MCP Servers Have a Context Cost

Some tools require MCP. Most don't. Knowing the difference keeps your agent sharp.

67K

tokens consumed by 4 MCP servers before typing a single prompt

50+

tool definitions loaded, most of which the agent never called

10%

context threshold where Claude Code auto-defers MCP tool definitions

When to Use MCP, When Not To

Use MCP

When MCP provides a capability your agent cannot get any other way.

  • Browser control
    Chrome DevTools MCP, Playwright MCP. No CLI equivalent exists.
  • Live research
    Brave Search MCP, Fetch MCP. Real HTTP sessions for web access.
  • Stateful external systems
    Persistent DB connections, proprietary internal tools.

Consider CLI Instead

Your agent was trained on millions of examples for these tools. Zero token overhead.

  • $
    gh pr list
    GitHub MCP exposes 40+ tool definitions. The CLI costs zero.
  • $
    kubectl get pods
    kubectl MCP loads full Kubernetes API surface into context.
  • $
    docker, git, aws cli
    Well-known CLIs with deep training data coverage.

Skills Make Both Better

Skills are not a replacement for MCP. They add metadata, guardrails, and project-specific context to any tool.

For MCP servers

Describe which of 40+ tools matter. Document gotchas, recommended sequences, project-specific context.

For CLI tools

Add project-specific flags, guardrails, API specs. Point to OpenAPI docs, explain which endpoints to avoid.

With scripts

Wrap CLIs with safety checks, rate limits, and defaults. More work than MCP, but real guardrails.

The Decision Tree

For every MCP server in your config, run it through this.

Does your agent need this tool?
No
Remove it
Yes
Can the agent already use it via CLI?
No
(browser, live DB, proprietary)
Keep the MCP server
Yes
(git, kubectl, docker, gh, aws)
Is CLI usage complex or repetitive?
Yes
Consider MCP,
monitor cost
No
Use CLI directly
In all cases: add a skill for project-specific context, guardrails, and documentation

Best Practices

1

Scope per project, not globally

Use project-scoped .mcp.json so each server only loads where needed.

2

Track what your agent actually calls

Tool usage follows a power law. 2-3 tools do the work. The rest eat context.

3

Review MCP additions in PRs

Treat .mcp.json like package.json. Every server addition is a conversation.

4

Read the source before installing

MCP servers are local subprocesses with full filesystem access. No sandboxing by default.

The question is not whether to use MCP.

The question is whether each server is earning its context cost.