MCP tools only become available to the AI agent after I manually toggle the MCP server off and on in Settings → Tools & MCP, even though the server is already enabled.
Configuration: My MCP servers are configured globally in ~/.cursor/mcp.json (not project-specific).
What happens:
MCP servers (e.g. Azure DevOps, Context7) are enabled and show as active in the UI
When I start a new chat or Agent session, the agent reports that the MCP server does not exist or that tools are not found
After I toggle the server off and then on again in the MCP settings, the tools start working for that session
Expected behavior: Tools should be available as soon as the MCP server is enabled, without needing a manual toggle.
Steps to Reproduce
Enable an MCP server in Settings → Tools & MCP
Start a new chat and ask the agent to use a tool from that MCP (e.g. list my Azure DevOps PRs)
Observe: agent says the server or tool is not found
Go to Settings → Tools & MCP and toggle that server off, then on again
Ask the agent again to use the same tool
Observe: tool works
Expected Behavior
Tools should be available to the agent as soon as the MCP server is enabled in settings, without requiring a manual toggle off/on.
Hi Matheus, I have been observing the same behavior all day with 2.5.20 on Linux as well. In the presence of an active, connected MCP server, the model starts flailing around looking for local files in the project to determine MCP tooling. When asked to stop and then use the , it comes to its senses and starts making appropriate tool calls again.
(Request ID: c00d5e16-bf37-4504-8445-1fdd4ac10002 ) – seems to be new behavior in this version, and feels like a different issue than some of the other MCP reliability issues.
Same here! I noticed that toggling any MCP off and on in settings makes all of them suddenly available, not just the one I toggled. Seems like it forces some kind of refresh. Your “local files” detail is interesting though, I hadn’t noticed that pattern on my end. Hope they patch this soon.
Update: just disabling one MCP (without re-enabling it) is enough to trigger the reload—full toggle not required. Any change to the MCP list seems to force the initialization that should have happened on startup.
After more testing, I noticed there’s actually a delay between the UI showing the MCP tools as available and the agent actually being able to use them. If you wait a bit after the server shows as connected in Settings, the agent eventually picks up the tools on its own — no manual toggle needed.
So this may not be a hard bug, but rather a timing/initialization issue: the UI reports the server as ready before the agent context is fully updated. A small loading indicator or a brief “tools loading…” state in the UI would help avoid confusion.
Leaving this here in case others run into the same thing.
Cursor team, this is maddening. Using 2.2.25 . Definitely not solved. I’m not sure if @devmatheusmota and I are encountering different issues, but it’s still doing weird things like looking in .cursor/projects/… for MCP details when there’s a working MCP server connected. Saying something like ‘no no no’ causes it to remember that there’s an actual MCP and try to connect to it. Request ID: 42e9bbea-2f13-4149-8156-9c8dce1ec0c0
edit: removed lighthearted comment about providing free QA for Cursor. I have no idea how anyone could have construed this as offensive, but it was flagged as such.
I am also seeing this issue. I’m currently on 2.6.18. The trick of going in and toggle off/on all my MCP servers got everything going. I tried manually asking for a specific mcp tool and it could not find it. The only solution I found was the toggle off/on trick. Pretty frustrating, especially as Cursor gets updates all the time and we have to do this daily.
I’m bumping this up to note that this is still an issue in 2.6.19. Not sure if it affects MCP plugins in the marketplace or just direct MCP server connections (we are using the latter). Very frustrating to have to redirect the agent to look for already connected MCPs (‘use xyz MCP’) when it goes fumbling around in the filesystem looking for non-existent tool .json files.