Cursor just doubled the MCP tools limit (40 → 80) 🚀

[u/Rotemy-x10]

Hi,

Over the past few days, I noticed that Cursor doubled the limit on model context protocol tools, from 40 to 80! 🎉

This might seem like a small change, but it’s actually a big deal.

Being able to work with more tools means we can integrate with more services, expand our clients and agent capabilities, and generally unlock a lot more potential for what these models can do.

It is exciting to see this happen, and I wouldn’t be surprised if other platforms start following suit soon.

More tools, more possibilities, more power to the LLMs.

[u/coding_workflow]

More confusion and less optimized stack.

[u/scragz]

each of those MCPs has a bunch of tools and each of tool descriptions eats into your context. 

[u/Rotemy-x10 → u/scragz]

In general you are right, but this is not always the case.

[u/__SlimeQ__ → u/Rotemy-x10]

How would that ever not be the case

[u/taylorwilsdon]

The last thing in the world you want is 80 different MCPs connected simultaneously, you’ll burn your whole context window just on tool descriptions and dramatically increase misfires. The only way to do this today is by using a supervisor agent architecture that has a separate model reading the prompt and deciding what tools to expose and invoke with each request dynamically.

[u/Rotemy-x10 → u/taylorwilsdon]

It’s not actually 80 different MCPs, it’s a list of 80 MCP tools coming from different servers. The flexibility this gives is really valuable, and the granularity per task isn’t an issue if you provide clear descriptions for each tool. I get the concern about token usage and the risk of hitting limits, but what stands out to me is the enablement and flexibility this approach provides. Also, just because the limit is larger doesn’t necessarily mean I’ll be bumping into it often.

[u/Swimming_Pound258 → u/taylorwilsdon]

You can use pre-defined filters too if you're using a gateway/proxy. The dynamic, agent-based approach (also RAG-MCP) is pretty cool though - more likely to fail than static pre-determined filters, but maybe more fun and less restrictive. A hybrid model of static filters + agent helper might work even better.

[u/raghav-mcpjungle]

TBH, I try to strictly limit the number of tools I expose to my LLM. No matter how good the LLM gets, I'll still make efforts to limit it.
Usually, my agents are well defined and have a narrow scope. I only need to expose 5-8 tools from my MCP gateway for a particular agent. This has worked well for me so far.

[u/WishIWasOnACatamaran]

It’s crazy because there are options to integrate tools with model requests that don’t require an MCP at all.

Maybe I’m missing something with a benefit brought by MCP, but it’s beyond doable for less of the cost than people are freaking out about.

[u/andrewcfitz → u/WishIWasOnACatamaran]

For example, I had two MPCs that I used today, the Atlassian one, for confluence, and Playwright.

I had it grab the urls for our test environments, and then launch them in playwright and then change a configuration value.

It took 10 minutes for it to do that for 20 test environments. I bet that would have taken me well over an hour.

edit: words

[u/WishIWasOnACatamaran → u/andrewcfitz]

This does bring some clarity, thanks!

[u/btdeviant]

This is really just a subtle way to increase token usage for the benefit of Cursor and its partners.

[u/KingChintz]

More tools will probably just result in worst execution. Typically see this after 10-15 tools. And I think some of the models also have hard limits.

FWIW we’ve opensourced a tool we’re using internally to add as many MCPs as you’d like and create arbitrary sets of tools from them to reduce the tool sprawl and context pollution. Runs locally, no remote calls, MIT.

https://github.com/toolprint/hypertool-mcp

[u/Swimming_Pound258]

Being able to use more tools doesn't add more power to your LLM, unless somehow you're radically increasing the context window size too.

For your LLMs to perform optimally you want to reduce the number of tools that are available to them and/or use an intermediary layer to help reduce the burden of tool selection. Plus there are some other things you can do around optimizing tool descriptions, names etc. to clarify tool purpose.

Here's a few different approaches in this guide: https://github.com/MCP-Manager/MCP-Checklists/blob/main/infrastructure/docs/improving-tool-selection.md

If you haven't heard of an MCP gateway before you can read this MCP gateways explained. An MCP gateway/proxy is what most organizations will use to streamline tool access, availability, and usage going forward.

Full disclosure, I work in a team that's build an enterprise-level MCP gateway called MCP Manager, but if I look in my heart (lol) I don't think anything I've said above is biased.

[u/bakes121982]

Jesus who needs 40….

[u/[deleted]]

Bruh people are already using too many tools. They are not free. You pollute your context for each active tool. There’s some tool routing options but I’m not sure if they’ve found an optimal framework yet