How Many Skills Is Too Many? The Context Cost Problem

Every Skill You Install Has a Hidden Tax

Adding a skill to your AI agent feels like adding power. In reality, every skill you install injects its tool definitions into the context window on every single request — before the agent even reads what you asked.

Anthropic's engineering team describes this as tool definition overload: agents connected to hundreds or thousands of tools must process hundreds of thousands of tokens before they reach the user's message. That is context spent on plumbing, not on your problem.

The costs compound in four ways. You get less room for reasoning, because definitions crowd out the actual task. You get tool selection confusion, as the model weighs dozens of near-identical options. You pay more per request, since those tokens bill every time. And debugging gets harder across 30+ tools, where failures hide in the overlap.

• Less reasoning room — definitions consume the context that should hold your request
• Tool selection confusion — more options mean more chances to pick wrong
• Higher cost per request — every definition bills on every call
• Harder debugging — failures blur across overlapping capabilities

The root cause is the "just in case" trap. According to practitioner guidance on Claude Code skills, installing too many skills is the single most common and most counterintuitive failure mode — adding capability feels like progress while quietly degrading performance. One working rule: if you have not used a skill in two weeks, disable it.

Quality does not rescue quantity. An academic study of 856 MCP tools found 97.1% of tool descriptions contain at least one quality defect, with 56% failing to state their purpose clearly. Defective descriptions cause wrong tool selection and invalid arguments — so a bloated library is often a library of small failures.

This is why SkillzBench treats loadouts as a first-class feature: instead of loading everything, you toggle the skills and tools each agent actually needs, so the agent only sees what you chose. Fewer, better-described, deliberately-loaded skills beat a large always-on library.

The Numbers: What Research Says About Skill Overload

Every skill you load into an agent charges a toll before the agent reads a single word of your request. The toll is paid in tokens — and the research shows it compounds fast enough to turn a "powerful" agent into an expensive, error-prone one.

The most striking number comes from Anthropic's own engineering team. In a Google Drive-to-Salesforce workflow, shifting from direct tool calls to code execution cut token usage from 150,000 tokens to 2,000 — a 98.7% reduction. As Anthropic's engineers explain, agents connected to thousands of tools "need to process hundreds of thousands of tokens before reading a request" (see their analysis of code execution with MCP).

The arithmetic of skill sprawl is unforgiving. A practical baseline from a Claude Code skills guide recommends just 5–8 active tools per project. The math behind that number: 20 MCP servers, each exposing 5–10 tools, can consume thousands of tokens on definitions alone — on every single request, whether the tools get used or not.

Then there's the quality problem. A Queen's University study of 856 MCP tools across 103 servers found that 97.1% of tool descriptions contain at least one quality "smell," and 56% fail to state their purpose clearly. Defective descriptions cause agents to select the wrong tool, supply invalid arguments, or take unnecessary steps.

Here the research reveals a genuine tension. The same study found that fully augmenting tool descriptions improves median task success by 5.85 percentage points — but at a price:

• Richer descriptions raise success rates (+5.85 points median) but increase execution steps by 67.46%
• 16.67% of fully-augmented cases actually regressed in performance
• Removing the Examples component from descriptions did not statistically degrade performance — compact descriptions often preserve reliability while cutting token overhead

In other words, description quality and context quantity compete for the same scarce window. You cannot solve the overload problem by writing longer descriptions, and you cannot solve description quality by adding more tools. Both must be optimized together: few skills, each with a compact, high-quality description.

This is why per-agent curation matters more than library size. SkillzBench is being built around exactly this principle — a free directory where every skill is validated and benchmarked, plus a free MCP connector with per-agent loadouts, so each agent sees only what was deliberately chosen for it. The evidence suggests that discipline, not accumulation, is what separates agents that work from agents that wander.

Fewer, Better, Loaded on Demand: The Structural Fix

