MCP Server Tool Count Tested: From 5 to 100, Accuracy Doesn't Drop — It Actually Holds

Why Everyone Tells You to Write Fewer Tools

When it comes to MCP server design, the most popular advice is "fewer tools is better." One developer read through 91 sources to investigate — 21 official docs, 28 vendor blogs, 20 independent blogs, 2 forum threads, and 20 papers — all the way through. The result: 38 sources recommended trimming tools, 22 recommended controlling the visible tool set through search or lazy loading, 8 recommended code mode (running code with one or two tools), and not a single one argued for exposing every tool.

20 sources gave specific numbers: Workato said 5-8, Phil Schmid said 5-15, OpenAI said no more than 10 per namespace and no more than 20 total, Gemini and Speakeasy said 10-20, Claude's docs said 30-50, and Archestra even claimed "40 is the inflection point." But of those 20 numbers, only 3 came from the authors' own measurements.

Two frequently cited claims don't hold up: "models break down at 30 tools" traces back to the RAG-MCP paper, which actually counted the number of MCP servers in the prompt, not tools; and "Cursor won't accept more than 40 tools" stopped being true once the limit was removed in January 2026. Of the 91 sources, 46 were subjective opinions, 8 cited others secondhand, and 37 performed some kind of measurement — but only 10 actually measured the relationship between tool count and accuracy: 7 papers, GitHub Copilot (cutting from 40 tools to 13 raised accuracy by 2-5 percentage points), LangChain, and one informal test on a 1.7B small model.

That's the crux of the problem: everyone says it, but almost nobody has tested it themselves.

MCP (Model Context Protocol) is a protocol open-sourced by Anthropic in late 2024 to let AI applications connect to external tools, data sources, and prompt templates in a unified way. In MCP's architecture, an MCP server exposes a set of "tools" to clients (such as Claude Code, Cursor, Codex CLI), each defined by a name, description, and parameters specified via JSON Schema. When starting a conversation, the client stuffs these tools' metadata into the model's context window in some form, and the model uses that to decide whether to call one, which one, and with what arguments. So "more tools means longer prompts and more mistakes" became an intuitive worry, giving rise to the rule of thumb that "fewer tools is better." But there's more than one way to inject the tool list: some clients write every schema into the system prompt at once, some inject only names and let the model retrieve schemas on demand, and some keep schemas out of the prompt entirely, having the model write code to query them. Understanding these differences is the prerequisite for understanding this article's conclusions on cost and accuracy.

Testing Method: 1,932 Runs Across Three Clients

The developer built a fake server with 100 realistic file and document tools, with names and schemas written to look real. Some were deliberately designed to be confusing, like pdf_compress, pdf_optimize, and image_compress. The server also had a grouped variant — 7 tools covering 50 operations — and a vaguely named variant. None of the tools actually touched files; the server's call log was the judge.

The test tasks were 18 tasks with known answers, 10 of which were ambiguous. Tool count ranged from 5 to 100 (5, 10, 20, 30, 40, 50, 75, 100), each condition run twice, for 1,932 total runs. The three clients were: Claude Code (Opus 5.5, with tool search on and off), Codex CLI (GPT-6.1-sol), and Antigravity (Gemini 3.1 Pro), each on its own subscription. All measurements, result CSVs, and raw logs for every run are public on GitHub.

The key point of this methodology: the server performs no real operations, so "correctness" is determined entirely by whether the model called the right tool, eliminating noise from execution results.

ToolSearch refers to a mechanism some clients provide for loading tool schemas on demand. When there are many tools, stuffing every tool's full JSON Schema into the prompt quickly burns context and drives up cost. ToolSearch's approach: list only tool names in the prompt (sometimes with a one-line description), and once the model decides it needs a tool, it first calls a special search/load tool to pull that tool's schema into context, then makes the actual tool call. In this article, Claude Code has this mode on by default, so every run shows exactly one ToolSearch call, and the model can pick between similar names based on names alone. This mechanism is the root cause of the divergence between the "search on" and "search off" cost curves, and it explains why search on is actually more expensive when tool counts are low — that extra call itself has overhead.

Core Finding: Accuracy Doesn't Drop with Tool Count

