Most developers treat MCP servers the way they treat npm packages. If it looks useful, install it. Sort it out later. By week one, they have 10+ servers running and their Claude Code context bar is sitting at 60% before they’ve typed a single prompt.
One developer spent seven months making every mistake in that playbook. His conclusion: more tools don’t sharpen Claude’s judgment. They degrade it. With 110 tools visible, he clocked the wrong tool getting picked on roughly 1 in 5 calls. With a trimmed setup, that dropped to 1 in 30. The model didn’t improve. The noise did.
Quick Start: What You’ll Learn
How to structure your MCP setup so it preserves context, improves tool selection accuracy, and doesn’t quietly break as the ecosystem keeps growing. No new tools required.
The Old Way vs. The Right Way
The old way: bolt on six MCPs day one, copy-paste configs from READMEs, set everything to --scope user because it’s easier, then wonder why Claude keeps reaching for the wrong tool on unambiguous queries.
The right way: one server. One week. Then earn every addition after that.
Most people miss this part. MCP tool descriptions don’t load once and disappear. They land in your context window on every single turn. One dev found a single tool description consuming 1,200 tokens per call. That’s not overhead. It’s a leak you’re paying on every message.
🛠️ The 7-Step Path to a Working Setup
- Pick one MCP server and use it for a full week
- Read your .claude.json like a dotfile
- Trim tool descriptions aggressively
- Stop defaulting to –scope user
- Group servers by workflow, not by vendor
- Add a gateway when you hit four servers
- Version-control your config before you touch it
Match it to the work you actually do. If you live in pull requests, start with GitHub MCP. If you spend most of your day querying databases, start with a Postgres or SQLite server. The goal isn’t to evaluate the server. It’s to watch how the model picks tools and notice when it picks wrong. Pay attention to the ambiguous cases: when two tools could plausibly handle the same query and the model picks the slower or more destructive one. That pattern recognition is worth more than any config guide.
Most people paste in a config from a README and never open the file again. Open ~/.claude.json. Read every server entry. Read every tool name. If you can’t tell what a tool does in five seconds from its name and description, the model can’t either. A tool named process_data with a four-sentence description is invisible to the model under load. A tool named fetch_github_pr_diff with one clear sentence is not.
The MCP spec allows verbose descriptions. That verbosity lands in your context on every turn. If a description reads like marketing copy, rewrite it. Before: "This powerful tool enables you to seamlessly retrieve and process information from your connected data sources in real time." After: "Fetches rows from the connected Postgres database." Cutting that 1,200-token description saved that cost permanently, on every single call from that point forward. It’s the highest-ROI change most setups never make.
--scope user makes a server available in every Claude session you ever open. Most servers don’t belong there. Use --scope project for anything specific to one codebase. Globally available Postgres, AWS, and Stripe access is a problem when you’re writing a blog post in a different project. Beyond the context bloat, you’re one confused tool call away from Claude touching production infrastructure while you’re doing something completely unrelated.
Instead of thinking "I have a Linear MCP and a Notion MCP," think "I’m doing PM work right now and I need read access to issues and docs." Two servers in one project scope. Zero in user scope. When you switch tasks, switch scopes. The model only sees what matters for the current work. A coding session doesn’t need your calendar MCP. A planning session doesn’t need your database MCP. Keep the two separate and tool selection accuracy goes up without touching a single config value.
Past four active MCPs, the gateway pattern starts paying off. Instead of every tool being visible, the model sees a small interface and tools get ranked per query. That’s where the 1-in-5 error rate dropped to 1-in-30. The model didn’t get smarter. It just had less noise to filter through.
Copy your ~/.claude.json before any edit. Good gateways back up your config automatically, but the version-control habit will matter most when things break in the middle of actual work. They will break. Keeping a dated copy in a private repo or even a local notes folder takes thirty seconds and has saved hours of debugging.
What to Do Right Now
Open ~/.claude.json. Count the servers. Count the tools. Read three tool descriptions out loud. If any of them run longer than two sentences, you’ve found your first fix.
The MCP ecosystem will keep growing and the temptation to keep adding will grow with it. The cap on your context window won’t. Add friction before you add servers.
Frequently Asked Questions
Q: How much context can I actually save by trimming tool descriptions?
It depends on the server. One developer reported reducing a single tool’s description from 800 tokens (with inline JSON Schema examples) to under 100 tokens by removing redundant examples , with zero behavior change from the model. Your savings vary, but verbose tool descriptions are surprisingly common overhead. Start by checking your .claude.json and trim any descriptions longer than 2, 3 sentences.
Q: Why does my context fill up so fast even with just one MCP server?
Tool call responses accumulate in your context throughout the session. A long coding session with multiple MCP calls per turn can burn through 100k+ tokens in accumulated outputs alone. Consider capping your session length and passing a concise summary to your next run , you’ll recover the budget faster than schema trimming alone.
Q: How do I stop the model from injecting code in random places when using MCPs?
One approach is using standard XML tags to separate your main logic from edge-case configs. This signals to the model exactly where it should and shouldn’t write code, especially for tools that handle both happy-path and fallback scenarios.
Q: Should I install all my MCP servers globally or per-project?
Use --scope project for codebase-specific tools (Linear, Postgres, Stripe, etc.) and --scope user only for tools you truly use everywhere. Many developers accidentally add too many globally because they forgot the flag. If you only need a tool for one project, it shouldn’t be global.
If you’re serious about not blowing up your Claude Code context with MCP servers, here’s the exact path I’d follow
by u/AbjectBug5885 in PromptEngineering