How many tools is too many for one MCP server, and how do you deal with tool bloat?
Quick Answer
There's no hard protocol limit, but practically, every tool's name/description/schema consumes tokens in the model's context on every turn, and having many overlapping or rarely-used tools measurably hurts the model's ability to pick the right one — both by increasing context cost and by adding decision noise. Common mitigations: split a large API surface into multiple, narrowly-scoped tools instead of one tool with a dozen optional modes; group related servers so a host only loads tool sets relevant to the current task; use the tools/list pagination cursor for genuinely large catalogs; and for very broad integrations, consider exposing a smaller number of "meta" tools (e.g., one search plus one get_by_id) rather than one tool per underlying API endpoint. The general guidance is to keep an individual server's exposed tool count in the range a model can meaningfully reason about — typically well under a few dozen — rather than mechanically wrapping an entire API 1:1 into tools.
Detailed Answer
It's tempting to wrap an entire REST API 1:1 into MCP tools — one tool per endpoint. In practice this backfires quickly.
Why more tools isn't free
Every tool's full definition (name, description, JSON Schema) is included in the model's context on essentially every turn where tools are available, whether or not that turn uses them. A server exposing 80 near-identical CRUD tools:
- Burns a meaningful chunk of the context window before the conversation even starts.
- Makes tool selection harder for the model. More semantically overlapping options increase the chance of picking a plausible-but-wrong tool.
- Makes maintaining good, differentiated descriptions much harder at scale. 80 descriptions are far more likely to blur together than 8.
Practical mitigations
- Consolidate around user intent, not API endpoints. Instead of
create_issue,create_issue_with_labels,create_issue_in_project, expose onecreate_issuetool with optional parameters covering all three cases. - Prefer a small number of general tools over many narrow ones for broad domains. A
search(query, filters)plusget_by_id(id)pair often covers what would otherwise be a dozen single-purpose lookup tools. - Scope servers narrowly by task, and let the host/user choose which servers are active for a given session, rather than one server trying to expose everything the API can do.
- Use
tools/listpagination (acursorin the request,nextCursorin the response) for genuinely large catalogs, so a client isn't forced to load the entire set into one tool-selection prompt.
The rule of thumb
If you can't write a distinct, non-overlapping one-sentence description for every tool on your server, that's usually a sign some of them should be merged into a single, more flexible tool with optional parameters instead.