support request from @heimlandr.io (flagged by @Rahul) in #1170786067595661432

Is anyone else having connection issues with their MCP endpoint hitting timeouts? None of my MCP server are responding anymore. No changes to code. I have not hit any ratelimits. Done 4 hours of troubelshooting on my end. All is perfect. Is Composio MCP down or whats going on? System going hot?

Original message link: https://discord.com/channels/1170785031560646836/1170786067595661432/1424758333805432892 --- beep boop, I've moved this conversation here so the support team can get back to you sooner. Could you please share your debugging info if you have not already? https://docs.composio.dev/resources/debugging-info

hey @heimlandr.io can you share the debugging info and i can check we can check what is happening

Hey, can you share more details on what issue you're facing? Any error messages or screenshots would be helpful in troubleshooting.

well, its been a good 24 hours of troubleshooting now, when we updated from v52 to v53 we had to change get_server to mcp_generate. This added some runtime but it was not an issue at the time. Then all of a sudden. It started hanging indefinatley. I still have this issue. We worked around it by bypassing the entire Composio SDK and built 400 lines of custom code just to see if this was on the Composio side or not. We are running Vercel AI SDK with Composio SDK - 3 MCP servers with aprox 120 tools. Everything is very well done and in good order. And our webapp worked really good, and all of a sudden it started hanging shortly after the update of composio. I have like 10 docs on this right now and i still havent come to the conclusion on whats happening. I just tried updating to v54 as its EXACTLY what happened to us. We came to the "tool export" and then it hanged. This is the info from the Agent wrapping everything, and som supabase DB logs: Hope this answers your questions and can help us debug.

thanks for the details, we'll take a look and get back.

Let me know if you need more! I'll keep pushing for a few more hours to find out what's going on.

The new SDK release (0.1.54) contains some additional types and no change in the logical part, so I don't think this is an SDK issue. But I was able to reproduce the issue you mentioned, and tried it with other MCP clients (Postman) and it seems to be working fine. I'm troubleshooting this further and will keep you posted.

I rebranched and updated every single package, and have updated to the new API, trying the new structure - And all the other SDK's as well. So, we are getting closer. But its still hanging. Yes, I have tried the endpoints with curl and postman and this worked and was fast, but something is off with deno and Composio. Thats where I am at right now. I'll keep you updated. We are getting closer that's for sure. I just want to make sure this is on our end and not yours. When importing into deno, we use @latest, this might be an issue, it worked previously but we are testing pinning the packages right now. And adding comprehensive logging at the endpoints so we will know shortly.

It looks like there's an LLM call involved if I'm not wrong, so that depends on the task and model's speed.

The experimental_createMCPClient() in the Vercel AI SDK hangs because it doesn't respond to server "ping" messages over Server-Sent Events (SSE). This causes the connection to time out, preventing tools from executing. This is a know issue, so you should revert the clause that Vercel works with Composio. Becasue Vercel doesnt work with SSE and experimental_createMCPClient. There is no ping-pong going on. Only ping. The solution is a fork of Vercel ai SDK and a wrapper of the client. The reason it worked for about a week. Or "now and then": Likely one (or a combo) of these changed mid-stream: Dependency update: A patch/minor release of Vercel AI SDK, Composio, or a transitive SSE/EventSource polyfill changed behavior (e.g., stricter heartbeat/ping handling). Even “non-breaking” updates can alter timing. Server-side tightening: Composio MCP servers may have enabled/shortened ping/idle timeouts. Your client not replying to pings would start failing once the server enforced them. Environment/network shifts: Edge runtimes (Supabase/Render) can change keep‑alive, idle TCP, or proxy timeouts. A redeploy, region move, or infra tweak can surface previously masked bugs. Load pattern: Under light load, connections survived long enough despite missing pongs; once traffic/latency increased, the lack of ping/pong started causing disconnects/hangs. Code path variance: Small logic/config changes (creating more clients per request, longer tool runs, different model/tools) increased connection duration, triggering the heartbeat issue. In short: the client has a latent ping/pong gap; a routine update or runtime change flipped conditions so the server now expects heartbeats your client doesn’t send, so it began hanging. That was a good 48 hour troubleshooting getting to this point.

Thanks for the detailed troubleshooting info. Just a heads up—we officially deprecated SSE support a few months ago. We're still allowing it for now to avoid breaking changes since we saw some active traffic, but we'll be phasing it out in the coming weeks. HTTP is now the recommended approach going forward.