Request: Increase MCP Tools Limit for Enhanced Development Workflow

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:
    • Free users: Current limit
    • Pro users: Higher limit (25-30 tools)
    • Enterprise users: Even higher or unlimited
  3. Dynamic Loading: Allow selective tool loading/unloading during development sessions
  4. Configuration Options: Let users configure which tools are most critical for their workflow

Impact on Community

This enhancement would:

  • :white_check_mark: Improve developer satisfaction and productivity
    • :white_check_mark: Better leverage the growing MCP ecosystem
    • :white_check_mark: Support more complex development workflows
    • :white_check_mark: 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

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.

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.

1 Like

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

1 Like

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?

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

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.
1 Like

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?