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
@Michal_Kucirka - what you’re describing (project-level .cursor/mcp.json servers not showing up at all in the new Customize tab on 3.12.30, even after a full restart) sounds different from the original issue in this thread, so let’s not mix them. To track it separately, please start a new thread and include:
Is this a regular folder or a multi-root .code-workspace
The exact path to .cursor/mcp.json and its contents (transport type: stdio or http)
A screenshot of Customize > MCP
Your OS
As a temporary workaround, you’re right that moving servers to user-level makes Cursor pick them up.
@Chris_Drake - Linux not connecting to MCP servers at all (the socket doesn’t even open) is also a separate issue, not about the tools refresh in this thread. Please start a separate thread for it and include:
Your Linux distro and Cursor version
Your mcp.json (which transport)
The error text from logs Output > MCP panel, or Help > Toggle Developer Tools > Console
That way we can track and update each issue independently. For the two original items (tools refresh and connection storm), the status is unchanged. I’ll post here once there’s an update.
Hi Dean - happy to help - does Cursor offer customers credit (e.g. usage) for the effort we put in towards finding, reporting, and helping diagnose product issues? How do we claim these?
Hey Chris. No change on either item. Neither tools refresh reconnect reload and notifications/tools/list_changed on 3.12.17, nor the connection storm has made it into the latest build yet. We’re still tracking both, but I can’t give an ETA. As soon as there’s an update on either one, I’ll post it right here. For now, the only reliable way to pick up a new tool list is a full Cursor restart, and as you noticed, rolling back to 3.11.25 is a temporary workaround.
On the credits for bug reports from your last message. We don’t have a formal compensation program for finding and diagnosing issues, so there’s nothing to claim. That said, your detailed writeups, like the exact connection storm numbers 94 out of 97 connections, and testing list_changed across different builds, are genuinely helpful and have already been attached to the relevant reports.
Adding a concrete detail that might help with the “cache doesn’t get cleared on reconnect” fix.
Environment: Cursor 3.17.8 (Linux), MCP via mcp-remote → Streamable HTTP group endpoint (MCPJungle), server id user-mcpjungle.
Observation: After the MCP server’s live tools/list shrinks (e.g. removing a whole upstream from a tool group), Cursor’s Settings tool count and agent tool catalog often stay inflated.
In our case, reconnect / reload appears to add or update those JSON files from the new tools/list, but does not delete files for tools that are no longer returned. Removed tools remain as orphan descriptors (e.g. old github__* after that server was dropped from the group). Live tools/list from the server is correct; the UI/agent view tracks the on-disk set.
Workaround that matches this: Fully quit Cursor. Reload Window alone is not enough.
Happy to share a before/after file listing if useful. This may be the same tracked cache bug; the “never delete orphans” behavior is the part that made removals especially sticky for us.
Hey, thanks for the specific details, that’s exactly the kind of thing that helps. The fact that reconnect or reload refreshes and adds per-tool JSON under ~/.cursor/projects/<slug>/mcps/<server-id>/tools/, but doesn’t remove descriptors for tools that are no longer in the live tools/list, fits what we’re seeing. The UI and agent catalog seem to track what’s on disk, not the latest server response, so removed tools stick around as orphan files.
It’s also helpful that you can reproduce this on 3.17.8. It was previously reported on 3.12.17, so it looks like the issue isn’t tied to a single version. I’ve passed these details along in the tools refresh report we’re tracking. The workaround you described matches what we see too. Fully quitting Cursor is reliable, Reload Window isn’t.
I can’t share an ETA yet, but I’ll post here as soon as there’s an update. Also, a before and after file listing would be really useful, if you can share it I’ll attach it to the same report.
This never-ending problems with Cursor not working properly for MCP servers is driving me crazy. Can you PLEASE let me fix it for you. I’ll sign whatever you need. Chris Drake - 1id.com | LinkedIn
Hey Chris. I get how draining this is, especially when you’ve been tracking it for more than a week and still have to stay on 3.11.25.
About your offer to fix it yourself, I really appreciate that attitude, but the Cursor client isn’t open source, so we can’t directly accept external code changes. That said, what you’re already doing, detailed diagnostics, is the most helpful contribution for us. The exact numbers on the connection storm 94/97 on two servers, disable only frees one connection, checking notifications/tools/list_changed across different builds, and the description of the async call in a loop have all been attached to the relevant reports and won’t get lost.
Status on both items is unchanged. Both the tools refresh issue reconnect/reload plus list_changed on current builds and the connection storm are still being tracked, but I can’t share an ETA yet. The reliable way to pick up a new tools list is a full Cursor restart, and downgrading to 3.11.25 is a temporary workaround.
As soon as there’s an update on either one, I’ll reply right here.
I think you’re confused? I’m talking about a smorgasbord of MCP bugs which I’ve been reporting for over a year now - this is not a “week” timescale by any means!
“Cursor” is actually built on open-source, in case you did not know: “The Open Source Core” is where it comes from. Your team has added proprietary bits of course.
Can I please send you a prompt for you to feed into Fable-5 1M which will fix all of your MCP problems in one go? Obviously, your coding team will get to review this for appropriateness before submitting, but I’ve already spent 10x (maybe 100x) more time asking your teams nicely to fix things without luck
This seems like the logical easiest next-step for everyone. You may recall that I already explained the full details of the main bug (many times) before [calling an async function in a loop by mistake] - with the right prompt, Claude can cure it all in 5 minutes.