Yes. Tool definitions are part of the request, so they count toward the context window and toward input tokens on every call, even if the model never uses the tool. Connecting many MCP servers can add a large fixed overhead. Trim the list to what a task needs.
Where the cost comes from
Anthropic's context window documentation says everything in a request counts toward the window, and names tool definitions explicitly alongside the system prompt, messages, tool results, images and documents. Its token counting page shows the effect with a small example: a request with one simple weather tool is counted separately from the same question without it. Tool schemas include names, descriptions and parameter details, so verbose descriptions cost more.
An MCP server can expose many tools. Each connected server adds its list to the request, and an agent with several servers pays for all of them every turn, subject to caching.
Why it matters beyond the bill
| Effect | Why |
|---|---|
| Cost | Input tokens on every call |
| Limits | Large inputs use input token limits unless cached |
| Accuracy | Documentation notes accuracy and recall can degrade as context grows |
| Cache | Changing the tool list invalidates the cache after it |
| Security | More tools means more actions an injected instruction could invoke |
The cache point is easy to miss. The prompt caching documentation says modifying tool definitions invalidates the entire cache. A tool list that changes by connection state or by user can quietly remove your savings.
How to reduce it
- Connect only the servers a task needs. Use a smaller toolset for a narrow job.
- Shorten descriptions without removing the facts a model needs to choose correctly.
- Defer rarely used tools. The context documentation points to managing tool context and a tool search approach that defers definitions.
- Keep the tool list stable within a session so the cache stays valid.
- Count tokens with and without the tools to see the real overhead before you decide.
The security side of a long tool list
Every tool is a capability. An agent with file write, shell and ticketing tools attached all the time has a larger reach if a prompt injection lands. Least privilege applies to the tool list the same way it applies to token scopes. We cover scoping in omnibus scopes for AI agent tokens.
Review what each MCP server can do, who approved it, and how it authenticates. MCP vendor questions lists what to ask.
Worked example: counting the overhead
The numbers are illustrative. A team connects four tool servers to an agent. Each exposes about fifteen tools, and each tool definition, with its name, description and parameter schema, runs a couple of hundred tokens. That is roughly sixty tools and twelve thousand tokens, carried at the front of every request before anyone has asked a question.
To measure the real figure, call a token counting endpoint twice with the same message, once with the tools and once without, and subtract. The Anthropic token counting page shows this kind of comparison with a single small tool, where the counted input rises noticeably. Repeat it for each server so you know which one carries the most weight.
| Server | Tools exposed | Measured overhead | Used in a typical task? |
|---|---|---|---|
| Code search | 8 | Fill in | Yes |
| Ticketing | 20 | Fill in | Rarely |
| Database | 15 | Fill in | Rarely |
| Chat | 12 | Fill in | Sometimes |
The table is a worksheet. If a server carries a large overhead and is rarely used, disable it by default and enable it for tasks that need it.
Deferred tool definitions
Anthropic's context documentation points to a tool search approach that defers definitions, so only names and instructions enter context until a tool is used. The Claude Code cost page says MCP tool definitions are deferred by default in that tool, and suggests running its context command to see what is using space, disabling unused servers, and noting that command line tools such as the GitHub or cloud CLIs add no per-tool listing. Behavior varies by client, so check how yours loads tool definitions.
A review cadence
Once a month, list every connected tool server, who owns it, what it can do, when it was last used and what it costs in tokens. Remove anything unused. This is both a cost step and a security step: every attached server is attack surface for prompt injection and a credential to protect.
Cache effects in practice
Because the prompt caching documentation says changing tool definitions invalidates the cache, avoid per-user or per-session tool lists when you can. If one user connects a server mid-session, their cache resets from that point. Standardize on a small default set and let people add extras knowingly.
What this means for you
If you connect tool servers to an agent, you are paying a small tax on every request, whether or not the agent uses the tools. The tax is easy to forget because it is invisible in the chat window. It shows up as larger input counts, tighter limits and, on some setups, a cache that resets whenever the tool list changes.
You do not need to give up useful tools. You need to know which ones earn their place. A code search tool used on every task is worth its weight. A database tool used twice a month may be better switched on only when needed.
Common mistakes
The first mistake is connecting every available server because it is easy, and never revisiting the list. The second is writing very long tool descriptions in the hope of helping the model, when a short, precise description often works as well. The third is changing the tool list per user or per session, which breaks caching for everyone. The fourth is skipping a security review of each server because the cost review looked fine, even though every server is also a set of actions an attacker could try to trigger through injected text. The fifth is measuring nothing, and so arguing from guesses.
A step by step trimming routine
- List every connected server, who owns it and what it can do.
- Measure each server's token overhead by counting a fixed request with and without it.
- Mark each server as daily, occasional or unused, using a week of logs if you have them.
- Disable unused servers, and make occasional ones opt in per task.
- Shorten descriptions that run long, then rerun a few tasks to check the agent still picks the right tool.
- Freeze the default tool list so the cache stays valid within a session.
- Put a monthly reminder on the calendar to repeat the review.
A thirty minute review usually removes most of the waste, and it lowers your attack surface at the same time.
Try it yourself
Click through it at your own pace, or open it full screen. Watch how a server is connected and which tools it exposes, then think about how many of those your agent needs.
Safeguard offers an MCP Guardrail and agent identity so you can set rules for which tools an agent may call and see who it is acting as. It does not change token counts, so trimming the list is still your job.
Quick check
Do unused tools still cost tokens?
Yes. Definitions are part of the request and count toward the context window whether or not the model calls them.
Does changing my tool list affect caching?
Yes. The prompt caching documentation says modifying tool definitions invalidates the entire cache.
How can I measure the overhead?
Use a token counting endpoint on the same request with and without the tools and compare the totals.
Sources
- Context windows, Claude API documentation
- Token counting, Claude API documentation
- Prompt caching, Claude API documentation
Last reviewed: 19 October 2026.
