Repository navigation
How many servers and tools it can handle? #1251
Pre-submission Checklist
Question Category
Your QuestionIf I’ve got millions of tools across thousands of servers, the MAX_TOOLS limit is a looming question—where does it all start to collapse for the client? It feels like the bottleneck is more on the LLM side? I’m toying with the idea of structuring it like a RAG pipeline—embedding, vectordb, hierarchical chunking with nodes. But even then, I’m skeptical. RAG might not be robust enough to handle. It’s a gamble, and I’m not entirely convinced it’ll hold. Two key issues: Any help will be appreciated. Edit: When a query comes in, does it first search for the relevant servers and then look for the tools within them, or does it go straight to searching for the tools directly? |
Replies: 10 comments 4 replies
|
Not an answer for your question but I have been exploring MCPs myself and I came across something called OctoTools last week. |
|
I think this is a broader question beyond just MCP; it applies to any agentic system. LLMs (currently) can easily become confused when handling excessively large and broad contexts. Therefore, it is recommended to break agents down into mission-specific units and manage them within a hierarchy. This way, each agent can focus on specific tasks using dedicated tools, improving its effectiveness. From this perspective, providing LLMs with millions of tools can make it difficult for them to perform their tasks correctly. |
|
The more tools you add, the more information you add to the context and overload the model with informations. Don't forget to use an MCP you need to add it to the context and an effective tool have a short description explaining the arguments otherwise Sonnet for example get confused how to use the tool or pass wrong parameter types. |
|
Around 50 you'll start noticing suboptimal responses. Here is my relevant idea on how to dynamically filter and exclude tools, Please vote for the idea to update mcp client and server specifications. |
|
With my experience on building a MCP proxy I can say that over 30 is confusing most of the time. It is better to use a proxy and disable the ones that you don't need at your current task. |
This comment was marked as spam.
This comment was marked as spam.
This comment was marked as spam.
This comment was marked as spam.
|
Relevant real-world data point on the 'too many tools' problem. We've been running ruflo/claude-flow which exposes 300+ MCP tools to Claude. After a deep audit, we found:
This is the worst-case scenario for the question you're asking: a single MCP server that registers 300+ tools where 97% do nothing, bloating context and confusing the LLM's tool selection. Practical lesson: MCP servers should only expose tools that actually execute something. Stub/planned tools should NOT be registered — they waste context tokens and degrade selection quality. GitHub's approach of breaking tools into toolsets (discussed in github/github-mcp-server#1182) is the right direction. Full audit: Independent Audit (Gist) |
|
We've limited Discussions in this repository to meeting notes and are closing this thread. To continue the conversation, pick a channel from Contributor Communication. Thanks for posting. |
|
I've created a clear-your-tools app that injects only relevant tools based on the user prompt to reduce the number of tools. unreal with uv tool install 'clear-your-tools[all]' |
The more tools you add, the more information you add to the context and overload the model with informations.
There is reported issues when reaching 80-90. Using currently 30-40 no issues but trying to separate the MCP's by groups to disable them when not needed.
Don't forget to use an MCP you need to add it to the context and an effective tool have a short description explaining the arguments otherwise Sonnet for example get confused how to use the tool or pass wrong parameter types.