MCP 90-Tool Limit: Is Catalog Size the Real Bottleneck?
No, MCP does not define a universal break point at 90 tools. A server or client may become difficult to use around that size, but the real bottleneck is usually how tools are discovered, described, selected, and routed—not a fixed MCP limit.
What the 90-tool claim means
MCP, the Model Context Protocol, is an open protocol for connecting AI applications to external tools and data sources. In MCP, a server can advertise tools and provide their names, descriptions, and input schemas; a client can then make those tools available to a model or another interface. The protocol’s basic tools model does not prescribe a maximum of 90 tools.
The number may still appear in discussions because a particular application, model workflow, or integration can behave poorly once a large catalog is loaded. That observation is not the same as a protocol guarantee. One client might handle hundreds of tool definitions by filtering them, while another may struggle with a much smaller set if descriptions are long or selection is unreliable. “Breaks at 90” should therefore be treated as a report about a specific setup until its cause is measured.
How MCP tool discovery works
At a high level, an MCP client connects to one or more servers and learns what capabilities they expose. A tool definition includes a name, a description, and an input schema. The model or surrounding application uses this information to decide which tool to call, and the client sends the call to the server. The server returns a result for the client to handle.
That sequence matters: a large catalog creates work before any tool is called. The application has to retrieve or hold definitions, make useful ones available to the model, and choose among similar candidates. If every tool is presented at once, the catalog can consume context and make selection harder. If the client supports search, filtering, or staged discovery, the model may see only a relevant subset.
MCP’s protocol mechanics and an application’s tool-selection strategy are separate concerns. The protocol describes how capabilities can be exposed and invoked; it does not ensure that every host will rank, summarize, or present a huge catalog effectively.
Where the real bottlenecks tend to be
- Context and prompt size: Every visible definition uses space. Long descriptions and large input schemas can matter more than the raw number of tools.
- Ambiguous choices: Tools with overlapping purposes—such as several ways to search, fetch, or update the same kind of record—make the correct selection less obvious.
- Weak descriptions: A vague name or description gives the model little basis for choosing correctly, even when the catalog is small.
- Client behavior: Hosts differ in how they load definitions, display them, filter them, and handle calls. A limitation in one client should not be assumed to apply to all MCP clients.
- Server and network performance: Slow discovery, slow tool execution, timeouts, or a server-side failure can look like a catalog limit even though the number of definitions is not the cause.
- Model selection quality: A model can overlook the right tool or choose a near match. More available choices can expose this weakness, but the exact threshold depends on the model and task.
For example, 100 short, clearly distinct tools grouped behind a searchable interface may be easier to use than 30 long, overlapping tools that are all placed in the prompt. A single “search records” tool with a precise schema may also be easier to select than several vaguely described search tools.
How to diagnose a catalog problem
Before trimming a catalog based on a reported number, identify which stage is failing. Does the client fail to connect or list tools? Does it list them but omit some from the model’s context? Does the model choose the wrong tool? Does the call reach the server and then time out? Those are distinct problems and require different fixes.
- Reproduce with a known task. Use a request that should clearly match one tool, and record whether the tool is listed, selected, called, and completed.
- Compare small and large catalogs. Keep the client, model, task, and server behavior the same while changing only which definitions are exposed. This helps separate catalog effects from unrelated changes.
- Inspect definitions. Check description length, duplicated or confusing names, schema complexity, and whether each tool has a distinct purpose.
- Measure the failing stage. Check application logs and server responses where available. A model-selection error is not a server execution error, and neither proves a protocol-level cap.
- Test discovery strategies. If supported, expose tools by task, search for relevant tools, or load a smaller group on demand. Confirm that the chosen approach still lets users reach the needed capability.
A useful diagnosis reports the exact client and server, the number and size of definitions, the task, and the observed failure. Without that context, “it breaks at 90” is not a reproducible technical limit.
Designing a larger catalog for usability
When a catalog is hard to navigate, improve its organization before assuming that MCP itself is the obstacle. Use concise, distinctive names and descriptions that state what a tool does and when it is appropriate. Keep schemas no more complicated than the operation requires, and avoid exposing several tools that differ only in unclear ways.
Where the host permits it, use progressive discovery: show a relevant group first and make other tools discoverable when needed. Grouping can follow user tasks or domains, such as “read customer data” and “update customer data,” rather than an internal implementation structure that means little to the caller. Keep destructive or consequential actions especially explicit, and make required inputs and effects clear.
Do not solve selection trouble by silently removing tools users depend on. A smaller catalog can be easier to navigate but can also hide useful capabilities or force awkward workarounds. Test representative tasks, including cases where two tools are plausible, and verify that the intended tool remains discoverable.
Frequently Asked Questions
Does MCP have a 90-tool limit?
No universal 90-tool maximum is defined by MCP’s tools model. A particular client, model workflow, or server may have its own practical constraints, so check the implementation and reproduce the reported behavior.
Why do more tools make an AI agent less reliable?
A larger set can use more context and increase the number of plausible choices. If descriptions overlap or are unclear, the model may select the wrong tool. Filtering and better tool definitions can help, but results depend on the host and task.
Is the problem caused by MCP or by the model?
It could be either, or neither. A protocol connection or listing failure points to a different stage than a model choosing the wrong tool. Check whether the tool was discovered, selected, invoked, and completed before assigning a cause.
How many MCP tools should a server expose?
There is no universally correct count. Expose the capabilities users need, make their purpose distinct, and use filtering or staged discovery when the client supports it. Evaluate usability with real tasks instead of targeting an arbitrary threshold.
Will splitting tools across MCP servers fix the issue?
It may help if the client can connect to and select among servers in a way that reduces the tools visible for each task. It will not automatically fix vague descriptions, slow execution, or a host that still loads every definition together.
The practical answer
A 90-tool catalog is not inherently broken, and MCP does not set that number as a hard boundary. Treat the claim as a symptom to investigate: find whether the failure is discovery, context use, tool choice, client behavior, or server execution. In practice, clear definitions, task-based filtering, and reproducible tests are more useful than treating 90 as a magic cutoff.
Related
Method: the standard formula for this calculation, rounded as each result states. See how the calculators work or report an error.