Prune Your MCP Servers: Every Tool Schema Is Always-On Cost
Adding tools can make your AI agent worse.
It feels like a free upgrade: connect another Model Context Protocol (MCP) server, and now the agent can do more. But every tool you expose has a standing cost. Its schema — name, description, and full parameter definition — is injected into the context on every single turn, and the pile of choices makes the agent worse at picking the right one. More capability on paper, less reliability in practice.
Two costs, not one
People notice the token cost and stop there. There are two:
- Token cost — each tool's JSON schema sits in context on every turn. A few dozen richly-described tools can eat thousands of tokens before the agent has read a single line of your code.
- Selection cost — this is the bigger one. When the agent has to choose among many similar tools, accuracy drops. It picks the wrong tool, or invents plausible-but-wrong arguments, or dithers between two overlapping options. Decision quality degrades as the option set grows, independent of token count.
So the failure isn't just "context is full." It's "the agent reaches for the wrong thing."
Expose only what the task needs
The fix is curation. For a given workflow, expose the small set of tools that workflow actually uses and turn the rest off.
- Cut what a CLI already does. If the agent has a shell, a git MCP server is often redundant —
giton the command line is more capable and costs zero schema tokens. The same goes for file listing, grep, and build commands. - Cut what you rarely use. A server you connected once for a one-off task is still taxing every turn. If you haven't used it this week, disconnect it.
- Split by context. Keep a lean default set, and enable a heavier server only in the sessions that genuinely need it, rather than globally and forever.
// Before: everything on, always
{ "mcpServers": { "github": {}, "postgres": {}, "slack": {}, "jira": {},
"filesystem": {}, "git": {}, "fetch": {}, "sentry": {} } }
// After: only what this project's tasks need; the shell covers git + files
{ "mcpServers": { "postgres": {}, "sentry": {} } }
The payoff
Fewer tools means a leaner context and a sharper agent. With a handful of relevant, distinct tools, selection accuracy climbs: the model reaches for the right one far more often, and you've spent your token budget on the task instead of on a menu the agent barely uses.
Power moves
- Audit by usage, not by capability. List your connected servers and mark the last time each was actually invoked. Anything cold is a prune candidate.
- Prefer distinct tools over overlapping ones. Two tools that do almost the same thing are worse than one, because the ambiguity is what tanks selection accuracy.
- Let the shell be your general-purpose tool. A CLI covers a huge range with no per-turn schema cost. Reserve MCP servers for capabilities the shell genuinely can't reach.
- Scope servers to projects. Configure MCP per-repo or per-workspace so a task only ever sees the tools relevant to it.
Resources
- Model Context Protocol — official site
- Anthropic — Connect Claude Code to MCP servers
- Anthropic Engineering — Writing effective tools for AI agents
- Anthropic Engineering — Effective context engineering for AI agents
Shipping AI or cloud systems? Yeda AI audits and hardens production LLM and cloud pipelines. Talk to us · Read the blog