# MCP tools cost 1.8× more than the estimate everybody used

> I counted what the tool definitions of every server in the MCP registry cost in Claude. The common o200k estimate was low by 1.8×, and the gap only showed up once I asked for the exact number.

- **Author:** Ondřej Úlehla
- **Published:** 2026-10-16
- **Canonical page:** https://ulehla.dev/notes/mcp-tools-cost-1-8x-more/

---

## The cost you pay before the first question

Connect an MCP server to an agent and the client sends the model a description of every tool it has: the name, the text that explains it, the input schema. This happens at the start of a session and again in every turn. The definitions are part of the prompt, so you pay for them in every turn, also in turns where the model calls no tool at all.

Nobody tells you this number. The official registry lists 43 000 servers and says nothing about what any of them adds to your prompt, or whether the server still answers. I wanted to know both, so I built [MCPCost](https://mcpcost.ulehla.dev): a probe that connects to every server the way a client does, asks for its tools and counts what they cost.

## The first version measured the wrong thing

My first count used the `o200k_base` tokenizer. That was the obvious choice. It is fast, it runs offline, and it was the estimate everybody used. I had a board full of numbers and they looked plausible.

Then I calibrated them. The `count_tokens` endpoint gives the exact count for a request, it is free and it calls no model. I sent each tool set twice: once with the tools plus a small marker tool, once with the marker only. The difference is what the tools cost, with nothing else mixed in.

The estimate was low. Claude charged between 1.5 and 3.8 times what o200k said, and across the registry the gap came out at 1.8×. That is not a rounding error. A budget built on the estimate is a budget that is wrong by almost half.

I switched the board to the exact number and kept the estimate next to it. The estimate stays because it shows the size of the mistake, and because that mistake is what most people still use.

## What the registry actually costs

With the exact count in place, the shape of the registry became clear.

16 586 of 30 024 servers answer. The probe sends a plain `initialize` and `tools/list` with no credentials, and the rest do not get through it. Almost half of what the registry lists does not answer the first two requests a client makes.

Of the servers that answer, the median tool set costs 2 737 tokens in Claude Opus 5.5. That sounds small, and for one server it is. But it is the median, and an agent rarely has one server. Add five typical servers and you are past ten thousand tokens in every turn before the user has typed a word.

The heaviest tool set costs 944 524 tokens. That is one server. It does not fit in a normal context window at all. Nothing in the registry entry warns you about it.

The distribution is the real lesson. Most servers are cheap, a few are absurd, and you cannot tell which is which from the name or the description. You have to measure.

## Why an estimate is not enough

I understand why everybody used o200k. An exact count needs an API call, and an estimate needs nothing. When you only want a rough idea, a rough tool feels fine.

The problem is that a rough idea becomes a decision. Somebody picks a server because it looked light. Somebody sets a token budget for a team config. Somebody writes a blog post that compares two servers. Each of these carries the 1.8× error forward, and nobody sees it, because every number in the chain came from the same tokenizer and they all agree with each other.

Agreement between numbers is not accuracy. The only way I found the gap was to measure the same thing a second way, with the system that actually sends the bill. If you have one source for a number, you do not know how wrong it is.

## What I do differently now

I count with the system that charges me. If there is an exact endpoint, I use it, and I keep any estimate only as a comparison.

I measure a config before I add to it. `npx mcpcost` reports what the servers in my own config cost, and `--budget` fails CI when a config grows past a limit. A tool set that grows quietly is the same problem as a dependency that grows quietly, and it gets the same check.

I also learned that "is it up" belongs next to "what does it cost". A server that does not answer costs nothing and does nothing, and a registry that lists it as if it worked hides that just as well as it hides the token count.

The definitions are the small number in an agent's prompt. They are also the number you pay in every turn, and most of us were reading it off the wrong scale.
