Cursor stops deep in a conversation saying I need to disable MCP servers, or switch models

I have the request id: 894acd9b-2793-4ee3-908b-a417c65c9922

I’m using gemini-2.5-pro (max). I also have two MCP implementations that are critical to what we’re doing. They seem to work fine.

In this particular conversation I am deep into a refactor. It has done a lot of changes in that time. No problems. Then, suddenly, it’s stuck. The error says I need to either disable the MCP servers, or switch models. I tried talking to the model in a different window and it seems fine. In the broken window, trying the request again continues to give the same message.

While I understand what the error says factually, the complete lack of detail is rather frustrating. What’s actually wrong? Is it making a particular call to the agent that is failing? If so, how? Can it not just deal with a failed MCP call? I assume it can, so why does Cursor simply stop with that error? I can’t simply continue working without the MCP tools, and there haven’t been any significant issues with them previously, using several different agents.

Is there a reason switching models would fix this? Deep in the middle of a refactor, there is no way I’m just going to “switch models”. They’re all rather different, and if I happen to select a model and it causes a context compression (or whatever), it’ll be somewhat like working with an entirely different “person” in the middle of a task.

The error is frustrating and vague, and one of the reasons I started using other agent tools. I can’t find the actual issue in logs. This kind of error needs a bit more “why” than simply “what”. I can’t imagine why disabling the MCP servers would help, nor why switching models would solve anything. Doing either would certainly make continued progress rather difficult.

“Explain how to reproduce the bug
I couldn’t begin to imagine how somebody would reproduce this bug.

“Attach screenshots or recordings (e.g., .jpg, .png, .mp4).”
Attached. I assume that clears up nothing (which is primarily why I’m submitting this report).

“Tell us your operating system and your Cursor version (e.g., Windows, 0.x.x).”
Mac 15.1, Cursor 0.48.8

“Tell us if the issue stops you from using Cursor.”
Yes, very much so. I may be able to restart and/or try to begin from a new conversation, but OMG, the loss of context is brutal with these kinds of edits. I had abandoned Cursor recently, and only came back because, as it turns out, other agents are also prone to blowing up arbitrarily. The others, however, usually give some more useful data.

Sorry for the expression of frustration, but you really need to give more detail when things go wrong. Most of the frustration is the message, and lack of detail. Should I also reboot the router? Disconnect the external monitor? Why do I need to disable the MCP server? If there’s an error, is there not a log of the error? If there’s a model error, is there not an error message? Which one should I do? Both? Why?!

PS: I uploaded an image, and just before I did I thought “I should copy this text in case it disappears”, and guess what happened when I uploaded…

Screenshot 2025-04-21 at 2.02.45 AM

2 Likes

Follow up. I tried continued communication instead of retrying the request. No luck. I switched to gpt 4.1, primarily because it has an equivalent context window. Then we went through “onboarding”, where it claimed to have the full context (it did not). Then we debated the meaning of “autonomous”, and now I’m experiencing just how much more encouragement 4.1 seems to need vs gemini 2.5. Anyway, please, give errors with more detail.

Same issue have you found a fix?

I had this error to and no explanation. But forcing the agent to use claude-3.7-sonnet did call the mcp tool after another prompt try.

No fix. It happens periodically. I was rather frustrated when it happened, but I put it in the same bucket as mostly everything with LLMs and all agent tooling. S$@# happens. Be ready for it. That means owning your context and an offensive use of git. It has nothing to do with MCP, directly at least. If you switch models, it’ll continue, but who knows what state your conversation is actually in. That, and different models are like talking to entirely different people. If I’m deep in a process that maybe had some good lessons for context, I’ll switch models to then try and write a hard copy summary. Otherwise, the “fix” is a new conversation. I’m sure they’ll figure it out at some point. While using Cline, which just let’s you eat up the whole 1m of Gemini 2.5, I wouldn’t trust anything the model did once it got halfway. It got flakey. I assume there’s some kind of internal sanity check that gets triggered at some point.
But, again, it would be nice to have a more useful error. Like, “this chat is toast, sorry”. Maybe not “useful”, but at least you’re sure it’s time to throw up your hands.

I started to do a small MCP server, and first tool worked great. Then Added new ones and at some point I arrive at:
“The model returned an error. Try disabling MCP servers, or switch models.” !

It’s exactly what I’m testing… My own MCP server! So I don’t want to disable it.
The issue is that I don’t have enough detail to know what failed! “The model returned an error”… No! It was not called.

I’m trying the MCP with another MCP client, and I manage to call each tool without any issue.
So there is something else blocking inside cursor directly… I would like to help unblicking this issue, but how ?

Let me know