Task-Specific vs System-Specific MCP Servers: Why More Tools Make Agents Worse

Connecting an agent to everything feels like progress. In practice it is the fastest way to make that agent slower, dumber, and harder to govern. Here is the counterintuitive math, and the architecture that fixes it.

Here is a result that should not be true. You take a capable agent, give it access to more tools, and it gets worse. It burns more tokens, picks the wrong action more often, and quietly becomes a governance problem. More capability, less capable.

This is not a fluke of one model or one framework. It is now one of the most reliably reproduced findings in agent engineering, and it has a structural cause. The way most teams connect agents to their systems, one big server per system with every tool switched on, optimizes for the wrong thing. It optimizes for coverage when what the model actually needs is focus.

The fix is not fewer integrations. It is a different unit of organization: the task-specific MCP server. To see why it works, you first have to see exactly how the everything-server fails, because it fails in three distinct ways, and each one is measurable.

The everything-server and its three hidden taxes

The Model Context Protocol (MCP) is the open standard that lets an agent talk to external systems through a common interface. It is genuinely excellent, and adoption has been explosive: by Anthropic’s own account, developers now “routinely build agents with access to hundreds or thousands of tools across dozens of MCP servers.” (Anthropic Engineering)

The instinct behind that sprawl is reasonable: if the agent might need something, expose it. But every tool you expose is not free. It is taxed three times before it does a single useful thing.

The token tax: you pay for the whole library to read one page

Most MCP clients load every tool definition into the context window up front, before the agent has even read the user’s request. Each definition is a chunk of schema: name, description, parameters, return structure. Individually small; collectively brutal. Anthropic puts it bluntly: when “agents are connected to thousands of tools, they’ll need to process hundreds of thousands of tokens before reading a request.” (Anthropic)

Then comes the second helping. Results flow back through the model too. In Anthropic’s worked example, an agent copies a meeting transcript from Google Drive into Salesforce; the full transcript passes through the context window twice, and for a two-hour meeting that is roughly 50,000 extra tokens spent moving data the model never needed to read. Practitioners describe schema bloat and response bloat together eating 30 to 50 percent of the available context before the real work starts. (The New Stack)

How much does that focus buy back? When Anthropic let the agent load only the tools a task required, one workflow dropped from 150,000 tokens to 2,000, a 98.7 percent reduction. Independent work on dynamic toolsets reports cutting total token consumption by around 90 percent, and input tokens by 96 percent, versus loading everything. (Speakeasy)

Tokens are not just cost. Context is the model’s working memory, and it is a finite, shared resource. Every token spent describing a tool the agent will never call is a token not spent on the user’s actual problem, plus added latency on every single turn. The everything-server makes you pay rent on capability you are not using.

The accuracy tax: more options, worse choices

The token tax is the one teams notice first because it shows up on the invoice. The accuracy tax is more insidious, because it shows up as the agent simply being wrong.

Tool calling has quietly split into two very different skills. Models have basically mastered the mechanics: on MCP-Bench, which wires models to 250 tools across 28 live servers, even mid-scale systems produce valid tool names and schema-compliant calls more than 95 percent of the time. The mechanics are a solved problem. What is not solved is judgment: on the same benchmark, scores for choosing the appropriate tool and getting its parameters right sit around 0.70 for frontier models and fall to 0.30 to 0.50 for weaker ones. Calling a tool is easy. Knowing which tool, in which order, with which arguments, is the hard part, and that is exactly the part more tools make harder.

The clearest evidence comes from a 2026 study with an unusually honest title, “How Many Tools Should an LLM Agent See?” The researchers found that a long candidate list actively hurts selection. On the Berkeley Function Calling Leaderboard (370 tools), an adaptive policy that showed the model just 7 tools on average matched the task coverage of showing 50 (90.3 percent vs 90.8 percent). Tested downstream on Claude Sonnet, the shorter, sharper list lifted tool-selection accuracy to 93.1 percent, versus 87.1 percent when the model was always shown more. Less menu, better choice.

Why does a fuller toolbox make a model dumber? Three mechanisms compound. Distraction: near-duplicate tools (three ways to “search,” four ways to “update a record”) blur the decision boundary, and benchmarks report tool-selection accuracy degrading as catalogs grow and as semantically similar tools pile up. Capacity: in the GeoEngine benchmark, a model with a context window large enough to hold all 46 candidate tools still picked the wrong one, simply because the sheer number of options overwhelmed it. Self-conditioning: once a model has reached for a tool, it tends to keep reaching for tools, so an over-equipped agent over-acts. Give an agent a hundred things it could do and you have given it a hundred ways to be confidently wrong.

The governance tax: a server that can do anything is a liability

The third tax is the one that keeps security teams up at night, and it is the reason “just expose everything” is not survivable in an enterprise.

A system-specific server with every action enabled is, by construction, an over-privileged actor. The OWASP MCP Security Cheat Sheet and others catalog the failure modes precisely. Excessive tool permissions: when a server is handed broad access from the start, a single compromise lets an attacker misuse every legitimate privilege it holds. The confused deputy: an MCP server usually acts with its own broad service identity, not the end user’s narrower permissions, so a manipulated agent can be tricked into exercising authority the requester never had. Prompt injection and tool poisoning: malicious input coerces the model into unintended tool calls, and attackers can smuggle sensitive data out inside ordinary-looking arguments like a search query or an email subject. The standard mitigation, repeated across every serious guide, is one phrase: least privilege. Give each server only the access its job requires.

