RAG-MCP is a 2025 research framework from Tiantian Gan and Qiyao Sun that treats tool selection as a retrieval problem. Tool descriptions live in an external index, semantic search picks the ones matching the query, and only those reach the model. It reported 43.13% selection accuracy against a 13.62% baseline.

Is there a hard limit on the number of tools an MCP client can expose?

Providers impose their own ceilings rather than the protocol doing it. StackOne's documentation notes that OpenAI caps function definitions at roughly 128 per request. Accuracy degrades well before any of these caps, so a client accepting a tool list is not evidence that the model can use it.

Does a bigger context window solve tool overload?

No. A larger window means the definitions fit, not that the model discriminates between them well. The LangChain results showed models failing on tasks whose tool lists were small enough to fit comfortably, because the difficulty is choosing among similar options rather than storing them.

Do models released in 2026 still degrade with tool count?

The public benchmark numbers here are from early 2025 and o1 already resisted the effect, so newer models plausibly hold up longer. A more recent data point backs that direction: AppSelectBench, submitted in November 2025, put GPT-5 at 63.3% accuracy choosing the right application among 100 candidates, still well short of reliable. Nobody has published a figure at which degradation stops, and the catalogue has grown about 35x since, so measuring the specific deployment matters more than assuming a number.

Should tool descriptions just be written better instead?

Both matter, but description quality has a lower ceiling. Clearer descriptions help a model tell two similar actions apart; they do not reduce the number of candidates it reads per turn. Retrieval addresses the count, and the RAG-MCP result shows the count is what moved accuracy.

How does this apply to an internal agent with only ten tools?

It mostly does not, and that is the useful part. Ten well-separated actions sit under any published degradation threshold. The problem appears when a platform team consolidates several pilots behind one assistant and nobody re-measures the combined surface.

Why AI Agent Accuracy Drops as Tool Count Grows

Agent accuracy falls as the number of tools visible in one turn grows. In LangChain’s February 2025 ReAct benchmark, GPT-4o’s calendar-scheduling accuracy fell to 2% once a task spanned seven domains, while o1 held 71%. RAG-MCP raised tool-selection accuracy from 13.62% to 43.13% by retrieving a shortlist instead of listing every schema.

How many tools can an AI agent handle before accuracy drops?

There is no single hard number, but the published benchmarks put the useful ceiling well below what a modern client will happily connect. Degradation starts when a model has to scan a long list of similar descriptions, and it shows up as wrong-tool calls rather than as an error that gets caught.

Supply has grown far faster than selection has improved. The UK AI Security Institute, working with the Bank of England, analysed 177,436 AI agent tools published between November 2024 and February 2026. A year earlier the public count was around 5,000, and monthly downloads went from 80,000 to 14 million. That is the catalogue enterprise teams now shop in, and publishing a server to the official MCP Registry is routine enough that the growth is not slowing.

Bar chart showing publicly released AI agent tools growing from around 5,000 in late 2024 to 177,436 in February 2026

What did LangChain’s ReAct benchmark measure?

LangChain published its ReAct agent benchmark on 10 February 2025, testing Claude 3.5 Sonnet, GPT-4o, o1, o3-mini and Llama-3.3-70B. It ran the same task with one domain in scope, then with seven or more, and the tool count per domain stayed small: only two scheduling tools plus an email tool.

On calendar scheduling with a single domain, o1 scored 71% and o3-mini scored 68%. At seven or more domains, o1 stayed roughly where it was, o3-mini fell sharply, GPT-4o fell to 2%, and Llama-3.3-70B scored 0% because it stopped calling the send_email tool at all. Same task, same tools, more competing options in the prompt.

Two caveats: these are early-2025 models, and LangChain varied domains rather than raw tool count, meaning unrelated capability in scope is what grows as another system gets connected. The direction still holds with newer models. AppSelectBench, submitted in November 2025, tested application-level tool selection across 100 desktop applications and measured GPT-5 at 63.3% accuracy and GPT-4o-mini at 60.3%. Frontier models resist the effect for longer. They do not escape it.

