DEV Community

Cover image for I measured the token cost of 9 MCP servers: 41k tokens before the first prompt
Piekwerk
Piekwerk

Posted on

I measured the token cost of 9 MCP servers: 41k tokens before the first prompt

Every MCP server you connect costs tokens before you type anything. The
server's tool definitions get injected into the model's context, and the
model reads them on every single call. I wired up 9 servers over a few
weeks, never counted the total, and then one day I ran /context and
found out what my tool collection actually cost.

About 41,000 tokens. Before the first prompt of a session.

This post is the measurement, what I changed, and the rule I use now to
decide if a tool deserves to be a server at all.

How I measured it

Two sources, because neither alone tells the full story:

/context            → in-session breakdown, shows MCP tools as one block
~/.claude/projects/<project>/*.jsonl   → per-request usage objects
Enter fullscreen mode Exit fullscreen mode

The JSONL files carry input_tokens, cache_creation_input_tokens, and
cache_read_input_tokens per API call. Summing the input side across a
quiet session with no prompts beyond a hello gave me the fixed cost: the
tool schemas alone.

The baseline: 9 servers, ~41k tokens

The setup that produced the number:

github, filesystem, memory, puppeteer, postgres,
fetch, slack, sequential-thinking, custom-jira
Enter fullscreen mode Exit fullscreen mode

Each server contributes its tool list: names, descriptions, and JSON
schemas. Small servers run 2-4k tokens. The heavy ones (github, jira)
run 6-8k because they expose 20+ tools with verbose parameter
descriptions.

Nine servers later: ~41k tokens of standing context. On a 200k context
model that is a fifth of the window gone before work starts. On usage
pricing it is worse, because those tokens re-enter every request.

Why the raw number understates the cost

Here is the part that took me longer to understand: the 41k is not the
expensive part. The expensive part is cache invalidation.

Prompt caching prices a cache read at roughly 0.1x the base input price.
That discount only applies when the prefix is stable. Tool definitions
sit at the front of the context, so any change to them (a server
restart that reorders tools, an edit to a description, a server added
or removed) breaks the prefix. Everything after the break re-bills at
full input price.

I measured a session where a flaky MCP server restarted mid-task. The
next request showed cache_read_input_tokens collapse and
input_tokens jump by roughly the size of the full context. One
restart cost more than an hour of stable work.

What I changed

Three moves, in order of impact.

1. Consolidate servers

I had two custom servers that each wrapped the same internal API with
different tool sets. Merging them into one server with one schema block
cut duplicated descriptions. Total schema tokens dropped by roughly
half, from ~41k to ~21k, without losing any capability.

2. Demote weekly tools to CLI scripts

Three servers (slack, jira, puppeteer) got used less than once a week.
They are now plain scripts I run in the shell when needed. The agent
can still reach them: the project instructions name the script and when
to run it. Cost when unused: a one-line mention in the config, not a
schema in every context window.

3. Stop churning descriptions

The sneaky one. I used to "improve" tool descriptions whenever they
annoyed me. Every edit is a cache break across every active session.
Now description edits batch into a monthly pass, the same discipline as
config edits.

The rule I use now

A tool earns an MCP server when all three hold:

1. The agent needs it autonomously (not "I sometimes run this")
2. It's used daily or near-daily
3. Its schema is small, or it groups a family of related calls
Enter fullscreen mode Exit fullscreen mode

Everything else is a script plus a line in the project instructions.

The honest caveat

Numbers above are from one setup: one machine, one model tier, my
mixed workload. Your server sizes will differ (a filesystem server with
a terse schema is much cheaper than mine was). The ratios are the
transferable part: measure your baseline with /context, check the
JSONL usage objects for cache behavior, and be suspicious of any tool
that is always loaded but rarely called.

Related reading


If you want a config that already respects the token budget: AgentConfig Studio ships 12 stack kits with this discipline built in, and the Next.js sample kit is free (MIT).

Top comments (0)