Agent configuration queries MCP providers through the builtin credential endpoint and returns 500

[CodeWarriors0]

Self Checks

• I have read the Contributing Guide and Language Policy.
• This is only for bug report, if you would like to ask a question, please head to Discussions.
• I have searched for existing issues search for existing issues, including closed ones.
• I confirm that I am using English to submit this report, otherwise it will be closed.
• 【中文用户 & Non English User】请使用英语提交，否则会被关闭 ：）
• Please do not modify this template :) and fill in all the required fields.

Dify version

1.16.0 (self-hosted deployment)

Cloud or Self Hosted

Self Hosted (Docker)

Steps to reproduce

Steps to reproduce

1. Deploy Dify 1.16.0 in a self-hosted environment.
2. Create an MCP provider under Tools > MCP. In this case the provider name is TAPD-TEST and its server identifier is tapd-server-test.
3. Complete the MCP authorization successfully and add one of its tools to an Agent configuration.
4. Open the Agent configuration page and inspect the network requests made by the tool authorization/credential UI.
5. The UI requests:
   GET /console/api/workspaces/current/tool-provider/builtin/tapd-server-test/credential/info

The MCP record exists in tool_mcp_providers, has authed = true, and has stored credentials. There is intentionally no matching row in tool_builtin_providers.

Response:

{
  "message": "Internal Server Error",
  "code": "unknown",
  "status": 500
}

Additional context

The builtin/{provider}/credential/info route resolves the provider through ToolManager.get_builtin_provider(...). An MCP server identifier is neither a builtin provider nor a plugin provider, so the lookup fails and is surfaced as a 500.

✔️ Expected Behavior

MCP providers should not be passed to the builtin/plugin credential-info workflow.

When an Agent uses an MCP tool, the UI should use the MCP provider state and MCP routes (/workspaces/current/tool-provider/mcp/...) for its configuration and authorization. It should not request /tool-provider/builtin/{server_identifier}/credential/info, and opening the Agent configuration must not produce a 500.

❌ Actual Behavior

The Agent configuration triggers a request to the builtin credential-info endpoint with the MCP server identifier. The backend then tries to resolve the MCP server as a builtin/plugin provider and returns HTTP 500. The MCP provider itself exists, is authorized, and has stored credentials.

[dosubot]

@CodeWarriors0 — this is the same class of bug that was reported for api-type tool providers in #39169, just now hitting mcp-type providers. The open PR #39866 fixes the api case but doesn't yet cover MCP.

Root cause (two layers):

1. getProviderCredentialType checks provider.team_credentials before checking provider.type. If an MCP provider has stored credentials in team_credentials, it returns 'api-key', which routes it into the plugin auth UI path and sets credentialVariant: 'unauthorized'.

2. UnauthorizedCredentialStatus then mounts usePluginAuth unconditionally for any tool with that variant. The useGetApi hook inside always builds URLs as /tool-provider/builtin/${provider}/credential/info regardless of providerType. The MCP server identifier isn't a builtin/plugin provider, so the backend returns 500.

Note that CredentialStatus does guard the authorized branch on providerType === CollectionType.builtIn [1], but the unauthorized branch at lines 184–186 has no such guard — it falls straight into UnauthorizedCredentialStatus for any non-none credential variant, including MCP.

What the fix needs:

1. In getProviderCredentialType: scope the team_credentials check to CollectionType.builtIn only (or explicitly exclude mcp, custom, workflow), so MCP providers aren't misclassified as api-key credential type.
2. In CredentialStatus / UnauthorizedCredentialStatus: add an isBuiltinProvider guard on the unauthorized branch (matching the authorized branch), so non-builtin provider types short-circuit to null before usePluginAuth is ever mounted.

Extending the existing PR #39866 to also exclude CollectionType.mcp (and CollectionType.custom / CollectionType.workflow) from both getProviderCredentialType and the UnauthorizedCredentialStatus render path would resolve this issue.

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.