How many tools can you give an AI agent through an MCP server? The popular rule of “no more than 10–20” is barely based on measurements. In a published benchmark from October 15, 2026 (3,336 runs), top models in Claude Code, Codex CLI, and Antigravity picked the right tool every time across runs with separate tools — with tool sets ranging from 5 to 100 — while cheaper models rarely made mistakes. The number of tools affects token cost more than accuracy, and the choice of the right tool is driven by clear names and descriptions. The limit should be set based on measurements on your own server and with your own models.
Prepared by AIrassvet October 16, 2026 based on the research published on Habr on October 15, 2026, with an open dataset on GitHub, and on the Model Context Protocol and OWASP documentation. It is intended for developers and architects of AI agents, IT directors, and product owners who design MCP servers or connect agents to enterprise systems. We did not repeat the experiment: all figures belong to the author of the research, while the business takeaways and checklist are the editorial team’s methodology. AIrassvet is not affiliated with the researcher or the developers of the clients mentioned; the section at the end of the article describes the publisher’s services.
Contents
- At a glance
- Where the tool-count limit came from
- How the benchmark was run
- What the benchmark showed with tool sets up to 100 tools
- What each tool costs
- Grouping, names, and cheaper models
- MCP server design rules
- How to test your own server
- FAQ
- Source materials and verification method
At a glance
- The “10–20 tools” limit did not come from measurements. Of 91 sources reviewed, 20 mentioned a specific number, but only 3 of those numbers were based on the authors’ own measurements.
- Accuracy did not drop on top models. Opus 5.5, GPT-6.1-sol, and Gemini 3.1 Pro chose the correct tools in every run with separate tools — from 5 to 100, including ambiguous tasks and similar names.
- Costs rise, not error rates. In Claude Code without tool search, each additional tool added about 429 input tokens per run, and at 100 tools a run consumed 48.6K tokens.
- Names and descriptions matter more than quantity. Unclear names did not cause mistakes, but they did make models read more schemas, and Gemini sometimes called the wrong tool with empty arguments.
- The number of tools is not the same as agent permissions. You should limit risky actions first, not the length of the list.
Where the tool-count limit came from
MCP tool — a function that an MCP server offers to an AI agent: “find a file,” “create an invoice,” “check order status.” The agent sees the list of tools, their names, and their descriptions, and decides which one to call.
The researcher reviewed 91 materials on MCP server design: 21 sections of official documentation, 28 vendor blogs, 20 independent blogs, 2 forum threads, and 20 academic papers (Habr, 10/15/2026). What they recommend:
- 38 sources recommend reducing the number of tools;
- 22 suggest keeping the visible set small through search or deferred loading;
- 8 recommend a “code mode,” where one or two tools run code;
- no one recommends exposing everything at once.
20 sources give specific numbers, and they vary widely: 5–8 (Workato), 5–15 (Phil Schmid), fewer than 10 per namespace and fewer than 20 (OpenAI), 10–20 (Gemini, Speakeasy), 30–50 (Claude documentation), and “40 is the tipping point” (Archestra). Only 10 of the 91 sources measured the relationship between tool count and accuracy.
The two most cited claims were not confirmed. The phrase “models break down at 30 tools” traces back to the RAG-MCP article, which counted the number of MCP servers in the prompt, not the number of available tools. The “Cursor does not accept more than 40 tools” limit stopped applying in January 2026.
How the benchmark was run
Research methodology (Habr, GitHub data):
| Parameter | Value |
|---|---|
| Server | Test server, 100 plausible tools for files and documents; some names are similar (pdf_compress, pdf_optimize, image_compress) |
| Variants | Separate tools; 7 grouped tools for 50 operations; vague names |
| Tasks | 18 tasks with known answers, including 10 ambiguous ones; 2 attempts each |
| Dataset sizes | 5, 10 … 50, 75, and 100 tools |
| Clients and top models | Claude Code (Opus 5.5), Codex CLI (GPT-6.1-sol), Antigravity (Gemini 3.1 Pro) |
| Cheaper models | Claude Haiku 5.5, GPT-Reserve, Gemini 3.8 Flash |
| Volume | 1,932 runs on top models and 1,404 on cheaper models |
| Verification | By server call logs; no actual file operations were performed |
Important detail: by default, none of the three clients puts all tool schemas into the prompt. Claude Code and Antigravity show the model only the names and load the needed schemas on demand; Codex searches for definitions in code. As a result, the model chooses a tool based on its name first.
What the benchmark showed with tool sets up to 100 tools
On top models, every run with separate tools was fully correct — from 5 to 100 tools, in all three clients, in Claude Code both with tool search and without it. This included ambiguous tasks and 50 additional similarly named tools at sizes 75–100.
This matches the few public benchmarks the author found: the drop in performance depends heavily on the model. In LongFuncEval, when the number of tools grows from 49 to 741, GPT-4o loses about 13% accuracy, while other models lose 40–85%. In MCP-Bench, top models hold up with a hundred extra tools, while weaker models degrade.
Business takeaway: on modern top models, trimming the list to improve accuracy is not necessary within the 100-tool range. But that does not mean this will hold for every model, every domain, and long conversations — we list the limitations below.
What each tool costs
Input tokens are averaged across 36 runs per cell, and all runs were correct (Habr):
| Client | How tools reach the model | Tokens per run: 5 / 50 / 100 tools | Per extra tool per run |
|---|---|---|---|
| Claude Code (Opus 5.5), search enabled by default | Names only, schemas via ToolSearch | 13.8K / 17.4K / 19.9K | ~79 tokens |
| Claude Code (Opus 5.5), search disabled | All schemas in the prompt | 9.3K / 27.9K / 48.6K | 429 tokens |
| Codex CLI (GPT-6.1-sol) | Code mode, schemas are discovered by code | 45.3K / 61.4K / 78.2K | 408 tokens |
| Antigravity (Gemini 3.1 Pro) | Names only, schema on demand | 15.7K / 20.5K / 18.6K | does not increase |
Two takeaways from the study:
- As long as the toolset is small — roughly up to 19 tools — tool search in Claude Code is more expensive because of the extra call than loading all schemas at once. With 100 tools, search cut input tokens by 59%.
- Fewer tokens do not always mean lower cost. By the price sheet, a run on 100 tools with search cost $0.047 versus $0.038 without search: cached input is cheap, while search adds another call.
For a company, this means agent cost depends not only on the model, but also on the client it runs in and how that client loads tools. You need to calculate budget from real logs, not from the number of tools in the documentation. More on distributing tasks across models at different price points is in the article about the model router.
Grouping, naming, and low-cost models
Grouping. When all schemas were loaded (Claude Code without search), 7 grouped tools cost about the same as 14 separate ones, with 100% accuracy. With search enabled, the difference almost disappeared: 16.1K tokens versus 17.4K for 50 separate tools. In Antigravity, accuracy on grouped tools dropped to 89%: Gemini 3.1 Pro did not read the schema for a multi-operation tool, guessed the operation names, and three times executed the wrong one.
Vague names. With the same descriptions, but names like optimize_file or process_image, all 276 runs completed correctly. However, Claude Code with vague names switched to keyword search and read several times more schemas, while Gemini sometimes opened the wrong tool’s schema or tried to call the wrong tool with empty arguments. The test server rejected those calls, but a real one might have executed them.
Technical constraints. Names that any client will accept consist of letters, numbers, _ and - and fit within 64 characters; the Claude API rejects dots. Claude Code calls the tool as mcp__<server>__<tool>, so a long server name eats into the limit. Enumeration values in the Gemini API schema are not accepted — the request with all schemas was rejected outright.
Low-cost models. On Claude Haiku 5.5, GPT-Reserve, and Gemini 3.8 Flash, 1,288 of 1,296 runs with separate tools were correct. GPT-Reserve called the wrong tool in 4 runs starting at 40 tools; three of Gemini Flash’s four misses were API errors caused by the same enum. Low-cost models are more expensive per tool: GPT-Reserve used 655 tokens for each extra tool versus 408 for GPT-6.1-sol and made 2.6 calls per task versus 1.7 at 100 tools. Haiku twice passed incorrect arguments in a three-step chain on grouped tools.
| Scenario | What to watch |
|---|---|
| Top-tier model, up to 100 tools | Accuracy did not drop in the measurement; optimize for cost |
| Low-cost model | Rare wrong-tool calls starting at 40 tools; the number of calls and tokens increases |
| Grouped tools | The effect depends on the model: test in your users’ clients |
| Similar or vague names | More schema reads and a higher risk of wrong calls; name by action and object |
| Older and smaller open models | Not included in the measurement; based on the sources in the review, the drop is most visible on them |
MCP server design rules
The rules below are the editorial team’s methodology based on the study’s findings and security requirements.
- Name tools by action and object:
invoice_create,order_status_get, notprocessorhandle. The name is the first thing the model reads. - Write distinguishable descriptions. For similar tools, state clearly how they differ: “joins PDF files,” “builds a PDF from images.”
- Stay within technical limits: letters, numbers,
_and-, no more than 64 characters including the server prefix; no dots; enums as strings. - Do not group blindly. If you combine operations into one tool, test the result on the models and clients your staff or customers actually use.
- Separate reads and writes. Separate tools for reading and changing data are needed not for accuracy, but for permissions: they make access control and audit review easier.
- Limit dangerous actions, not the length of the list. OWASP identifies excessive agency (LLM06 Excessive Agency) as a separate risk: one extra function with delete rights is more dangerous than a dozen extra read-only functions.
- Trim the list for cost, not by intuition. If tokens are expensive, start with analytics from the live server: which tools are never called, which schemas are read most often.
How to test your server
The study was published together with the report, results.csv, and logs for every run, and the author recommends running the same benchmark on your own server. Test sequence (editorial methodology):
- Create 15–20 tasks with known correct answers, including ambiguous ones and tasks where similar tools are easy to confuse.
- Run them on the models and clients your employees or customers actually use, at least twice each.
- Compare the variants: full set and reduced set, separate and grouped tools, with tool search and without.
- For each variant, record the share of correct calls, wrong-tool calls, incorrect arguments, number of calls per task, and input tokens per run.
- Repeat the measurement whenever you switch models or clients, and when you add new tools.
We covered how to build your own task set for evaluating models in the article "Your Own Benchmark for Choosing an LLM", and how to safely test an agent before launch in the piece on an AI agent sandbox.
Frequently Asked Questions
How many tools can you give an AI agent through MCP?
There is no universal limit. In the October 2026 measurement, top-tier models did not make mistakes with 5–100 tools, while cheaper ones occasionally called the wrong tool starting at 40. The limit should be determined by testing on your own tasks, models, and clients.
Does a large number of tools reduce an agent's accuracy?
In this measurement, no for top-tier models. The drop depends on the model: according to public research, weaker and older models lose accuracy much more noticeably, so their tool list should be checked separately.
Why does cost rise as the number of tools grows?
Tool schemas are included in the model's context. In Claude Code without tool search, each extra tool added about 429 input tokens per run. Clients that load schemas on demand grow more slowly.
Do tools need to be grouped?
Not necessarily. In the measurement, grouping saved almost no tokens when tool search was enabled, and in one client it reduced accuracy to 89%. If you do group them, test the result on your users' models.
How should MCP tools be named?
Use the action and object, letters, numbers, underscores, and hyphens; keep the name no longer than 64 characters including the server prefix and without dots. Similar tools need descriptions that clearly explain the difference.
Is it safe to give an agent one hundred tools?
Safety is determined not by the number of tools, but by permissions. Read and write tools should be separated, and actions involving deletion, money, and external sending should require human approval.
Primary sources and verification method
Method: on October 16, 2026, we read the study on Habr, extracted the methodology, accuracy and token results, and limitations, checked whether the data repository was available, and verified the wording of the excessive privileges risk against OWASP. We did not repeat the AIrassvet experiment or recalculate the raw data from the repository; the design rules, verification order, and situation table are the editorial methodology.
- Habr, 10/15/2026: measurement of 5 to 100 MCP tools in Claude Code, Codex CLI, and Antigravity — review of 91 sources, methodology, accuracy, tokens, grouping, naming, low-cost models, limitations.
- GitHub: report, results.csv, and run logs.
- OWASP: LLM06:2025 Excessive Agency.
The study's limitations, as stated by the author: the tools were test tools, the domain was only one area (files), and six models were used; older and smaller open models were not tested; the tasks were straightforward, and context displacement in long conversations was not measured; vague names were tested only with good descriptions; token counts include client overhead; not all sizes were run in all clients.
How AIrassvet helps design AI agent tools
The toolset determines what the agent can do in your systems, how much each step costs, and what permissions it gets. On the AIrassvet website the directions directly relevant to this task are described:
- developing AI agents integrated with enterprise systems and communication channels, including tool and tool-description design;
- agentic automation of actions in ERP, 1C, and the browser, with tools separated into read and write;
- pre-launch testing: a task set with known answers, checking tool selection and arguments on the required models;
- process auditing: which operations the agent really needs and which of them require human approval.
The first step is to choose one process for which the agent is planned, list the systems and operations it will need, the security constraints, and the criterion by which the toolset will be considered ready.
Bottom line: measure errors and tokens, not tool counts
The rule of "no more than 10–20 tools" turned out to be more a case of mutual citation than a result of measurement. In the October test, top-tier models handled 100 tools correctly, and the number of tools affected token cost more than accuracy.
Practical takeaway: name tools by action and object, write distinct descriptions, separate read and write, and determine the limit by testing on your own models and clients. The first thing to restrict should be the agent's dangerous permissions, not the length of the list.
