Claude Haiku 4.5 drops below 90% tool-choice accuracy at 10 to 15 tools

When AI gets tools, the mess moves to the server

Over the past year MCP has become one of the most talked-about ideas in AI infrastructure. The promise is a clean one: a single standard protocol through which an LLM can reach external services, read data, call functions, drive applications. No rebuilding the plumbing for every model. Stand up a server once, and Claude, GPT, Gemini and other compatible clients can all work with it.

But as soon as the first teams started building such servers in earnest, it became clear that the protocol is only the beginning. The awkward practical question comes next. How do you actually build an MCP server properly, so that it doesn't crawl, doesn't confuse the model, and doesn't turn into a dumping ground of a hundred badly described tools?

That is the question taken up by the paper Architectural Patterns of MCP Servers for LLM-Integrated Applications. It isn't a theory piece about a beautiful future; it's an attempt to write down how the ecosystem already works in practice. The authors looked at real MCP servers, pulled out the recurring architectural patterns, described the typical mistakes, and added some numbers: on latency, on tool counts, and on how reliable their own classification is.

The result is a text that will serve engineers and architects better than researchers. Because it helps answer a simple question: if you are building an AI application with tools, what server do you actually need?

What was actually studied

The authors assembled a corpus of 15 independent MCP servers. Five come from ANSYR, an industrial voice AI platform; the other ten from the public MCP registry. That matters: the work doesn't rest on a single in-house project, although the production experience clearly shapes the conclusions.

From there the researchers went through the servers' code and configuration by hand. They looked at:

They then did a round of qualitative coding and condensed the observations into five recurring architectural patterns. Separately, they collected anti-patterns — choices that reliably break the model's behavior.

The paper's strength is that it treats MCP not as an abstract protocol but as the problem of designing an interface for a client that reads natural-language descriptions. That is the real shift. A human developer will read the documentation and figure it out. An LLM picks a tool differently: by its name, its description and its argument schema. Get those wrong and the tool may as well not exist.

Five patterns that have already taken shape in MCP

The paper's main result is a catalog of five patterns. Not the "one correct" architectures, more a vocabulary for thinking about design.

1. Resource gateway

The first pattern is a server that carefully opens up data to the model — a database, documents, a CRM, an external API.

The idea is simple: the server becomes the single entry point to the data. It exposes a list of resources, reads by identifier, sometimes parameterized queries. And it is the server that decides what the model may see, in what form, and how to guard against hostile content.

This is a very practical pattern. Once the model is reading other people's documents, comments or user records, you run into prompt injection fast. Say a document contains the line "ignore all previous instructions." To a human that is just text. To a model it is a potential command. A sanitization layer here is not a luxury but a required part of the architecture.

This kind of server shines where there is a lot of reading and few actions. It gives you a stable interface even when the underlying database schema changes.

2. Tool orchestrator

The second pattern is for when a single action is really several steps across different systems.

For example: create a ticket, assign an owner, post a notification to chat and send an email. You can hand the model four separate tools and hope it walks the whole path itself. Or you can fold the scenario into one composite tool.

The authors consider the second option more reliable. The server hides the internal complexity and gives the LLM one legible operation.

Which looks quite sensible. The less the model has to hold in its head, the better its odds of picking the right action and not stalling halfway. But there is a price: the process logic moves to the server. Which means the server is the one that has to handle partial failures, retries and changes to the flow.

This pattern works especially well where the business processes are repeatable.

3. Session-stateful server

By default MCP calls are stateless: request, response, done. Real tasks don't always fit that. A coding agent opens a file, edits it, then saves it. A browser agent opens a page, clicks, checks the state. A voice assistant runs a dialogue where the context of earlier steps matters.

This is where you want a server that holds session state.

It issues a session identifier and binds context to it: the open file, the edits, a transaction, authorization, intermediate data. That takes load off the model, which no longer has to restate the whole context in every request.

But the paper is honest about the downsides. State has to be cleaned up. Skip that and you leak memory. With more than one server you need shared storage. And most of all, state is hard to see from the outside. A list of tools alone does not always tell you that the server "remembers" earlier steps.

That point resurfaces later, in the evaluation of the patterns: even other models frequently mistake these servers for ordinary orchestrators.

4. Proxy aggregator

Once there are many tools and many servers, the temptation is to gather them all behind one entry point. That's how the proxy aggregator is born: a server that talks to other MCP servers, collects their capabilities and proxies the calls.

On paper it sounds great. One configuration for the client. Centralized authentication. Unified logging. A single audit point.

But this is exactly where the paper delivers one of its most useful practical findings: simply dumping every tool into one list is a bad idea.

