MCP connection timeout issue with sse transport

[pwlnow]

Issue with MCP server supporting sse

I have below mcp plugin configuration on anythingllm docker container:

{ "mcpServers": { "mcp-chart-server": { "type": "sse", "url": "https://chart.mcp.cloudcertainty.com/sse", "anythingllm": { "autoStart": false } } } }

Inside the container, I use curl to check if I can connect to the url, and it did:

~/docker/anything-llm $ docker exec -it anythingllm bash anythingllm@5b5ff5baa572:~$ curl https://chart.mcp.cloudcertainty.com/sse event: endpoint data: /sse/message?sessionId=59121778345cac68406f9e498f32de25b1cdac8c62ba8d49474284d3839f920a

However, on the anythingllm setting page, when I manually start the mcp server connection, it failed. Here is the logs from anythingLLM container:

[backend] info: [MCPCompatibilityLayer] Attempting to start MCP server: mcp-chart-server [backend] error: Error toggling MCP server: Error: Not connected at SSEClientTransport.send (/app/server/node_modules/@modelcontextprotocol/sdk/dist/cjs/client/sse.js:139:19) at /app/server/node_modules/@modelcontextprotocol/sdk/dist/cjs/shared/protocol.js:298:29 at new Promise (<anonymous>) at Client.request (/app/server/node_modules/@modelcontextprotocol/sdk/dist/cjs/shared/protocol.js:237:16) at Client.ping (/app/server/node_modules/@modelcontextprotocol/sdk/dist/cjs/client/index.js:194:21) at MCPCompatibilityLayer.toggleServerStatus (/app/server/utils/MCP/index.js:165:41) at /app/server/endpoints/mcpServers.js:61:58 at Layer.handle [as handle_request] (/app/server/node_modules/express/lib/router/layer.js:95:5) at next (/app/server/node_modules/express/lib/router/route.js:149:13) at /app/server/utils/middleware/multiUserProtected.js:67:7 [backend] info: [MCPCompatibilityLayer] Failed to start single MCP server: mcp-chart-server {"error":"Connection timeout","stack":"Error: Connection timeout\n at Timeout._onTimeout (/app/server/utils/MCP/hypervisor/index.js:372:31)\n at listOnTimeout (node:internal/timers:569:17)\n at process.processTimers (node:internal/timers:512:7)"}

Is this a connection timeout issue? Can I configure a longer timeout? or is this a configuration issue or some kind of bugs?