fix(mcp): start OAuth when initialize succeeds without tokens

[Epochex]

What

Fix MCP OAuth authorization flow for servers that return 200 OK on initialize even when no tokens are present.

Today ToolMCPAuthApi marks the provider as authed=true as soon as it can connect, which breaks OAuth-protected servers like Google Drive MCP: initialize succeeds, but later tool calls fail because no access token was ever obtained.

How

After a successful connect, if the provider has client_information configured but still has no tokens, start the OAuth flow via core.mcp.auth.auth_flow.auth() and return the authorization_url response instead of saving authed=true.

Tests

• uv run --project api pytest -q api/tests/unit_tests/controllers/console/workspace/test_tool_providers.py -k mcp_auth
• uv run --project api ruff check api/controllers/console/workspace/tool_providers.py api/tests/unit_tests/controllers/console/workspace/test_tool_providers.py

Fixes #36230

[Epochex]

Actions checks haven’t started for this fork PR yet (workflow runs show “Action required”).

I ran the focused checks locally and they pass:

• uv run --project api pytest -q api/tests/unit_tests/controllers/console/workspace/test_tool_providers.py -k mcp_auth
• uv run --project api ruff check api/controllers/console/workspace/tool_providers.py api/tests/unit_tests/controllers/console/workspace/test_tool_providers.py

Could a maintainer please approve/run the workflows so CI can execute?

[alexelagov]

Thanks for picking this up @Epochex — this PR fixes the exact issue I reported in #36230 (Google Drive MCP, and any other MCP server that returns 200 OK on initialize without bearer tokens).

We hit this on a self-hosted Dify 1.14.1 deployment and had to build a separate Flask service as a workaround, since the official Google Drive MCP can't be used until this is fixed.

Would really appreciate a maintainer (@QuantumGhost, @laipz8200) approving CI and reviewing — the change is small (116 LOC, +tests) and unblocks a meaningful integration path. Happy to test against my reproducer once it lands.

[Epochex]

Rebased this onto current main in 8fa05e4d5 and updated the success path to use the current MCPAuthResponse serializer.

The guard now checks parsed OAuth client information rather than a raw credential key, so a server with no OAuth configuration still follows the normal success path. The focused cases now cover:

• successful initialize + configured OAuth client + no token: start OAuth
• token already present: mark the provider authenticated
• no OAuth client configured: mark the provider authenticated

Validation:

• focused mcp_auth controller tests — 3 passed
• Ruff check on the controller and test file
• git diff --check

This is ready for CI approval and review.

[Epochex]

Rebased onto current main in f2eec1fc10. The MCP OAuth tests still pass locally:

• uv run --project api pytest -q api/tests/unit_tests/controllers/console/workspace/test_tool_providers.py -k mcp_auth
• uv run --project api ruff check api/controllers/console/workspace/tool_providers.py api/tests/unit_tests/controllers/console/workspace/test_tool_providers.py
• git diff --check