Ayhan Sipahi Claude Code Skills and Context Window Bloat: A Token Budget Guide
Copying Claude Code configurations causes context window bloat, degraded tool selection, and mismatched workflows. Build setups intentionally with token budget math.
The Claude Code ecosystem now includes 500+ community skills, 1,200+ agent skills, and dozens of MCP server directories. Cloning someone’s “awesome” setup is tempting, and it is the wrong default. Copied configurations create three compounding problems: context window bloat leaves less room for actual code, tool sprawl degrades the model’s ability to pick the right tool, and the copied workflows do not match your codebase.
The setup that works runs the other way. Start with zero MCP servers, add one only when a repeated friction point justifies it, and keep total configuration overhead under 20% of the context window. The token math below shows what a copied setup costs, and the benchmarks show why the model gets worse as the tool list grows.
What a Copied Setup Costs
Claude Code loads configuration from several sources every session. These include system prompt, tool definitions, MCP server schemas, CLAUDE.md files, skills, and memory files. Each source consumes tokens from a shared context window. The math is straightforward but often overlooked.
Two Setups Under /context
The /context command breaks the window down by source. Two real setups:
Minimal setup (2 MCP servers, focused CLAUDE.md):
System prompt: 2.6K tokens (1.3%)
System tools: 11.6K tokens (5.8%)
MCP tools: 5.7K tokens (2.8%)
Custom agents: 69 tokens (0.0%)
Memory files: 743 tokens (0.4%)
Skills: 61 tokens (0.0%)
Autocompact buffer: 33.0K tokens (16.5%)
Free space: 146.2K tokens (73.1%)Bloated setup (8+ MCP servers, copy-pasted config):
System prompt: 2.6K tokens (1.3%)
System tools: 17.6K tokens (8.8%)
MCP tools: 82.0K tokens (41.0%)
Custom agents: 1.3K tokens (0.7%)
Memory files: 7.4K tokens (3.7%)
Skills: 1.0K tokens (0.5%)
Autocompact buffer: 33.0K tokens (16.5%)
Free space: 55.1K tokens (27.5%)The bloated setup loses 91K tokens to overhead. That is nearly half the context window consumed before the conversation starts. Those 91K tokens could have been your codebase, your error logs, or your documentation.
From Two Servers to an Awesome List
| Configuration | MCP Token Cost | Available for Work | Effective Capacity |
|---|---|---|---|
| Zero MCP servers | 0 tokens | ~155K tokens | 100% |
| 2-3 focused servers | ~6K tokens | ~149K tokens | 96% |
| 8+ copy-pasted servers | ~82K tokens | ~73K tokens | 47% |
| 15+ “awesome list” servers | ~145K tokens | ~10K tokens | 6% |
At 6% effective capacity, the model has barely enough room to hold a single file and your question.
Degradation Without a Stack Trace
A misconfigured linter fails loudly. A misconfigured Claude Code session fails by degrees: answers get vaguer, a copied skill steers the model toward plausible-but-wrong suggestions, and with dozens of tools registered the wrong one gets picked more often. Nothing throws an exception, and no log points at the schema definitions sitting in the window. So the usual diagnosis is that the model is having a bad day, and the configuration never comes under suspicion.
Tool Count vs. Accuracy
Two independent sources put numbers on the relationship between tool count and accuracy: an academic benchmark and Anthropic’s own evaluations.
TaskBench (NeurIPS 2024)
The TaskBench benchmark measured LLM accuracy across tool graphs of varying complexity:
- Single tool: 96.16% accuracy
- 6 tools: 39.31% accuracy
- 8 tools: 25.00% accuracy
One caveat: TaskBench scores complete multi-step tool chains, not isolated tool picks, which is much closer to how an agentic coding session actually runs.
Anthropic’s MCP Evaluations
Anthropic’s own benchmarks on Opus 4 with MCP tools show a similar pattern:
- 50+ tools (without Tool Search): 49% accuracy
- 50+ tools (with Tool Search): 74% accuracy
Tool Search improved things, but even with the mitigation enabled, one tool selection in four is still wrong.
Between those data points sits the range that industry write-ups and benchmarks agree on: 5-7 tools for consistent, accurate selection. Past it, each additional tool raises the odds that the model picks the wrong one.
How Far Tool Search Goes
Anthropic shipped MCP Tool Search in Claude Code 2.1.7 (January 2026). When tool definitions exceed 10% of the context window, Tool Search lazy-loads tools on demand instead of including all definitions upfront. The results are meaningful:
- Token overhead reduced by 46.9-85%
- Opus 4 accuracy improved from 49% to 74% on MCP evaluations
Tool Search lowers the bill without removing the reasons to keep the list short:
- The model still searches through tool descriptions to find matches
- Each search step costs tokens and adds latency
- Incorrect search matches waste a turn
- The model must still understand which server has the right tool
Think of Tool Search like a garbage collector: it manages memory pressure, but you would not write memory-leaking code just because the GC exists. The practical ceiling stays where it was, fewer than 10 servers with focused tool sets, and the quality of each tool description matters more once matching happens through search.
Building Up from Zero
The sequence is a loop:
A CLAUDE.md That Earns Its Lines
Start with zero MCP servers and a minimal CLAUDE.md. Include only:
- Build, test, and lint commands for your project
- Architecture decisions Claude cannot infer from code
- Coding style rules specific to your team
- File naming conventions
Anthropic recommends keeping CLAUDE.md under 200 lines, ideally under 100. Every line is read every session.
When a Server Pays for Itself
Add an MCP server only when you find yourself repeatedly describing the same external system to Claude.
The 3-server rule is a useful starting point:
- One for version control (GitHub/GitLab)
- One for your primary data source (database, API, cloud provider)
- One domain-specific (project management, documentation, monitoring)
Skills Come from Repetition
Write skills only for tasks you have done 5+ times with similar prompts. A generic “code review” skill copied from a community list adds nothing Claude cannot already do; a skill that walks through your team’s review checklist, your test requirements, and your architectural patterns is a different tool entirely. The test for a skill draft is whether it describes a process you actually follow. If it reads like a reusable prompt with no process in it, use a prompt.
Keeping the Budget Honest
The audit takes minutes. Run /context and read the breakdown; MCP tools plus system prompt plus memory should stay under 20% of the window. Run /mcp for per-server tool counts and disable anything you have not touched in a week. Reread each CLAUDE.md, global and project-level, and cut every instruction Claude does not need for the tasks you actually do. Then open .claude/skills/ and ask of each file: did I write this, or copy it? Copied skills get replaced with ones based on your own process, or deleted.
Watch compaction frequency too. If auto-compaction triggers often mid-session, overhead is crowding out the work.
Re-run /context after each change.
What Earns a Slot
MCP Servers
| Signal | Action |
|---|---|
| You describe the same external system to Claude 3+ times/week | Add a focused MCP server for it |
| You saw it on an awesome list and it looks interesting | Skip it |
| Your team all needs the same external tool access | Add it to project config |
| You used it once in the last month | Disable or remove it |
| A single server registers 50+ tools | Look for a more focused alternative |
Skill or Plain Prompt
| Signal | Action |
|---|---|
| You have done this task 5+ times with similar prompts | Write a custom skill |
| Someone shared a skill that matches your workflow | Adapt it to your conventions, do not copy it |
| The task is generic (e.g., “review this code”) | Use Claude’s built-in capabilities |
| The task requires your project’s specific conventions | Write a skill that encodes those conventions |
| The skill would exceed 200 lines | Split into focused sub-skills |
CLAUDE.md Lines
| Signal | Action |
|---|---|
| Claude keeps making the same mistake | Add a specific rule to prevent it |
| The instruction applies to every task in this project | Keep it in root CLAUDE.md |
| The instruction applies to one subdirectory only | Move it to a scoped CLAUDE.md |
| You copied it from another project’s CLAUDE.md | Remove it unless it applies to your project |
| Your CLAUDE.md exceeds 200 lines | Audit and move non-universal rules to skills |
The Rationalizations
”I’ll Need It Eventually”
A Docker MCP server with 135 tools consumes ~126K tokens: 63% of a standard 200K context window, reserved for a tool you use twice a week. Even with 1M token windows available, that overhead is still 126K tokens not spent on your actual work. The answer is session scoping. Toggle the server on with /mcp for the sessions that need it and leave it off everywhere else.
”My CLAUDE.md Covers Everything”
A comprehensive CLAUDE.md gets read every session, but only a fraction of it applies to any given task; the rest is paid-for noise. Scoped files exist for this. Keep the root CLAUDE.md to universal rules, and move task-specific instructions into subdirectory CLAUDE.md files or skills.
”The Trending Setup Must Be Best”
A viral configuration was built for its author’s needs, over weeks of iteration you did not see. Read each skill and config before adopting it, and ask when you last needed what it does. If the answer is not within the last week, leave it out.
The CLAUDE.md Scoping Problem
CLAUDE.md files follow a hierarchy:
~/.claude/CLAUDE.md(global): loaded in every project./CLAUDE.md(project root): loaded for this project./packages/api/CLAUDE.md(subdirectory): loaded when working here
Copy someone’s global CLAUDE.md and their React component rules follow you into Go microservices, the “always use pnpm” line fights your yarn workspace, and the Vitest instructions do nothing for a Jest suite.
What belongs is the same short list from the minimal foundation above; the scoping question is which file each line lives in. What does not belong, at any level:
- Generic programming advice (“write clean code”)
- Tool instructions that belong in skills
- Rules for stacks you are not using
- Verbose explanations. Claude reads code well.
When to Override the Default
The zero-then-evidence default holds whenever you are the one paying the context bill: your own repository, a small team, a codebase whose conventions you already carry in your head. Two situations justify overriding it. A platform team that maintains one vetted MCP set for twenty repositories buys consistency that is worth the tokens. A single external system that dominates your working day pays back its server in the first hour. Community skills, shared dotfiles, and awesome lists stay useful as inspiration in both cases; the cost appears when they arrive as a block.
Run /context today and write the overhead number down. Every configuration change after that has a number to beat.
References
- Best Practices for Claude Code - Anthropic’s official guidance on CLAUDE.md structure, recommending under 200 lines
- Context Windows - Claude API Docs - Official documentation on context window mechanics and token budgeting
- Model Context Protocol and the “Too Many Tools” Problem - Analysis of how MCP tool sprawl degrades LLM performance
- Having Multiple MCP Servers Running Eats into Context Window - Issue #3036 - Community report of 67K+ tokens consumed by 7 MCP servers
- Claude Code Just Cut MCP Context Bloat by 46.9% - Analysis of Tool Search reducing token overhead from 51K to 8.5K
- AI Tool Overload: Why More Tools Mean Worse Performance - Research showing 5-7 tools as the practical upper limit for consistent accuracy
- Your MCP Servers Are Eating Your Context - Practical analysis of per-server token costs and reduction strategies
- Extend Claude with Skills - Claude Code Docs - Official documentation on SKILL.md format and skill creation best practices
- Skill Authoring Best Practices - Claude API Docs - Anthropic’s guidance on writing effective skills
- TaskBench: Benchmarking Large Language Models for Task Automation (NeurIPS 2024) - Academic research showing tool graph accuracy dropping from 96% (1 tool) to 25% (8 tools)
- Feature Request: Lazy Loading for MCP Servers - Issue #7336 - Community discussion that led to the Tool Search feature
- MCP Tool Search: How Claude Code Fixed Context Window Bloat - Technical deep-dive on Tool Search internals
- MCP Tools Consume 50% of Context Tokens - Issue #13717 - User report of 98.7K tokens consumed by MCP tools
- Optimising MCP Server Context Usage in Claude Code - Developer walkthrough of auditing and optimizing MCP server token consumption
Related posts
A framework for six levels of AI assistance in software, from code review to vibe coding, with guidance on when to dial AI help up or down.
Devcontainers, Codespaces and AWS Lambda MicroVMs as homes for a coding agent: what each rung adds, what it costs, and when moving the agent off the laptop pays off.
A lifecycle test for CDK stack layout: give a resource its own long-lived stack when it outlives any single deployer, then reach it by a well-known name.
How a frontend platform team makes the right way the easy way: golden-path scaffolding, versioned shared packages, and a task CLI that removes per-team drift.
Agents made code-writing essentially free, but judgment about when and how much to use them is still entirely yours. An Aristotelian frame to separate the two skills.