The fix isn't fewer capabilities — it's changing when they load. Progressive disclosure keeps prompt size under control by loading only skill names and descriptions upfront, then reading full files only when a task actually needs them, as Red Hat's developer guidance describes. Vast information stays available on demand, but the agent stops paying for it on every request.

That principle scales into a two-tier architecture. The always-on tier is a lean context file — AGENTS.md kept under 150 lines, or 30–50 for smaller repos — whose every line passes a single litmus test: would removing this cause the agent to make a mistake it wouldn't otherwise make? Red Hat notes the file ships with every prompt, so each unnecessary line dilutes the signal for the lines that matter. The second tier holds situational skills, loaded only when the task calls for them.

Then there's the pruning discipline that keeps both tiers honest:

• Core — skills the agent uses constantly; these stay active.
• Project-specific — skills tied to one codebase or workflow, enabled only there.
• Occasional — everything else, switched on when needed and off when not.

The audit that sorts them is deliberately blunt: "Did I use this in the last two weeks?" If not, disable it. That heuristic comes from practitioner guidance that names installing too many skills the most common and most counterintuitive failure mode — adding capability feels like adding power, but it degrades performance through reasoning room lost, tool-selection confusion, and higher cost per request. The recommended working set is 5–8 active tools per project. The numbers back the caution: an analysis of 856 MCP tools found 97.1% of descriptions contain at least one quality smell, and fully augmenting descriptions lifted median task success by 5.85 percentage points while increasing execution steps 67.46% — richer context helps, but it spends the same scarce budget.

Per-agent loadouts complete the structure. Instead of one shared library every agent inherits, each agent sees only the skills chosen for it — a sales agent and a support agent get different working sets. This matters at scale, where Atlan's analysis of agent sprawl describes context sprawl: agents building isolated, conflicting understandings of the same business. SkillzBench is being built around exactly this model — a free directory of vetted agent skills plus a free MCP connector with per-agent loadouts, so an agent only ever sees what you toggled for it.

Your Skill Audit: A Practical Checklist

Before adding another skill, run a quick audit. The goal: an agent that carries a small, sharp toolkit instead of a warehouse of dormant installs. Practitioner guidance converges on a 5–8 tool baseline per project, and the audit below gets you there in under an hour.

Start with a full inventory. List every skill and MCP server your agents currently load, then note when you last actually used each one. The two-week heuristic is the fastest filter: if a skill hasn't fired in the last fortnight, it's costing you context on every request for nothing. Most bloat comes from the "just in case" trap — installing for theoretical future use — which is the most common mistake practitioners identify.

Then apply the deletion test to what remains. For instruction files, Red Hat's guidance offers a clean litmus test: would removing this line cause the agent to make a mistake it wouldn't otherwise make? Keep AGENTS.md under 150 lines (30–50 for smaller repos), and treat always-on context as an index pointing to deeper resources, not a dump.

Your audit checklist:

• Inventory every skill and MCP server loaded per agent, with last-used dates.
• Disable anything unused in two weeks; keep only core, always-on skills active.
• Tighten descriptions — remove Examples blocks, which research on 856 MCP tools found can be cut without statistically degrading performance.
• For heavy data workflows, adopt sandboxed code execution so data is filtered before it touches context — Anthropic's engineers showed a Google Drive-to-Salesforce workflow dropping from 150,000 to 2,000 tokens, a 98.7% saving.

Description quality deserves special attention. The same study found 97.1% of tool descriptions carry at least one "smell," and 56% fail to state their purpose clearly — so vetting what you install matters as much as how much. That vetting is genuinely hard to do manually, especially with roughly 26% of published skills carrying at least one vulnerability. It's why we're building SkillzBench: a free directory that security-scans, validates, and benchmarks every skill, plus a free MCP connector with per-agent loadouts so each agent only sees the skills you toggle on. If you want vetted, benchmarked skills without the audit fatigue, join the waitlist — Skills, proven.