[Bug] MCP server connection issues

[Melodeiro]

Some MCP servers aren't very stable. It might be their implementation issues or different protocol versions/approach to development.

One of the most annoying but also a very desirable is Jetbrains MCP. If i add SSE endpoint its just doesn't loads any tools. If i try stdio - it loads, but might lose the connection. Such connection issues can lead to dashboard freeze, which is a not a big deal most of the time. Application might even hang and only forced kill helps.

Im using xubuntu 25.04, running in a remote mode as a user-scoped systemd service

[Melodeiro]

If talking about freezes, there are the fresh example with context7 (i have seen it quite a lot times before).

Before the error (10:53:33):

 ┃ INFO Making direct tools list call to upstream server {"server": "context7"}

All other servers successfully completing health checks:

 ┃ INFO Successfully retrieved tools via direct call to upstream server {"server": "deepwiki", "tool_count": 3} DEBUG Health check
 passed successfully {"server": "deepwiki"}

The failure (10:53:38 - 5 seconds later):

 ┃ ERROR Failed to list tools via direct call to upstream server {"server": "context7", "error": "transport error: failed to send
 request: failed to send request: Post \"https://mcp.context7.com/mcp\": context deadline exceeded"}

 ┃ WARN Health check failed with connection error, marking as error {"server": "context7", "error": "failed to list tools:
 transport
 error: failed to send request: failed to send request: Post \"https://mcp.context7.com/mcp\": context deadline exceeded"}

 ┃ INFO State transition {"from": "Ready", "to": "Error", "server": "context7"}

 ┃ ERROR Connection error {"server": "context7", "error": "failed to list tools: transport error: failed to send request: failed
 to
 send request: Post \"https://mcp.context7.com/mcp\": context deadline exceeded", "retry_count": 1}

After the error:

 ┃ DEBUG Server state changed - emitting servers.changed event {"server": "context7"}

Analysis:

• Request initiated at 10:53:33
• Timeout after ~5 seconds (deadline exceeded)
• Server was in "Ready" state before failure
• First retry attempt (retry_count: 1)
• All other servers (supabase, deepwiki, etc.) completed successfully in 2-4 seconds

[Melodeiro]

When connection issues with mcp servers happens, like this one, web ui also got connection issues with mcpproxy process. Probably a thread blocking call

[algis-dumbris]

@Melodeiro Could you try the latest version v0.9.21?
JetBrains MCP via SSE works for me. Also, the number of tools is visible in the web UI.

[Melodeiro]

Yeah, there were 0 tools in the web UI, but on MCP protocol (client <->mcpproxy) it responded with the list of tools but wasn't able to connect to them.

All right, will try

[Melodeiro]

SSE version works fine, wasn't able to reproduce the STDIO problem with Intellij MCP as well. Well, looks like the reason why i got 0 tools for SSE proxy was that i copied the config from intellij and pasted it to the .mcpproxy/mcp_config.json file manually... And there was a wrong protocol property name: intellij got "type" while mcpproxy uses "protocol" instead.

Thats what you get when you copy it from intellij:

{
  "type": "sse",
  "url": "http://localhost:64343/sse",
  "headers": {
    "IJ_MCP_SERVER_PROJECT_PATH": null
  }
}

I have seen one freeze during tests, sounds like another server, http protocol this time. 504 is a problem on the remote server, but UI again showed the spinner and request /servers stuck in pending state. Attaching the logs

The problem occured somewhere around the 01:45:
mcpproxy_crawl4ai_complete.log

Thats what i have told about OAuth error: there aren't such type of auth (yet) on this remote MCP server, so the error is slightly misleading. And since it is the 0.9.21, i guess there are still something that is blocking/locking the thread or coroutine, but it is already working better in other scenarios, thank you!

[Dumbris]

Thanks a lot for the detailed report - really appreciate the clear breakdown and logs!

The REST API freezes will need a separate investigation since they seem unrelated to the SSE or STDIO configuration issues. I’ll close this issue for now, but please feel free to reopen it or create a new one if the problem reappears.

Your feedback is very helpful and directly contributes to improving the project - thank you again!