Why? Because the model has a threshold past which tool selection noticeably degrades. Put too many options in the context and the LLM gets it wrong more often.

The authors propose two variants of the aggregator:

And they clearly regard the second as the right one for real systems.

The more tools the model can see at once, the worse its selection accuracy and the higher the latency.

This is one of the paper's strongest passages. It doesn't just say "don't build too many tools," it backs the claim with data from production operation.

5. Domain-specific adapter

The last pattern is a wrapper around an awkward API. Plenty of enterprise systems are a poor fit for an LLM: opaque identifiers, complicated fields, unhelpful errors, odd date formats and bulky responses.

Here the MCP server becomes a translator between the model and the domain. It accepts more human arguments, normalizes input, turns errors into readable text, swaps identifiers for legible names, and adds a description that helps the model pick the right tool.

It is essentially a semantic layer. It shouldn't rewrite the system's business logic, but it should make that logic usable by an AI.

For enterprise integrations this is probably one of the most viable patterns of the lot.

Four mistakes that break everything

Alongside the patterns the authors describe anti-patterns. The work is especially useful here, because the mistakes are all very recognizable.

The first is the god tool. Instead of a set of clear operations you build one universal function along the lines of "do whatever." For a model that is a disaster: the task is too vague, the argument schema is weak, and the odds of picking the wrong thing are high.

The second is unsanitized content in resources. Hand the model user text as-is and you've opened the door to prompt injection.

The third is long synchronous operations. If a tool is processing video or a huge file and takes too long to answer, the client may simply hit a timeout. Better to return a job identifier plus a separate tool for checking status.

The fourth is bad tool descriptions. And this is probably the most underrated problem of all. For an LLM, the name and the description are part of the interface, not decorative commentary. If the description is vague, the model won't know when to reach for it.

What the measurements showed

The paper has three quantitative results. None of them is startling, but all three are useful.

First, the authors checked whether their pattern classification can be applied with any reliability. Two models independently labeled 54 other servers from their text descriptions. Agreement came out respectable: a Cohen's kappa of 0.76. Which means the catalog isn't entirely arbitrary.

But there is an interesting caveat. The boundaries between patterns are often blurry — particularly where state or domain logic is hard to see from the outside. That is a useful lesson in itself: MCP architecture doesn't always read off a list of capabilities.

Second, the authors measured transport latency.

Latency across the MCP transport options: locally the protocol costs almost nothing, while remote calls run into the network.

The conclusion is simple and thoroughly down to earth: the latency that matters is in the network, not the protocol. Locally everything is fast. The difference between stdio and streamable HTTP barely matters if you're reaching other machines anyway. What matters far more is whether the server sits near the client and whether you're adding an extra network hop through an aggregator.

It is a valuable counterweight to the endless arguments about the "ideal transport." In most practical systems the bottleneck is somewhere else entirely.

Third, the authors looked at the relationship between the number of tools and selection accuracy.

For Claude Haiku 4.5, accuracy falls below 90% somewhere between 10 and 15 tools in context. For Claude Sonnet 4, between 20 and 30. And a growing tool count hits latency as well.

This is a very applied result. It means designing an MCP server isn't just a question of API elegance. The number of tools becomes a constraint on quality.

Which is exactly why "let's just show the model everything we've got" turns out to be harmful.

Why this paper matters

The value of the work isn't a new algorithm. Its strength lies elsewhere: it turns chaotic engineering practice into a legible set of choices.

Plenty of teams today build AI systems by trial and error. First they wire up a couple of functions. Then another ten. Then they add data access. Then comes a second server, a third, routing, logging, authentication. And only after several painful iterations does it dawn on them that there is an architecture here already — it just doesn't have names yet.

This paper supplies the names and the frame. Which means it helps teams make good decisions earlier.

More important still, the authors keep the specifics of an LLM client in view throughout. They aren't just porting old integration patterns into a new world; they show where the rules change. For instance:

The bottom line

Put briefly, the paper says something simple: MCP is not just a protocol but a new discipline of designing interfaces for AI.

The authors identify five base architectural patterns: resource gateway, tool orchestrator, session-stateful server, proxy aggregator and domain-specific adapter. They lay out the typical mistakes. And they add two very practical thoughts: don't spend so much time arguing about transport, think about network topology instead; and don't show the model too many tools at once.

For engineering teams that is probably the main takeaway. A good MCP server isn't the one that can do everything. It's the one that shows the model exactly what it needs, in a legible form, at the right moment.

And if MCP really does become for AI what LSP once became for code editors, work like this will matter all the more. Not because it settles the questions. Because it helps the ecosystem stop building infrastructure by feel.