The conclusion was unexpected: every run using individual tools, from 5 tools to 100 tools, across all three clients and both Claude Code modes, was completely correct. That includes every ambiguous task, and the 50 extra confusing tools added at 75-100 tools.

On Opus 5.5, GPT-6.1-sol, and Gemini 3.1 Pro, "fewer tools means more accuracy" did not appear anywhere in the 5-to-100 range. This matches a warning from the survey: the degree of performance degradation is highly dependent on the specific model. In other words, those "it breaks at XX tools" claims likely come from older, smaller models — or were never tested at all.

Claude Code's tool search never hid the correct tool. Every run made exactly one ToolSearch call, as the first action, then selected a tool by exact name. The model could choose between similar names before reading any schema, based on tool names alone.

The Real Cost: Huge Gaps Between Clients

Accuracy stayed the same, but cost varied greatly. And cost depends on how the client loads tools, not on the model itself. Here's each client's input token consumption at different tool counts (average per run, 36 runs, all completely correct, so the table reflects cost only):

Client	How tools reach the model	First call: 5/50/100 tools	Per run
Claude Code, search on (default)	Names only, schemas loaded on demand via ToolSearch	3.9k / 4.6k / 5.4k	13.8k / 17.4k / 19.9k
Claude Code, search off	All schemas injected into the prompt	4.1k / 11.7k / 20.2k	9.3k / 27.9k / 48.6k
Codex CLI	Code mode: schemas don't enter the prompt, the model searches with code	13.2k constant	45.3k / 61.4k / 78.2k
Antigravity (Gemini 3.1 Pro)	Names only, schema files opened on demand	3.8k / 4.1k / 4.3k	15.7k / 20.5k / 18.6k

In Claude Code, tool search is the most critical switch. It's on by default: only tool names enter the prompt, and the model loads the needed schema through one ToolSearch call. That extra call makes it more expensive than full loading below about 19 tools, and cheaper above 19 — at 100 tools it uses 59% fewer input tokens per run.

But fewer tokens doesn't equal cheaper. At list price, at 100 tools, search on costs $0.047 per run, versus $0.038 with search off. The reason is that cached input is cheap, and search adds an extra call. Search saves context space, not money.

A cautionary detail: early in the experiment, the author accidentally disabled Claude Code's tool search due to an isolation flag, so the first reported "search off" data was actually mislabeled. A single flag made the first-call cost differ by 4x.

Code mode is another approach to controlling tool visibility: instead of letting tool schemas enter the prompt, give the model one or two general "write code / execute code" tools, and let the model write code to enumerate, retrieve, and call the underlying tools. This way prompt size is nearly independent of total tool count, at the cost of requiring multiple rounds of code interaction to complete a single call. In this article, Codex CLI uses this mode, with the first call holding steady at 13.2k tokens, but total input per run rising significantly with tool count (45.3k to 78.2k). Note that cached input is typically priced far below uncached input, so "fewer input tokens" doesn't automatically mean "a smaller bill" — this is precisely why Claude Code with search on saves 59% of tokens yet costs more at list price.

Grouping Strategy: Helps One Client, Hurts Another

When loading all schemas fully (Claude Code search off), the cost of 7 grouped tools equaled 14 individual tools, at 100% accuracy. But under Claude Code's default search-on mode, grouping barely mattered: 16.1k input tokens per run, versus 17.4k for 50 individual tools. Grouping only shows clear benefits when schemas are fully injected.

Antigravity was the only place in the entire experiment where accuracy dropped, falling to 89%. Gemini skipped reading the multi-operation tool's schema, guessed operation names like delete, help, fake_op, and incorrectly executed 3 times. This shows grouped tools can actually add risk for some clients — the model needs to read the schema first to know what operations exist, and it might guess without reading.

Impact of Vague Naming: Depends on the Client

In the vague naming variant, the developer kept the same 100 tools and the same descriptions, only giving tools arbitrary names: optimize_file, optimize_document, process_image, combine_files, handle_pages.

Accuracy stayed the same: all 276 runs were correct, with no wrong tools executed. Descriptions determined the answer.

