The more tools you add to Claude Code, the slower and more expensive each session becomes — until it doesn't. Understanding why requires a brief look at how Claude Code handles its context window, and why the behavior changed in version 2.1.7.
The Original Problem: Tools Consumed Context Before the First Prompt
When you configure MCP servers in Claude Code, each server exposes a set of tools — functions the agent can call to interact with external systems. Every tool has a schema: a JSON description of what the function does, what parameters it accepts, and what it returns.
Before Claude Code 2.1.7, all of these schemas loaded at the start of every session, before you typed a single character. With five or six active MCP servers, tool definitions could consume between 60,000 and 130,000 tokens — up to 82% of the available context window in some configurations. That left relatively little space for the actual work: your files, your prompts, your conversation history.
The result: longer response times, higher API costs, and in large sessions, context truncation that caused the agent to "forget" earlier decisions.
How MCP Tool Search Changes This
Claude Code 2.1.7 introduced MCP Tool Search — a lazy loading system for MCP server schemas. Instead of loading every tool definition upfront, Claude Code now:
- Loads a lightweight search index at session start (~500 tokens of overhead)
- Analyzes your prompt to identify which tools are likely relevant
- Fetches those tools' full schemas on demand, when you actually need them
In practice, this achieves an approximately 85% reduction in tool definition token overhead, and preserves around 95% of the context window for real work. If you're asking about CSS layout, the Postgres MCP schemas don't load. If you're writing a database query, they do.
This feature is enabled by default for all users running Claude Code 2.1.7 or later. No configuration required.
The Architecture Principle Still Matters
MCP Tool Search largely removes the automatic performance penalty for having many servers configured. But it doesn't remove the decision penalty: when the agent has 40 available tools across 8 servers and needs to pick one, it makes worse decisions than when it has 12 tools across 3 servers and the right one is obvious.
Tool Search helps Claude Code find the right tool. It doesn't help Claude Code choose between five tools that all roughly match a query.
The practical implication: keep your server list focused. Three to six servers covering your actual daily workflow will consistently outperform eight to twelve servers covering everything you might conceivably need someday. Install tools for things you use, not things you've read about.
Plugin vs. Bare MCP Server: The Context Cost Comparison
Here's where the Plugin format produces a meaningful advantage for complex tools.
A bare MCP server for a full backend might expose 15–30 individual tools: get_table_schema, list_tables, run_query, create_record, update_record, delete_record, list_actionflows, call_actionflow, get_permissions, and so on. Each of those tools has its own schema. They all load on demand, but they're individually verbose.
A Plugin (Skill + CLI + Hook) solves this differently. Instead of exposing many narrow tools, it exposes a small number of orchestrating tools and uses a CLI as the execution layer. The Skill teaches Claude Code the pattern — "to interact with the backend, use this CLI command with this shape" — so the agent has one clear path rather than a menu of options.
For Momen's Plugin, the agent calls the CLI to run schema codegen, execute typed operations, and call Actionflows. The number of tool choices stays small; the power of what those choices can do stays large. The agent spends fewer tokens on tool selection and more on the actual task.
This is the concrete reason the Plugin form wins for a full backend: not just that it bundles useful things together, but that it makes each session more efficient by reducing decision overhead.
Practical Tips for Keeping Claude Code Fast
Audit your configured servers. List everything in your MCP configuration and ask whether you've actually used it in the last two weeks. If not, comment it out. You can always add it back.
Prefer Plugins over collections of small MCP servers. If you're using a backend, an auth system, and an API — and there's a Plugin that covers all three — use the Plugin. You'll get better agent decisions and lower context overhead than three separate MCP servers would produce.
Use CLAUDE.md to steer tool selection. Add a line to your project's CLAUDE.md that names which tool to reach for in common scenarios: "For database operations, use the Momen plugin CLI. For browser testing, use Playwright MCP." This reduces the time the agent spends evaluating tool options and produces more consistent choices.
Keep CLAUDE.md focused. A CLAUDE.md that's 100 lines of project context is an asset. One that's 800 lines of everything you've ever wanted Claude Code to know is a liability — it consumes context and the agent weighs all of it before responding.
For large sessions, checkpoint explicitly. Even with lazy loading, long sessions accumulate context from files, tool outputs, and conversation history. Use /clear to reset context when switching to a genuinely new task within the same working session.
When You Should Actually Worry About Performance
Performance concerns are real for large, complex sessions — but they're frequently overstated for typical development work.
If you're running 3–4 MCP servers and working on focused tasks (one feature per session), Claude Code 2.1.7+ will generally handle your tool load without issues. The lazy loading system is designed for exactly this usage pattern.
If you're running 8+ MCP servers, doing long exploratory sessions, or working on very large codebases, the architecture principles above matter more. That's the scenario where server selection, Plugin use, and focused CLAUDE.md content make a measurable difference.
The session that slows down most reliably isn't the one with many servers — it's the one where the agent is trying to reason about an unfamiliar backend while also working through many tool options. Give it fewer choices and clearer context, and it performs better regardless of how many tools are technically available.
Summary
Claude Code 2.1.7's MCP Tool Search removes the automatic context penalty for many configured servers by loading schemas on demand. The remaining performance factor is decision quality: fewer, more coherent tool options produce better agent decisions. The Plugin format (Skill + CLI + Hook) reduces decision overhead for complex tools like backends by exposing fewer, more powerful tool options rather than many narrow ones.
The practical advice is simple: keep your server list focused, prefer Plugins for complex tools, and use CLAUDE.md to guide the agent's tool selection for your specific project. Most performance issues with Claude Code come from configuration choices, not from Claude Code itself.
Top comments (0)