Request: Increase MCP Tools Limit for Enhanced Development Workflow

[TylerAustinW]

Hello Cursor Team and Community,

I hope this discussion finds you well! I wanted to bring up an important issue that many of us developers are encountering: the current limitation on MCP (Model Context Protocol) tools that’s affecting our development workflows.

Current Situation

Many users are currently seeing an “Exceeding total tools limit” warning when working with MCP tools in Cursor. This limitation is significantly impacting productivity, especially for developers who rely on multiple MCP tools for comprehensive development workflows.

Why This Matters

MCP tools have revolutionized how we interact with various services and systems directly from our development environment. They enable us to:

• Enhanced Productivity: Access to multiple tools simultaneously allows for seamless workflow integration
• • Better Context Management: Different tools serve different purposes - file management, API interactions, database queries, etc.
• • Comprehensive Development: Complex projects often require multiple specialized tools working in harmony

The Problem

The current tool limit prevents developers from:

• Using comprehensive tool suites that require 10+ tools
• • Leveraging the full potential of MCP ecosystem
• • Building complex, multi-service applications efficiently
• • Maintaining productive development workflows

Proposed Solutions

1. Increase the Default Limit: Raise the current limit to accommodate modern development needs (perhaps 25-50 tools)
2. Tiered Limits: Implement different limits based on subscription tiers:
3. • Free users: Current limit
4. • Pro users: Higher limit (25-30 tools)
5. • Enterprise users: Even higher or unlimited
6. Dynamic Loading: Allow selective tool loading/unloading during development sessions
7. Configuration Options: Let users configure which tools are most critical for their workflow

Impact on Community

This enhancement would:

• Improve developer satisfaction and productivity
• • Better leverage the growing MCP ecosystem
• • Support more complex development workflows
• • Attract more developers to the Cursor platform

Community Input Needed

I’d love to hear from other developers:

• How is the current limit affecting your workflow?
• • What would be an ideal number of MCP tools for your use case?
• • Are there specific tool combinations that are essential for your work?

Conclusion

Increasing the MCP tools limit would be a significant quality-of-life improvement for the developer community. It would enable us to fully utilize the powerful MCP ecosystem that Cursor has helped create.

Thank you for considering this request, and I look forward to hearing thoughts from both the team and community!

Best regards,
The Community

[condor]

Hi @TylerAustinW

Thanks for the post!

Here are some details from my own usage:

• Currently the MCP tool limit is 40 tools.
• They can be enabled and disabled by clicking on each tool name in the MCP settings.

[TylerAustinW]

This is far from what I’m discussing. I understand you can disable and enable them. This is far from the point of my post.

[deanrie]

Hey, thanks for your request. We’ll consider it, but here’s the current situation:

Increase the MCP tool

The 40 tool limit (Cursor – Model Context Protocol) is actually there for a good reason - if we increased it, the AI would struggle to effectively choose between all the available tools We’re working on a better system for the AI to intelligently select the right tools. For now, the best approach is to manually disable any tools you don’t need within your MCP server to stay under the 40 tool limit This way you can ensure the tools you actually need are available and working effectively

[therealJMT]

somewhat related to this request, is there a way to have different mcp tools for different projects/repos?

Especially for supabase where I have to put in my project name and my access token in the mcp.json I have to manually change that everytime I switch projects.

My wish/request would be to have the mcp.json in the repo under .cursor/mcp or something like that. Is there a way to achieve this currently or are there any plans to have specific MCP connections for specific projects?

[condor]

Hi @therealJMT yes you can create the same mcp json file within .cursor folder in. your project.

Cursor – Model Context Protocol

[algis]

When Cursor forwards 40+ raw MCP tools, the LLM wastes context judging tools, so latency increases and precision drops. Disabling tools manually is tedious and error-prone.
Alternatively: The paper “RAG-MCP: Mitigating Prompt Bloat in LLM Tool Selection via Retrieval-Augmented Generation” (https://arxiv.org/abs/2505.03275) embeds every tool’s metadata into a vector index and retrieves only the K most relevant entries before prompting. Authors report >50 % token cuts and ~3× higher tool-selection accuracy.

Two Practical Paths

1. Raise the cap – simplest to ship but keeps prompts fat and costly.
2. Retrieval proxy – place an external proxy that does RAG-based pre-selection and exposes just high-level endpoints. This flow is already implemented in the open-source mcpproxy-go (https://github.com/smart-mcp-proxy/mcpproxy-go/) if you need relief today.

[fusiondev]

Yeah this seems limiting. You should not have to worry about adding more tools. Am i supposed to toggle on and off? I only get it to call tools when i say so?

[condor]

In the first implementation of MCPs you could toggle MCPs on/off but not tools. MCP servers provide information on the MCP capabilities and this has to be included in each AI API request.

This leads to:

• Higher consumption of tokens as each API request has to include higher amount of information
• Errors in AI responses as increased context with task unrelated information confuses AI.
• Potential security issue from exposed access to sensitive information or destructive commands.

Therefore toggles for MCP tools have been added to allow you to avoid both cases.