But in scenarios where the model sees names first, names determine the path to the answer. Under Claude Code search-on mode, honest names led the model to precisely load the needed schema in 69 of 72 runs; with vague names, only 7. The model fell back to keyword search, and at 100 tools the number of schemas loaded per run rose from 1.6 to 7.6 (one run loaded 23), with input growing 21%. Gemini opened the wrong tool's schema first in 34 of 72 runs, and probed the wrong tool with empty arguments 10 times. On a real server, if a tool has no required parameters, those empty calls would execute. Gemini's input grew 38% at 100 tools.

The most misleading names included: "3 JPGs into one PDF" led to combine_files (which actually merges PDFs), "shrink a PNG" led to optimize_image, and pptx and docx to PDF got confused between convert_file and convert_document.

Naming Conventions and the 64-Character Budget

Names callable across all clients can only contain letters, numbers, underscores, and hyphens, up to 64 characters. The Claude API rejects names containing dots, and some clients rename dots on their end. Those 64 characters are shared: when Claude Code calls your tool, it uses the format mcp__<server>__<tool>, so a long server name eats into the tool name's budget.

There was another unexpected finding: Gemini's API rejected a tool schema containing an integer enum in one eager-loading run.

The dot-in-tool-name problem deserves its own note. Many tools in the MCP ecosystem are conventionally written as namespace.action (like files.convert), but the Claude API outright rejects tool names containing dots, and some clients locally replace dots with underscores or hyphens before forwarding. This means the same server can appear with different tool names across clients, which in turn affects the model's name matching and log readability. Add Claude Code's mcp__<server>__<tool> call prefix, and the server name itself also consumes part of that 64-character budget — so naming conventions aren't just a style question, but a hard constraint on cross-client compatibility.

Practical Advice

Based on this measurement, the author's recommendations differ significantly from mainstream opinion:

Don't cut tools for accuracy's sake. On frontier models, 5 to 100 tools showed no accuracy difference. The reason to trim or lazy-load is cost and context, not accuracy.

Name tools by action and object, not with generic verbs. The name is now the first piece of information the model reads, and vague names bring extra schema reads and the risk of wrong calls.

Write descriptions the model can distinguish. This is the key to maintaining 100% accuracy — even with similar tools and vague names, good descriptions still let the model make the right choice.

Don't group blindly. Test in the client your users actually use, because grouping affects Claude Code and Gemini completely differently.

Measure your own server. The worklore story the author provides includes the same benchmark steps, so your agent can run them directly against your server.

Limitations

This experiment has its boundaries: it used fake tools and a single domain (file operations); it only tested three frontier models, not smaller or older ones (and the surveyed sources that did measure happened to focus on those models); the tasks were direct tasks with no long-chain reasoning, so context-crowding effects weren't measured; vague names were only tested alongside good descriptions, not double-vague cases; token counts include each client's overhead; some scales weren't run for every channel, and Codex's vague naming channel only got 60/72 runs due to usage limits; and this is a snapshot from October 2026.

Even so, this remains one of the most systematic public measurements of MCP tool counts to date. It at least shows one thing: when designing an MCP server, rather than following the "fewer is better" rule of thumb, do a real measurement on the client your own users use.

One-line Summary

1,932 runs tested: accuracy holds from 5 to 100 tools, and cost differences depend on how the client loads them.

Paragraph Summary

After reading through 91 sources, one developer found that of the mainstream "fewer MCP tools is better" advice, only 10 sources actually measured the relationship between tool count and accuracy. So he built a fake server with 100 tools and ran 1,932 tasks across three clients — Claude Code, Codex CLI, and Antigravity. The conclusion was unexpected: from 5 tools to 100 tools (including 50 confusing ones) on frontier models, accuracy stayed completely unchanged, and ambiguous tasks were all correct too. The real differences were in cost: Claude Code with tool search on saves 59% of input tokens at 100 tools, but because of an extra call it's actually more expensive at list price; grouped tools only pay off when schemas are fully injected, yet in Antigravity they dragged accuracy down to 89%; vague naming doesn't affect accuracy, but makes models that pre-select by name load more schemas and probe the wrong tools. Based on this, the author advises: the reason to cut tools is cost and context, not accuracy.