MCP with Cursor — Tips, Gotchas, and Things I Learned the Hard Way

Cursor is better than Claude Desktop for actual MCP-assisted development work. Claude Desktop is still better for poking at a setup when you don't trust it yet.

I'm writing upfront because I spent too long trying to be diplomatic about it.

Why I switched

The context switch cost was frustrating me. I would work on something in my editor, hit a wall, switch to Claude Desktop, ask it to run a tool, receive the answer, then go back to the editor and continue manually apply what I'd learned. Twenty times a day. Maybe more. Each switch is only 10 seconds, but they add up to this low-grade annoyance that makes you feel like you're doing something wrong.

So I moved my MCP workflow into cursor, not all at once. I started with the filesystem server because it was already stable and I knew it worked. Configured it in Cursor's MCP settings, restarted, and asked the AI to list files in my project directory.

Worked on the first try, which rarely happens to me. I should have been suspicious.

The genuinely better thing

The tools live close to the code. That's it. That's the whole advantage. And it sounds stupid until you actually experience the difference.

In Claude Desktop, the AI reads your files through MCP and tells you what to change. Then you change it. In the cursor, the AI reads your files through MCP, understands the context, and can apply changes directly in the editor. The loop is tighter. You're no longer copying information between two applications.

For the kind of work I do on mcp-find.org — testing servers, checking tool schemas, fixing build scripts — having the tools right there in the editor have noticeably reduced my iteration time. I can't give you a percentage because I didn't measure it properly. But the feeling of "this is faster" was immediate and obvious.

I also stopped losing context. In Claude Desktop, if I had a long conversation about a problem and then went to the editor to fix it, I'd sometimes forget a detail and have to switch back. In the cursor, the conversation and the code are in the same window. No switching, no forgetting.

The thing that's genuinely worse

OK, so here's where I have to be honest.

Cursor can be fussier about MCP in ways that are hard to pin down. With Claude Desktop, when a server is not functioning properly, it's usually pretty clear: the hammer icon isn't there, or the tools don't appear. You check the config, fix the path, restart, and done.

With the cursor, I've had situations where the MCP integration appears to be present, but something is slightly off. The tools appear in the list but they don't get invoked when they should. Or they get invoked but with weird arguments. Or the server connects fine for an hour and then starts timing out for no reason I can identify.

I had one specific setup — a Python-based retrieval server — that worked perfectly in Claude Desktop with the same config, same server binary, same everything. In the cursor, it would connect, work for a few queries, then go into this state where it seemed to half-recognise the server. The tools were listed, but calls would hang. I never fully figured out what was happening. Restarting the cursor fixed it every time, but I shouldn't have to restart my editor every 45 minutes.

That was a few weeks ago, and it's gotten better since then. But the experience left me with the background worry that Cursor's MCP layer has rougher edges compared to Claude Desktop. This makes sense — Claude Desktop is Anthropic's own product connecting to Anthropic's own protocol. Cursor is a third-party editor building on top of it.

When I still use Claude Desktop

I haven't abandoned Claude Desktop. I use it for two things:

Testing. When I discover a new MCP server on GitHub that I want to evaluate for mcp-find.org, I test it in Claude Desktop first. Always. Fewer moving parts. If it doesn't work there, it's definitely a server problem, not an editor problem. Claude Desktop is my clean room.

Debugging connection issues. If a server that was working in cursor starts acting weird, I'll fire up Claude Desktop with the same config to see if the server itself is healthy. If it works in Claude Desktop but not the cursor, the problem is in the cursor's MCP layer. If it doesn't work in either, the server broke. This has saved me from chasing the wrong problem multiple times.

Some people say choose one option and commit to it. But having a second client as a debugging baseline has been worth the mild inconvenience of maintaining two configs.

Setup differences from Claude Desktop

The config format is slightly different — Cursor stores the MCP config in its own settings rather than a standalone JSON file. The exact location depends on your OS and Cursor version, but you can usually find it through the Cursor's settings UI under the MCP or AI section.

The server config structure is basically the same: command, args, env. If you have a working Claude Desktop config, you can copy the server entries with minor adjustments. The restart behaviour is different — a cursor doesn't always need a full restart when you change the MCP config — sometimes just reloading the window is enough. But sometimes it isn't, and you're back to the "did the change take effect or not?" guessing game. I've developed a habit of doing a full restart every time just to be safe. It costs me 10 seconds and saves me 10 minutes of wondering.

One thing that caught me off guard: project-relative paths behave differently in the cursor than in Claude Desktop. In Claude Desktop, the server's working directory is honestly hard to reason about. In the cursor, it's relative to the project you have open, which means if you have path-sensitive servers like a filesystem server scoped to a specific directory, the behaviour might change depending on which project you're working in. I learned this after being confused about why a server could see different files on Tuesday than it could on Monday — I'd opened a different project.

The pricing tangent

I'm going to go off-topic for a moment because this has been bugging me.

AI IDE pricing is a mess. Not just the cursor. All of them. Every product bundles a different set of things into "premium" and uses different words for what you're buying. One product gives you X requests per month. Another gives you Y minutes of "fast" responses. A third has a token budget that you can't easily map to actual usage.

I pay for Cursor Pro. It's worth it for the MCP integration alone. But I had to use it for two weeks before I could tell whether the free tier would have been enough, because the pricing page didn't give me enough information to figure that out in advance. That's a complaint about the industry, not specifically about the cursor.

End of tangent.

Practical notes from a few weeks of daily use

These aren't organised. They're just things I've bumped into.

If MCP is acting flaky in the cursor, test it in the simplest possible project first. Create a new empty folder, open it in the cursor, and check whether the server connects. If it does, the problem is project-specific. If it doesn't, the problem is configuration-level. This has saved me from rabbit holes.

Be careful with relative paths in your server config. What the server sees as its working directory might not be what you think it is, especially if you switch between projects. When in doubt, use absolute paths. I know I keep saying this. I keep saying it because I keep getting bitten by it.

If a server works in Claude Desktop but not in the cursor, check what runtime Cursor is actually using. It might be picking up a different Node or Python binary than your terminal would — the which node trick from my Claude Desktop setup article applies here too.

Keep one boring, known-good server around as a sanity check. I always have the official filesystem server configured because it's simple, stable, and well-tested. If my custom servers start acting weird, I test the filesystem server first. If that works, the problem is my server. If that's also broken, the problem is the Cursor's MCP layer. Having a baseline makes debugging way less stressful.

Where I landed

Cursor for daily development. Claude Desktop for testing and debugging. That's my setup. I don't think about it much anymore, which is probably a sign that it's working.

The gap between them isn't small, by the way. Once you've used MCP tools inside your editor — actually inside, not in a separate chat window — going back to Claude Desktop for regular work feels like using a calculator app while a spreadsheet is open. It works, but you're leaving performance on the table.

That said, if you're starting with MCP, I recommend setting up in Claude Desktop first. Get comfortable with servers, configs, and debugging in the simpler environment. Then migrate to the cursor once you know your servers are solid. Starting with the cursor when you don't know if the server even works is asking for a bad time, because when something breaks, you won't know which layer to blame.

I learned that the hard way. Hence the title.