MCP Tools Drain Less Context Than the Panic Suggests — 6,132 Tokens for 50 of Them

4,204 tokens. That is what one MCP server costs before your agent reads a single file, runs a single command, or answers a single question. I counted it this morning, tool by tool, on a real server, and the number is both smaller and more annoying than the warnings going around suggest.

Two of the most-read posts on dev.to right now are about MCP, and one of them says your MCP servers are silently draining your context window. The claim felt right and unproven at the same time. Nobody in either post shows a count. So I built a server with the official SDK, listed its tools the way a host does, and counted the definitions with tiktoken (cl100k). Then I did the same for the official filesystem server, untouched, as a reality check on my own numbers.

What I measured

First, a server I built myself, with tools modelled on the ones real servers ship: file reading and writing, directory listing, web search, a database query, GitHub issues, a chat message. Same shape, same style of description. I ran it at 1, 10, and 50 tools. Then the official filesystem server, 16 tools, straight from the package.

The raw counts:

synthetic-1: 1 tools, compact JSON 470 bytes synthetic-10: 10 tools, compact JSON 5626 bytes synthetic-50: 50 tools, compact JSON 28226 bytes real-filesystem-server: 16 tools, compact JSON 19369 bytes 

And in tokens:

tools-synthetic-1.json: 1 tools | compact 470 bytes = 101 tokens tools-synthetic-10.json: 10 tools | compact 5626 bytes = 1208 tokens tools-synthetic-50.json: 50 tools | compact 28226 bytes = 6132 tokens tools-real-filesystem-server.json: 16 tools | compact 19369 bytes = 4204 tokens 

The real server costs more than my synthetic one

That gap is the most useful thing in the table. My synthetic tools averaged 121 to 123 tokens each. The real filesystem server averaged 263. Real servers write longer descriptions and richer schemas than my neat little test tools, so the synthetic curve understates the real thing by about half. If you take one number from this post, take the real one: roughly 260 tokens per tool, not 120.

Inside the filesystem server, the spread is wide:

408 tok edit_file 387 tok directory_tree 376 tok search_files 319 tok read_media_file 312 tok read_text_file ... 205 tok copy_file 197 tok get_file_info 154 tok list_allowed_directories 

The fattest tool costs 2.6 times the leanest. What makes a tool fat is not mystery: a long description, several parameters, and enums or nested objects in the schema. edit_file takes a path, an array of edits, and a dry-run flag, and its description is a full paragraph explaining the matching rules, including how line endings and whitespace are handled. list_allowed_directories takes no parameters at all and still costs 154 tokens, because the name and description alone have weight. (The per-tool figures add to 4,202; the other 2 tokens are the brackets and commas of the list itself.)

Here is one tool definition in full, so you can see where the tokens go. This is list_directory from the real server, 214 tokens:

{ "name": "list_directory", "title": "List Directory", "description": "List the files and directories directly inside a path, each marked [FILE] or [DIR]. Use it to see what a directory contains; when you also need each entry's size or want entries sorted by size, use list_directory_with_sizes instead, and for a recursive view use directory_tree. Returns one line per entry. Only works within allowed directories.", "inputSchema": { "type": "object", "properties": { "path": { "type": "string", "description": "The directory to list. Absolute, or relative to an allowed directory; it must resolve inside the allowed directories." } }, "required": ["path"], "$schema": "https://json-schema.org/draft/2020-12/schema" }, "outputSchema": { "type": "object", "properties": { "content": { "type": "string" } }, "required": ["content"], "$schema": "https://json-schema.org/draft/2020-12/schema", "additionalProperties": false }, "annotations": { "readOnlyHint": true, "destructiveHint": false, "idempotentHint": true, "openWorldHint": false } } 

Notice how much of that is not the tool at all. The description is a paragraph with cross-references to two other tools. There is a title, a schema URL repeated twice, an output schema, and four annotation flags. Every one of those fields rides along on every request. The description alone is most of the weight, but the metadata around it is not free either.

One more formatting detail, because it surprised me: the numbers above count compact JSON, no spaces or newlines. Pretty-printed, the same 16 tools cost 6,010 tokens instead of 4,204, a 43% jump for whitespace alone. If your host pretty-prints definitions before sending them, you are paying nearly half again as much for nothing. Most hosts send compact JSON, but it is worth knowing the formatting is not free.

The part nobody mentions: you pay it on every request

Here is where a small number turns into a real cost. Tool definitions are not sent once per conversation. They go out with every request, attached to each one, for as long as the tools are connected. The window only ever holds one copy at a time, so 4,204 tokens is 2.1% of a 200k window no matter how long the conversation runs. But the meter runs on every copy sent. Twenty turns with the filesystem server connected means 84,080 tokens of tool definitions crossing the wire, just to keep the same 16 tools available. Three servers of that size would be 12,612 tokens per request, 6.3% of a 200k window, before a word of conversation.

Put a price on it and it stays small but stops being nothing. At $1.50 per million input tokens, one current published price, 4,204 tokens is about six-tenths of a cent per request. Twenty turns: about 13 cents. Nobody goes broke on that. The cost that matters is the window share, not the money, because the window is what runs out first in a long task.

What actually helps

The numbers point at three levers, in order of effect.

First, disconnect servers you are not using. A connected server charges rent on every request whether its tools get called or not. This is the entire drain, and it is the only lever that removes it completely.

Second, shorten descriptions. The description is the biggest single chunk of most tools, and it is also the part server authors pad with warnings, examples, and restatements. Cutting a description in half saves roughly a third of that tool's cost. If you maintain a server, this is the cheapest win you have.

Third, split big servers. Fifty tools on one server cost 6,132 tokens in my test, but nobody needs all fifty at once. Two servers of twenty-five, connected only when needed, cost nothing extra to build and let you pay for half the tools at a time.

What does not help: worrying about it at small scale. One or two servers on a 200k or 1M window is a rounding error. The drain becomes worth thinking about around four or five servers, or on a long task where the per-request copies pile up.

Limits, stated plainly

Token counts use cl100k, one tokenizer. Other models count the same text differently, usually within about 10 to 20 percent either way, so treat 4,204 as a measurement on one ruler, not a universal constant. I counted the definitions as the client lists them; a host may wrap them with its own extra fields, which would add a little on top. My synthetic tools were leaner than real ones, which is why the real server is the number to trust. And I measured definitions only, not the tool results that come back during a task. Those are a separate cost, and usually a bigger one.

The verdict, then: the drain is real, it is measurable, and it is smaller than the panic suggests. One server is 2% of a 200k window. The problem starts when servers pile up and nobody unplugs them, because the rent is charged on every request, forever, whether the tools get used or not.

P.S. Everything I write stays free — that part doesn't change. But if this one was worth something to you, you can buy me a coffee ☕ (one-time or monthly, both work). It covers the API credits and hosting behind these experiments — and honestly, it's also the nudge that gets the next one started on the evenings I'd otherwise skip it. — Salam