Notice that least privilege is not just a security control. It is the same prescription the token tax and the accuracy tax were quietly demanding. Fewer tools, matched to the job. Three different problems, one answer.

So what is actually going wrong?

Here is the reframe. The everything-server is not failing because MCP is flawed or because the model is weak. It is failing because of how the tools are organized. The default unit of organization is the system, and the system is the wrong unit.

That single design choice, “one server per system, all tools on,” is what generates all three taxes at once. To replace it you need to understand the two architectures clearly, so let us define both, in detail.

What is a system-specific MCP server?

A system-specific MCP server is organized around a piece of software. There is a Salesforce server, a Snowflake server, a GitHub server, a Workday server. Each one mirrors its system’s API surface and exposes that system’s full catalog of tools and actions to any agent that connects.

This is the default for a good reason: it is the natural unit of integration. The team that owns Salesforce ships “the Salesforce MCP server,” and it faithfully reflects everything Salesforce can do. It is reusable, it is conceptually tidy, and for a single system with a handful of actions it works fine.

The trouble is what happens when an agent needs to get real work done, because real work is almost never confined to one system. To flag at-risk renewals, an agent needs the CRM and the data warehouse and the billing system. With system-specific servers, the only way to give it that reach is to connect all three servers and expose all of their tools. The agent inherits the union of three full API surfaces to use perhaps five actions. You have organized your tools for the convenience of the systems, not for the job the agent is trying to do, and the model pays all three taxes for the privilege.

What is a task-specific MCP server?

A task-specific MCP server is organized around an outcome, not a system. Its unit is the job to be done: “flag at-risk deals,” “reconcile a payment,” “triage an inbound support ticket,” “answer a renewals question.” It exposes only the small set of tools that workflow needs, even when those tools are drawn from several different systems, bundled with the context and the governance the task requires.

The mental shift is from here is everything Salesforce can do to here is exactly what is needed to flag an at-risk deal. A task-specific server for that workflow might carry just five read-only tools, two from the CRM, two from the warehouse, one from billing, and nothing else. The agent that connects sees a clean, purpose-built surface: a short menu of obviously relevant actions, narrowed to a single outcome.

This is the premise Nexla built MCP Studio on, and it is worth stating in full because it inverts the default: “the future is not one MCP server per system, but task-specific MCP servers that assemble the data, actions, context, and governance required to accomplish a business outcome.” The server is defined by the work, and it deliberately carries the minimum set of tools that work requires.

Crucially, task-specific does not mean small-minded. The same underlying connectivity, hundreds of systems, thousands of possible actions, is still there. It is simply not all loaded into one agent at once. You compose a focused server per workflow and draw from the full library only what each job needs. Breadth lives in the platform; focus lives in the server the agent actually sees.

Task-specific vs system-specific, side by side

Lay the two architectures over the three taxes and the case makes itself. The token tax falls because only a handful of definitions load, the difference between Anthropic’s 150,000 tokens and 2,000. The accuracy tax falls because a 7-tool menu beats a 50-tool one, the difference between 93.1 and 87.1 percent selection accuracy. The governance tax falls because a server built for one outcome can hold least-privilege credentials instead of a master key. Same three problems. Same one answer: build the server around the task.

“But won’t I lose capability if each server only does one thing?”

This is the objection everyone raises, and it rests on a hidden assumption: that capability the agent could have must be capability loaded right now. Drop that assumption and the worry dissolves.

The whole industry is converging on the same insight from different directions. Anthropic’s answer is progressive disclosure and code execution: present tools as code the agent can explore on demand, “loading only the definitions it needs for the current task,” which is what produced the 98.7 percent saving. The “How Many Tools” researchers reach it through adaptive shortlists: search the catalog, show the model a handful. Anthropic’s own Skills reach it through composition: small, reusable units the agent pulls in as needed. Different mechanisms, identical principle, the right tools at the right time, not all the tools all the time.

A task-specific server is the cleanest expression of that principle. You are not amputating capability; you are refusing to dump the entire toolbox into the model’s lap for every request. The hundred other things your systems can do are one server away, in the server built for that job. Capability is preserved. What you have removed is the noise.

What a good task-specific server looks like

If you are designing one, four principles separate a real task-specific server from a system server wearing a smaller label.

Target the outcome, not the app. Name the server after the job (“flag at-risk deals”), and let that name decide what belongs in it. If a tool is not on the critical path to the outcome, it does not ship.

Carry the minimum set of tools. Start from zero and add only what the workflow provably needs. Five sharp tools beat fifty hopeful ones, on tokens, on accuracy, and on auditability.

Bring the context with the tools. A task is more than its actions. The server should also assemble the data, definitions, and relationships the agent needs to use those tools correctly, so the model is not guessing what a field means or where a record lives.

Inherit governance by default. Each server should run with least-privilege credentials and full audit logging and lineage for exactly the systems its task touches, so security is a property of the architecture rather than a patch applied afterward.

Organize around the work, not the org chart

The reason more tools make agents worse is that the everything-server organizes integration around systems, and an agent does not think in systems. It thinks in tasks. Every tax it pays, the tokens, the misfires, the over-broad permissions, traces back to that one mismatch between how the tools are arranged and how the work is actually done.

Task-specific servers close the gap. They give the model a short, relevant menu, a small context footprint, and a narrow set of permissions, which is to say they give it focus. And focus, the research is now clear, is what turns a sprawling, expensive, hard-to-trust agent into a reliable one.