There’s no fixed limit on how many tools an MCP server can expose — the protocol doesn’t cap it, and a client will happily list a server with 300 of them. The limit that matters isn’t technical, it’s the model’s: every tool definition gets loaded into context before the model does anything useful, and past a certain point more tools make the model worse at picking the right one, not better. Most teams find that out the hard way, after a server is already live. Here’s how to think about the number before you get there.

Why tool count is a real cost, not just clutter

Every tool a server exposes — its name, description, and full JSON Schema — gets sent to the model as part of the request, on every turn, whether or not that tool ends up being called. A handful of tools is free. A few dozen starts to add up. A few hundred means a meaningful chunk of the context window is spent on tool definitions before the conversation itself begins, which leaves less room for the actual task, and gives the model more near-duplicate options to choose between when it decides what to call.

That second effect is the one people underestimate. It’s not just token cost — it’s selection accuracy. A model picking from 8 clearly-named tools rarely calls the wrong one. A model picking from 150, several of which are subtly different variants of the same operation, calls the wrong one far more often. If you’ve read our guide on writing MCP tool descriptions, this is the same problem at a different scale: a great description helps the model use one tool correctly, but no description fixes a list so long the model never seriously considers most of it.

Where the number tends to come from

Almost nobody sits down and designs a tool count on purpose. It’s usually a side effect of how the server got built:

  • One tool per API endpoint. The most common source. Auto-generating a server from an OpenAPI spec — the approach we cover in turning an API into an MCP server — defaults to mapping every operation to a tool. A REST API with 200 endpoints becomes a 200-tool server unless someone curates it down.
  • CRUD symmetry. If “create” is a tool, teams often add “read,” “update,” “delete,” and “list” for consistency, even when an agent realistically only ever calls two of the five.
  • Every internal service becomes a tool. Wrapping several internal microservices behind one MCP server, one tool per service method, compounds fast — nobody planned for 150 tools, it just accreted service by service.

None of these are wrong reasons to have a tool. They’re just not reasons to expose it to a model without asking whether an agent will ever plausibly need it.

A rough sense of scale

There’s no single correct number, and anyone quoting one as a hard rule is guessing. But the shape of the tradeoff holds across most setups:

  • Under ~20 tools: comfortable. A model handles this without much selection difficulty, and you can afford tools that overlap slightly for convenience.
  • ~20–50 tools: still workable, but this is where naming and descriptions start to matter a lot — ambiguity that was harmless at 10 tools starts causing wrong calls here.
  • 50+ tools on one server: worth actively curating. At this range, most teams either split the server by domain, or accept that the model will only reliably use a subset of what’s exposed.

For context on where the ecosystem draws this line in practice: gate’s MCP Builder caps a generated server at 60 tools when converting an OpenAPI spec, and gate’s free security scanner scans up to 75 tools per server before truncating the report. Neither number is a claim about the “right” size — they’re practical ceilings chosen because past that point, generating or scanning more tools stops being useful faster than it stops being possible.

How to cut a long tool list down

Curating rarely means picking favorites at random. A few approaches that hold up:

  • Ask what an agent actually needs, not what the API offers. An API built for a full admin dashboard exposes far more than a task-focused agent will ever call. Start from the agent’s job, not the API’s surface.
  • Collapse near-duplicates. get_invoice, get_invoice_by_id, and fetch_invoice_details are three tools doing one job. Keep one, well-named and well-described.
  • Split by domain instead of exposing everything at once. A billing server and a support-ticket server, each with 15 tools, is easier for a model to use well than one 30-tool server mixing both. It also lets you apply different access rules to each — billing tools behind stricter approval than read-only ticket lookups.
  • Drop rarely-needed admin operations entirely. They can stay in the underlying API without ever becoming a tool. Exposing a capability isn’t free just because the code to call it already exists.

The governance side of a long tool list

A large tool list isn’t just a selection-accuracy problem, it’s a review problem. Vetting a 12-tool server — reading every description, checking which ones write versus read, deciding what needs approval — is a five-minute task. Doing the same for 200 tools is not, and in practice it rarely gets done properly, which is exactly how a destructive tool ends up sitting unreviewed next to a harmless lookup. Our MCP server vetting checklist covers this in more depth, but the short version is: the longer the tool list, the more a per-tool allow/ask/block policy matters, because eyeballing the whole list stops being realistic. That’s the kind of governance an MCP gateway sits in front of a server to provide, whatever the tool count ends up being.

The short version: tool count isn’t a vanity metric, it’s a design decision that trades context budget and selection accuracy against completeness. Default to curating down from an API’s full surface, not mirroring it, and treat a tool list that’s grown past a few dozen as a signal to split or prune — not a badge of how capable the server is.

The bottom line

More tools is not more capability, past a fairly low threshold — it’s more context spent and more chances for the model to pick wrong. Whether you’re hand-building a server or generating one from an API, the question worth asking isn’t “can I expose this operation as a tool,” it’s “will an agent doing this job actually need it.” Browse the MCP server directory and you’ll notice the pattern yourself: the servers people reach for aren’t the ones with the longest tool list, they’re the ones where every tool earns its place.