Right-size your MCP servers

MCP servers give the agent real tools: databases, browsers, payment APIs, issue trackers, your internal services. The right ones remove guesswork and let the agent act directly instead of asking you to.

When PromptConduit flags this

This guide is tied to the mcp_imbalance insight type in PromptConduit’s coaching contract. That insight is not currently raised automatically. Neither the editor extension nor the web Trends view has a threshold that emits it today, so you won’t see it as a coaching flag.

What PromptConduit does compute, and what you can use to right-size by hand:

• MCP servers used: each tool call named mcp__<server>__<tool> is attributed to <server>, with a call count per server.
• MCP server count: how many distinct servers were actually called.
• MCP vs built-in ratio: MCP tool calls divided by built-in tool calls.

Compare the servers you called with the servers you have configured. The gap is what to prune.

Why it matters

Configured servers have costs even when idle:

• Context. In Claude Code, MCP tool definitions are deferred by default (tool search), so only tool names and server instructions enter context until Claude uses a tool. That is much smaller than loading full definitions, but it is not zero. When tool search is disabled or unavailable, for example with some gateways and older models, full definitions load upfront.
• Cache stability. When tools are loaded upfront, a server connecting mid-session changes the tool definitions at the front of the prompt and invalidates the prompt cache. See improve your cache hit rate.
• Tool selection. Many overlapping tools, such as two servers that both query GitHub, make it harder for the agent to pick the right one.
• Output size. Claude Code warns when an MCP tool’s output exceeds 10,000 tokens and limits output to 25,000 tokens by default (MAX_MCP_OUTPUT_TOKENS changes the limit). A chatty server can fill context fast.

The other side is real too. A server for a system you use every day lets the agent query and act directly instead of you copying data in by hand.

What to do

Audit what’s configured:

claude mcp list

Each server shows a health status such as ✔ Connected, ! Needs authentication, or ✘ Failed to connect. Inside a session, /mcp shows status and the tool count per server, and /context shows what is taking up context space.

Remove what you never call:

claude mcp remove <name>
claude mcp remove <name> --scope project   # if it was added at project scope

Or disable it for now from /mcp. Removing a remote server also deletes the OAuth tokens Claude Code stored for it.

Put servers at the right scope. A server only one project needs belongs at local or project scope, not user scope where it loads everywhere. Project-scoped servers live in .mcp.json and can be committed so the team shares the same set.

Prefer a CLI when one exists. Anthropic’s cost guide notes that tools like gh, aws, gcloud, and sentry-cli are more context-efficient than MCP servers because they add no per-tool listing. Keep MCP for systems without a good CLI, or where the server does something the CLI can’t.

Use a server’s tools instead of scripting around them. If a connected server can do the thing directly, let it. Having the agent shell out and parse raw output is slower and fails more often (see raise your tool success rate).

Make changes between sessions. Editing MCP config takes effect on restart, so prune at a natural break rather than mid-task.

How to check it worked

In the editor extension’s coaching tab, the MCP servers used section lists each server called in the live session with its call count. After pruning, the servers you rely on should still appear there, and claude mcp list should show nothing you haven’t called in weeks. In Claude Code, the /usage plan breakdown attributes recent usage to individual MCP servers on Pro, Max, Team, and Enterprise plans.

See /docs/editor-extension for extension setup and /docs/tools for which assistants report MCP tool calls through hooks.