MCP Context in Claude Code: Keep the Tool or Run a Command?
Measure the context cost of MCP in Claude Code on one repeatable task. Compare tool calls with a local command without assuming a fixed token saving.
MCP Context Cost in Claude Code: Keep the Tool or Run a Command?
An MCP server is useful when Claude Code needs a system outside the working directory: an issue tracker, an internal API, a database, or observability data. It also gives the session tool names, descriptions, input schemas, and possible actions to consider. That does not make MCP automatically expensive. It means the decision belongs to a specific task.
Do not remove every server after one long response. Pick a short, repeatable, read-only task and compare the same task with one server enabled and with that server narrowed or absent. The useful result is a decision about your workflow, not a universal token number.
Where the extra context can come from
Claude Code documents MCP as a way to connect external tools and data. Cost can grow through different paths:
- a broad server advertises many tools and schemas before any call;
- a tool returns a large result that the next turn must interpret;
- the agent repeats searches or reads because the result was too broad;
- a necessary external check disappears after a tool is removed.
These are different observations. A large tool result is not the same as the server description, and neither proves that the server caused every token in a task. Prompt, session history, model choice, repository size, and tool output all affect the result.
Choose the smallest useful interface
For example, git status --short is usually a better first choice than a dedicated tool when the only question is the local worktree state. A command is not a replacement for a constrained interface when the task repeatedly needs structured, external data.
Run a small comparison
- Choose one task without an external side effect, such as listing changed files or reading open tickets in a test project.
- Record the prompt, working directory, expected result, number of turns, tools called, and whether the necessary fact was obtained. Do not copy API keys,
.envvalues, or sensitive output into the note. - Run the task with the current MCP setup.
- Open
/mcp, toggle one server off, start a fresh session, and confirm that the server is still listed as disabled. Run exactly the same task, then toggle it on again and confirm its status in another fresh session. - Compare the result as well as the response size. If the reduced setup causes manual copying or removes a required check, the apparent saving is not a complete win.
A fresh session matters because an earlier session may already contain a tool result. This comparison does not benchmark Claude Code. It gives a reversible decision for one recurring task.
One comparable command
Do not replace MCP with an arbitrary command. For a local status, an equivalent read-only command can return the same fact:
In both variants, ask for the changed-file list and one next step without writing to the repository. Keep the prompt and expected list identical, verify the list first, then compare turns, tool calls, and tokens. If an MCP tool returned an external fact that this command cannot obtain, it is not an equivalent replacement: keep a narrow read-only MCP or use a documented command to that same system.
Reduce tool surface before removing a server
A server may expose many actions while a project uses only one or two. Start by limiting that surface: keep read-only tools for the first test, separate development and administration profiles, and move rare operations into a documented command with an expected result. Do not put secrets, full logs, or chat transcripts into a tool description.
If a tool changes an external system, require its own authorization and verify the resulting state. A model response is not evidence that an external operation succeeded.
Compare API usage without inventing a cause
For a separate Claude Code API workflow, BetterToken provides a user-owned API key and an Anthropic-compatible endpoint. Its Dashboard shows request time, model, status, input, output, cache tokens, and usage cost. Use the current Claude Code setup documentation to verify configuration. BetterToken is API access, not a Claude subscription, and the key belongs in the user's account rather than a repository or handoff.
Record model, date and time, input, output, cache, Dashboard cost, and turns for both runs. If cost is shown, calculate observed difference = cost with MCP - cost without MCP. If only tokens are shown, open the current BetterToken pricing page, note its date, model, and cache rules, and use cost = input/1,000,000 x Pinput + output/1,000,000 x Poutput + cache/1,000,000 x Pcache only when cache has a separate listed price. Do not replace an empty field with zero or reuse an old rate. This is an observed two-run difference, not a fixed price for MCP.
Those records cannot prove that one MCP server caused every token: hold the task steady and treat the result as an observation with limits.
Check the decision in the right order
Before removing MCP from a working profile, check these items in order:
- Required external fact. Confirm that the replacement obtains the needed ticket, status, API record, or document rather than guessing it.
- Correctness and access boundary. Match the expected result and keep the test read-only without adding a secret or a broader scope.
- Preserved verification. Confirm that the replacement did not remove a validation the tool used to perform; a model response is not evidence of an external result.
- Only then measure cost. Compare turns, calls, input/output/cache tokens, and Dashboard cost with the same prompt in a fresh session.
If the first three checks fail, lower usage does not improve the workflow: the runs no longer represent the same task, or a person now carries the missing verification.
When to revisit the choice
Restore a server when its removal prevents a required external fact, leads to unverified suggestions, or makes people copy the same data into each prompt. Keep the narrower setup when the task still produces the required result with fewer unnecessary calls. A useful MCP profile is usually quiet: every enabled tool has a repeated job, while the rest have a short command, document, or manual check.