Nearly every existing server includes instructions for .json config.
Other popular clients use the same format.
Instead of simple copy/paste from an existing config Cursor requires adding servers individually in a format few, if any, will provide documentation for.
Similar to how Cursor can import our VSC config, it should offer to import our MCP config. I’d much rather import them all and delete ones that don’t work (single click) vs. adding them all manually.
Using a modal dialog for +add new MCP server is also annoying since it prevents copying from an open config file.
There are servers that install servers. It would make everyone’s lives much easier to customize one for Cursor and include it by default.
This could allow automatic installation from the chat window, and listing known compatible servers to prevent wasting time with the majority that don’t work.
I’m not aware of any other client that opens individual node.js windows for each server (or any at all) so this should be avoided if possible.
It’s great to be able to add a server in the settings, but it shouldn’t be a replacement for a config file that experienced MCP users are familiar with.
MCP servers can be edited or deleted from the MCP settings page.
There really needs to be enable/disable (like other MCP implementations.)
Otherwise, we need to fully delete a server to disable it, only to re-add it all over again to enable it.
It’s common for servers to have identical tool names (e.g. I have four called read_file). This can cause disambiguation failures in Claude, even with explicit instructions. Each server should maintain its own namespace, with tools being uniquely identified through fully qualified paths
The Composer Agent will automatically use any MCP tools that are listed under Available Tools on the MCP settings page if it determines them to be relevant.
This makes the same mistake as Claude Desktop. My tool descriptions alone are ~17,000 tokens! Do I really want that included in my prompts just so Composer Agent can decide to use tools without me telling it to?
Implementing tool categorization could allow context-aware loading from only a lightweight tool manifest containing only essential metadata.
Detailed tool descriptions would then be loaded dynamically based on contextual relevance or explicit user requests. This optimization would significantly reduce token overhead.
Semantic categorization would enable intelligent tool suggestion and loading based on user intent, rather than maintaining all tool descriptions in constant context.
Would you be able to give a more indepth writeup on your use of the MCP tools you have, and what areas they serve, and more specifically “lightweight manifest” whereby, which MCP tools are your most common/productive/valued…
It would be great to have some better writeups on how to better leverage… especially with claude desktop.
Or, please point to resources you find best to get people to deeper adoption of MCP toools with claude/cursor
To be clear, I don’t use most of MCP tools I have installed, but I follow the development closely and add ones that seem interesting, or that might be useful in the future.
I use Claude Desktop with MCP tools as a substitute for Chat in Cursor.
Claude has Projects, but it’s annoying keeping the knowledge files updated, especially as the allowed extensions are hard-coded and exclude most files I use that it can actually read.
I use the Filesystem server so my local files become the ‘Project Knowledge.’
I have Claude save and read notes/summaries as local files so new chats stay up to speed.
Sequential-Thinking breaks up tasks, discovers errors, and creates PRDs for features.
MCP-Reasoner with MCTS is used for hard problems.
In my Project Knowledge I have a readme file that instructs Claude on what tools to use, and local files to read so I don’t have to keep explaining it.
Other MCP servers are used for:
-Task management, Git, Trello, Todoist
-web search, download
-accessing other models (OAI, DeepSeek, Grok, Perplexity, Gemini)
-knowledge graph/memory, executing code, shell commands, browser automation
These are the best places for MCP discovery (there’s also a link to the MCP Discord)
Cursor’s userbase consists of people who are familiar with working with config files.
As @AbleArcher has stated, moving to a config based implementation of adding MCP servers would make the user experience a lot easier.
I’ve just spent the past hour or so trying to figure out how to install MCPs to no avail see this thread from 2 days ago. The current UI isn’t very verbose when a MCP isn’t configured correctly.
As a start, I believe adding a implementation of a config file similar to claude 's would accelerate MCP adoption on Cursor. Other features mentioned can be added incrementally.
Something to consider is environment variable configuration for MCP servers. This is something that config file options have out-of-the-box, but is not available right now with the visual editor.
A good example of this is Brave Search, where env vars are used to specify API keys.
Some positive feedback on the feature:
Overall, love the long-direction that this and .cursorrules suggests
The refresh button to retry config is a strict improvement over Claude’ app, nicely done
Yes, it seems weird that it’s Claude Desktop, aimed at a more general audience that forces users to manually edit .json config files, while the IDE has the limited UI-only option for developers!
Ideally, neither method should be required except as a fallback option.
Shouldn’t a top-ranked coding model, and an IDE built on top of it with a literal “Agent mode” be able to handle something this basic?
Speaking my language. I have kind of ignored my Claude subscription but the MCPs you pulled especially with the file system integration is interesting. Can I ask what your workstream looks like as far as using Cursor vs Claude Desktop/browser?
Is it dumb to ask the OS having an impact on this? I use Windows 11 and Ubuntu, both give different issues using MCP. I see Mac users/Unix users getting this to work no issue, so just curious if anyone has successfully got MCP to work on Windows. Secondly, curious if anyone has done the docker implementation vs just using npx.
I use Win 10. It definitely works, but if my main experience was with Cursor instead of Claude Desktop I’d think I’m an idiot and the whole protocol is hot garbage (the first may still be true).
You’re not entirely wrong about the OS being a factor. Everyone in Silicon Valley seems to think the whole world runs on 13" Macbooks and Windows support is secondary.
While I have a ton of installed MCP servers, I’d say there are probably 10-20% I haven’t been able to get working. I normally keep my config file ‘clean’ by moving non-working config entries to a different file to easily try them again later.
My preference is always uvx/npx, but when that fails I clone them/manage them with GitHub Desktop and follow the manual/development install.
Git Bash often works better than cmd. I forget the specifics, but I installed some Windows based alternative to chmod since that was a common failure point when installing with node.
I use Cursor to edit my Claude config file and it’s really helpful for fixing formatting, and changing things like /path/to my actual paths.
I just got 0.4.6 so haven’t had much time to test, this is a definite improvement!
Project level configuration is very helpful, though I wonder if supporting @ at the message level could allow using task specific config files?
ie .curosr/MCP/reasoning-tools.json
In general, the reason to invoke MCP tools is to accomplish a specific task, and this is even more the case in Cursor.
This usage would also be consistent with the new Cursor Rules changes.
A related improvement could be allowing MCP servers (or task specific combinations as described above) to be invoked/loaded in .mdc rules files.
The downside of .json is the lack of comment support.
With MCP in .mdc rules users can write custom descriptions for how/when to use specific servers/tools/combinations, and load the necessary configurations.
Other:
Enable/Disable is really good. Though I think the tool list and other details should be cached. Although tools are not available for disabled servers, we should still know what they are.
Manual would load servers if referenced, but they would not auto-start (more resource efficient, and reduces token overhead for descriptions etc.)
Automatic could load when used and unload when the user loads a different MCP config.
Natural language commands like “Stop all MCP servers” should be recognized in the sidebar.
"startup": "auto",
"category": "reasoning"
"comment: "Useful for planning and challenging bugfixes. Always use MCTS",
"autoApprove": [project],
This just a mockup, but categories could be used for grouping, and comments could be used with categories for intelligent tool discovery, as well as serving as custom instructions for each MCP server.
Installing MCP servers should be this easy, exactly as suggested in my original post.
There are servers that install servers. It would make everyone’s lives much easier to customize one for Cursor and include it by default.
This could allow automatic installation from the chat window, and listing known compatible servers to prevent wasting time with the majority that don’t work.
There’s half a dozen included models that can score 70%+ on GPQA Diamond, installing MCP servers isn’t asking much.
A major MCP issue is the majority of servers still fail, the UI provides zero useful information. There’s nothing in the docs about where logs might be located (if they exist al all!)
Information (tools etc.) persists when servers are disabled.
Can be collapsed/expanded to show more or less details.
Enable/disable in the UI should also be reflected in the json IMO, and an allow field could provide more granular control than “YOLO” or “ask me about everything all the time.”
