MCP connecting error：internal server error

[Brianxia]

Self Checks

• I have searched for existing issues search for existing issues, including closed ones.
• I confirm that I am using English to submit this report (我已阅读并同意 Language Policy).
• [FOR CHINESE USERS] 请务必使用英文提交 Issue，否则会被关闭。谢谢！:)
• Please do not modify this template :) and fill in all the required fields.

1. Is this request related to a challenge you're experiencing? Tell me about your story.

I'm using Gbrain for my RAG, and dify for agent platform.

2. Additional context or comments

When I configed MCP to connect gbrain, I got following erros:
1, couldn't connect gbrain mcp, and got an error: Internal Server Error.

2, when deleting it, then got another error:

[dosubot[bot]]

Hi @Brianxia! I'm Dosu and I'm helping the Dify team.

Both errors you're seeing match a bug in MCP provider identifier handling that was widely reported after 1.17.0 shipped. The root cause: the MCP provider list endpoint returns the human-readable server_identifier (e.g. a slug like "gbrain") in the id field instead of the database UUID. When the frontend replays that identifier back to the server for actions like connect, update, or delete, PostgreSQL rejects the non-UUID value with invalid input syntax for type uuid, which surfaces in the UI as a generic "Internal Server Error" [1] [2]. Your second screenshot — the error when deleting — is consistent with the same identifier mismatch tripping the delete route's validation.

This has been tracked across several issues (#41109, #41305, #41328, #41512), and the frontend fix merged to main is PR #41360, which switches the MCP management view to load providers from the management-list endpoint (/workspaces/current/tool-providers?type=mcp) that returns real database UUIDs. A complementary backend fix in PR #41853 (still open) makes get_provider resolve either a UUID or a server_identifier, covering detail/update/auth/delete routes more robustly.

Important: PR #41360 merged on 2026-08-27, after the 1.17.0 release tag (2026-08-25), so the fix is not included in 1.17.0 [3]. If you're on 1.17.0, you'll need to upgrade to a newer build or a later release once one is cut.

Separately, it's also worth confirming your Gbrain MCP server URL is correct and reachable — Dify's MCP client auto-detects transport from the URL path (/mcp → Streamable-HTTP, /sse → SSE) and falls back between them, so a malformed or unreachable server URL can produce a similar generic internal error independent of the UUID bug [4].

Could you share which Dify version you're running? If it's 1.17.0, that would confirm this is the identifier bug described above.

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.

[Brianxia]

thanks. @dosu

my gbrain: 0.48.2.0
dify: 1.17.0

should I update dify?

[dosubot[bot]]

@Brianxia You're already on the latest official release — 1.17.0 is the newest tag. The MCP management bug (where delete/edit/refresh fails with an "invalid UUID" error) has been fixed in PR #41360, but that fix merged on main after the 1.17.0 release and hasn't been included in a tagged version yet [1].

Your options right now:

• Wait for the next release (1.17.1 or 1.18.0) — the fix will be picked up automatically through the normal upgrade path.
• Run from main if you're comfortable building from source in a non-production environment, since the fix is already there.

One important thing to note: the UUID bug specifically affects MCP management actions (editing, deleting, refreshing providers) [1]. However, your first screenshot shows an "Internal Server Error" when connecting to the Gbrain MCP server, which could be a separate connectivity issue. It's worth verifying that the Gbrain MCP endpoint URL is correct and reachable from your Dify server, since an unreachable or misconfigured URL can produce the same generic error independently of the identifier bug.

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.

[Brianxia]

by the way, when will 1.17.1 or 1.18.0 be released? thanks.

[LetMeSleep8h]

"Internal Server Error" here almost always means Dify's MCP client failed the MCP initialize handshake with the endpoint — it is not a Dify-internal crash. Here is how I'd narrow it down (I've spent some time in Dify's MCP client code, so this follows its actual connect order):

1. Make sure the URL points at the MCP endpoint, not the app UI

Dify picks the transport from the URL path: a path ending in /mcp uses streamable HTTP, /sse uses SSE, and anything else tries SSE first and falls back to streamable HTTP. If your Gbrain docs give you something like http://gbrain-host:8000/mcp, use exactly that — a wrong path is the #1 cause of this error.

2. Probe the endpoint directly with curl

This tells you in five seconds whether the problem is Gbrain or Dify:

curl -i -X POST http://<gbrain-host>:<port>/mcp \
  -H 'Content-Type: application/json' \
  -H 'Accept: application/json, text/event-stream' \
  -d '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-03-26","capabilities":{},"clientInfo":{"name":"probe","version":"0.0.1"}}}'

• HTML page or 404 → wrong URL/path.
• 401/403 → the endpoint needs auth; put the token in the provider's authorization (Bearer) or Headers config in Dify before saving.
• A JSON-RPC response (or an SSE stream) → the server is fine; the problem is on the Dify side (see 4).

3. Check the real traceback in the API logs

The dialog only shows "Internal Server Error"; the actual exception is in the api container:

docker compose logs -f api | grep -iA8 mcp

You'll typically see one of: connection refused (host unreachable from inside the container — remember localhost inside the api container is not your host; use host.docker.internal on Mac/Windows or the LAN IP), a timeout, or a JSON decode error (server isn't speaking MCP on that path).

4. Version mismatch

If Gbrain's MCP implementation predates a protocol version Dify requests (or is a very new one with breaking changes), initialize fails. Upgrading the Gbrain MCP endpoint to the current protocol version usually resolves it.

About the deletion error

When a provider fails mid-creation, Dify can leave a partially-initialized provider/credentials row behind, and deleting it re-triggers the failed connection cleanup. After fixing the connectivity from steps 1–3, deleting and re-adding the provider should go through. If the delete error persists, include the api-log traceback from step 3 in this thread — that will show exactly which cleanup step is failing.

[jamalkamaladdin]

Upgrade to 1.17.1, released Sep 10. #41360 fixes Authorize returning 500 on 1.17.0: it sent server_identifier where APIs expect provider UUIDs. #41288 fixes delete failing with Field required for provider_id.

Release notes: https://github.com/langgenius/dify/releases/tag/1.17.1