Why does adding a new tool break tools that already worked?

Tool selection is a discrimination problem, not a lookup. Every new definition adds another candidate the model has to rule out, and enterprise catalogues are full of near-duplicates: three ways to create a ticket, four things called “update record”. Adding a fifth makes the other four harder to pick between.

The failure is quiet. The agent does not report confusion: it calls something plausible and adjacent, the run completes, and the wrong system gets written to. For a Head of AI explaining why a Copilot or Glean pilot works in demo and wobbles in production, this is usually the mechanism, and it is invisible in a latency dashboard.

How many tokens do MCP tool definitions consume?

Enough to dominate the prompt before the model has read the user’s request. StackOne’s documentation gives an illustrative comparison: around 500 tool definitions loaded up front is roughly 150,000 tokens, against roughly 900 tokens for a search-and-execute pair. Exact counts depend on which actions are enabled and which model reads them.

The token bill and the accuracy problem come from the same place, which is worth stating plainly because they get treated as separate budgets. We have written before about why the cost driver is the catalogue loaded rather than the model licence, and why MCP’s 2026-07-28 stateless spec makes catalogues cacheable without freeing up model context. Caching helps the server. The model still reads every definition it is handed.

Does retrieval-based tool selection improve agent accuracy?

Retrieval is the mitigation with published numbers behind it. Gan and Sun’s RAG-MCP paper, submitted 6 May 2025, indexed tool descriptions externally, used semantic retrieval to pick the relevant ones for a query, and passed only those to the model. Tool-selection accuracy went from 13.62% to 43.13%, with prompt tokens cut by more than half.

That is a tripling from a low base on a stress test. It does not make selection a solved problem, but it does show the constraint is what the model reads rather than what a platform can reach.

That result is why our team exposes StackOne’s catalogue through two operations rather than a schema list. Advanced Tool Search gives an agent a search call and an execute call, so 520+ connectors and 32,000+ actions sit behind a prompt footprint that does not grow when the next system connects. On the S1 Search Bench we measure 91.6% first-try accuracy, with 78% average tokens saved. The 78% is measured on tool-heavy actions, so it reads as the good end of the range rather than the typical one.

Two-panel diagram comparing loading every tool schema into the prompt against a search-and-execute surface, with definitions read per turn, token cost, and failure mode for each

What is the difference between loading every schema and a search-and-execute surface?

One puts the whole catalogue in the model’s context window every turn. The other puts a query interface there and fetches definitions on demand. The distinction matters most at scale, because only one of them keeps the prompt flat.

	Every schema in the prompt	Search then execute
Definitions read per turn	All enabled, e.g. 500	2
Prompt cost before reasoning	~150,000 tokens (StackOne docs, illustrative)	~900 tokens (same source)
Effect of connecting one more app	Every existing tool gains a competitor	Prompt unchanged
Failure mode	Wrong-tool call that looks like a prompt bug	Weak search results, visible in the response
Provider ceiling	OpenAI caps function definitions at roughly 128 per request	Not reached

How should an enterprise IT team cap the tools exposed to Copilot, Glean or Claude?

Treat visible tool count as a rollout metric with a named owner, tracked like latency: count what each assistant sees per turn, group tools by task, add search once a catalogue passes a few dozen actions, measure first-try accuracy, and re-measure whenever a new system connects. Those five steps in detail:

Count what each assistant sees in a single turn, per assistant, not per connector. This is the number that predicts wrong-tool calls.
Group by task rather than by system. An expenses agent needs the expense actions, not everything the finance stack exposes.
Switch to a search surface once a catalogue passes a few dozen actions. Below that, a curated allowlist is fine and simpler to audit.
Measure first-try tool-selection accuracy alongside cost and latency, and record it before and after each new connection.
Re-measure when a new system connects, because the regression shows up in tools that were already working.

Teams skip that last point: a new connector is tested against its own actions, not against the actions it now competes with.

The Advanced Tool Search documentation walks through the two operations and the token comparison behind them.

Facts verified against primary sources on 25 August 2026.