The latest update has introduced a swathe of new bugs in the way Cursor handles MCP server connections (at least ones other than stdio anyhow).
It looks like it makes a “cache” of server response at startup, and then never fetches updates.
disconnect and reconnect does not show the correct tool list (only the stale one)
it looks like the disconnect and logout options do not actually do anything at all?
making changes to mcp.json does not make cursor load the mcp tools properly
I think you mistakenly think that an mcp reply can be cached? it cannot - they can change at any time - you need to do a full re-read of everything every time mcp.json gets touched, or every time a tool is dosconnected/reconnected, etc etc.
Steps to Reproduce
load an mcp (not stdio)
change it
tell cursor to connect and reconnect
notice it’s not using the new changes
exit cursor
restart cursor
notice it work properly now
Hey thanks for the detailed report. This is a known bug. Reconnect/reload and changes in mcp.json don’t always pick up updates for non-stdio servers. Only a full Cursor restart is guaranteed to load the new state. We have it tracked but I can’t share an ETA on the fix yet.
Quick note on never cache. The tool list snapshot is cached on purpose. The issue is it doesn’t get cleared on reconnect/reload. That’s exactly what we’re fixing.
For now here are workarounds that work today. If you control the server send notifications/tools/list_changed after you change tools. This forces a live re-list without a restart. In mcp.json change one of the hashed keys for example add a dummy query param to url. This makes Cursor rebuild the client. Full restart works as a fallback.
On the disconnect/logout doing nothing point. For cloud MCP the Logout fix is already in 3.12.17. If you still see the issue describe the surface and server type and I’ll look into it separately.
Thanks for the hint! That unfortunately does NOT work on the current release of cursor. It does work on most older releases I have tried - but I think you know that already, so I guess we just have to wait for a fix!
While you’re there - is there any chance you can fix the multi-year-long bug you STILL have in your connection code? You’re calling an async function in a loop which spawns a storm of new connections to existing servers for no reason. e.g. if I have 10 different MCP servers (even if they’re not connected), cursor makes 10 new connections to every server, keeping all of those alive, but only using a single random one to work with, and it does this every time a reconnect happens (never releasing the old ones) - I’ve seen hundreds, sometimes thousands, of simultaneous connections being maintained by cursor to my servers - this is an incredibly serious bug that is way past due being fixed! (it makes it almost impossible to run public mcp servers, because your own client DDoS’s us!)
Thanks for testing notifications/tools/list_changed. The fact that it no longer triggers a re-list on 3.12.17 even though it worked on older builds is useful. I noted this as a regression in the same issue we’re tracking for the tools refresh. There’s no ETA yet, and until it’s fixed, only a full restart is reliable.
About the storm of connections: you’re right, and you already described it in detail earlier. We have a separate open issue for this long-standing problem with parallel connections during reconnect, and your explanation about the async call in a loop is recorded there. I’ll add your new note that the storm still reproduces on 3.12.17. I can’t give a timeline for a fix, but it’s separate from this thread and won’t get lost.
If you can, please share rough numbers on your side for 3.12.17: how many servers are in mcp.json, how many are enabled, and how many simultaneous connections you see on the server. That’ll strengthen the existing report with fresh data for the current release.
Hi Dean,
Thanks as always for the rapid personal reply!
I have 9 different MCP servers in my mcp.json, only 2 of them are enabled. Cursor has been open for about 12 hours now. It has 94 open simultaneous connections to one of those two enabled ones, and 97 open to the other one. (these are all https, not stdio, connections).
“stopping” (disabling) a server in the Cursor settings releases only 1 connection. Quitting cursor entirely results (obviously) in all of the rest closing all at once. i.e. all of those redundant connections are definitely “leaked”, which hints strongly at the call which established the connection misunderstanding how it worked, and wrongly thinking it’s a blocking-style procedural call, when it’s a non-blocking async one instead.
Thanks for the details, Chris. 94 and 97 live connections on two enabled servers after 12 hours, and the fact that disable only frees one while they all close at once only on exit, is exactly what we needed. The connection leak picture is clear and matches your description of an async call in a loop.
I added these numbers to the issue tracking the parallel connections on reconnect, so it now has fresh data for 3.12.17. I can’t share an ETA for a fix yet, but the report won’t get lost.
On the tools refresh side, reconnect or reload doesn’t pick up changes and notifications/tools/list_changed doesn’t fire on 3.12.17. That’s tracked separately, and for now only a full restart is reliable. I’ll post in the thread as soon as there’s an update on either one.
Is there any update on this? two weeks should have been, like, a dozen days more than it would have taken Claude to fix this problem already - are MCP servers working now? (and not incorrectly caching replies, not doing multiple reconnects, and actually working without having to exit and re-launch cursor all the time?)
Hey Chris. No update on the release yet. Neither tools refresh reconnect reload and notifications/tools/list_changed in 3.12.17 nor the connection storm has made it into a recent build. We are still tracking both, but I can’t share an ETA.
Until there is a fix, the only reliable way to pick up a new tool list is a full restart of Cursor. For the storm, your numbers 94 and 97 connections across two servers, and disabling only frees one, are noted and still the clearest description of the issue. We don’t need anything else from you right now.
As soon as we have an update on either item, I’ll reply here.
Hi Dean - thanks for the update!! I get your replies by email, so as soon as it’s fixed, I’ll know!
Meanwhile, I downgraded to Version: 3.11.25 which was the last working version before the tool-change stuff broke, so I’ll hang there until this gets fixed!
Hello @deanrie . Full Cursor restart doest help anymore. MCPs from mcp.json from to project level are not being picked up at all. As mentioned before, this is happening in new Cursor layout with MCPs in “Customize” tab under version 3.12.30. Is there an ETA for fixing this bug.
The only solution I see now is adding Cursor MCPs into the user level.
I discovered a new problem: the linux version of cursor is not connecting to MCP servers at all either. Logs show errors, but it never even tries to connect - not even opening a socket