Build1 publisher3 min readPublished
Every turn pays again for the same MCP tool definitions
A post arguing the Model Context Protocol was built for 2024-era models pushed a 165-point Hacker News thread into a fight about token cost. The post reports no benchmark, so the measurement is left to your own agent.
The Engineer · Build desk
What happened
- The critical side of the thread argues that every tool definition, schema and server handshake eats context that could go to the task, and that the cost recurs on every call.
- The defending side argues that for an agent without full shell access, explicit tool boundaries are safer and easier to review than a terminal, with sandboxing and auditability as the value.
- dev.to's first recommended step is to dump tool definitions and the system prompt through a tokenizer, falling back to a character count divided by four as a labelled estimate.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- cost The definitions are re-sent each turn, so the overhead scales with conversation length, not with how many servers you wired up. Long-running agent loops pay the most for the same integrations.
- constraint Once tools sit behind one provider's setup, evaluating a cheaper model for part of the workload costs a migration. That is a real tax on experimentation even if the token tax turns out small.
- decision The choice has to be made per agent. A synthesis agent with audited boundaries and a tight loop over two functions do not deserve the same answer, and a team-wide policy will be wrong for one of them.
- contradiction Both camps accept that tools consume context and context costs money, so the thread cannot resolve the question for anyone. What separates them is the price they put on auditability.
Three MCP servers cost you the whole set of tool definitions on every turn. Each server ships names, descriptions and JSON schemas. Those definitions go into the prompt each turn, and the system prompt grows with them, according to dev.to's writeup of the debate [8]. The second effect never shows up as a charge: with more options in front of it, the model's tool selection gets noisier [8].
The post that started this, "Why MCP was always a bad idea" on maharship.com, argues the protocol was designed for 2024 models and now produces context bloat and a token tax [1]. dev.to reports the argument is architectural and cost-oriented, with no benchmark, migration or incident behind it [4]. It is the seed of a renewed debate, and the specification itself has not formally changed [2].
The Hacker News thread ran to roughly 165 points and more than 100 comments in about 13 hours, and dev.to describes it as active and divided [3]. That works out to about two points per comment [15].
The two camps are measuring different things. The critics count context: every tool definition, schema and server handshake consumes tokens that could go to the task, and the cost recurs on every call [5]. Some of them say to "rip out" MCP or to prefer a direct CLI [6]. The defenders count reviewability. For an agent without full shell access, explicit tool boundaries are safer and easier to review than handing it a terminal, and the stated value is sandboxing and auditability, not raw speed [7]. dev.to's conclusion is that treating the decision as global is the mistake, and that the audit "belongs per agent, not per team" [14].
The compounding case is the interesting one, because it is the one teams walk into by accident. Add a cheaper model for classification alongside a stronger one for synthesis, and you take on a second provider account, a second key, a second SDK and a second set of rate limits [9]. Trying a new model against your existing tool setup stops being a one-line change and becomes a provider migration [10].
Both sides in the thread accept that tools consume context and context costs money, dev.to writes; the disagreement is "about the exchange rate" [11]. The measurement that settles it locally is cheap. dev.to's first step is to dump the tool definitions and system prompt to a file and run them through a tokenizer. If no tokenizer is handy, use a character count divided by four as a starting estimate, clearly labelled as an estimate [12]. That count is paid once per turn, so the session total is the count multiplied by the number of turns [16].
What to watch
- Whether anyone in the thread, or the maharship.com author, publishes token counts for a real tool set instead of arguing protocol shape.
- Whether MCP maintainers change how definitions are loaded, so a server's schemas stop being re-sent on every turn.
- Whether providers start caching tool definitions server-side. That would move the cost argument onto different numbers.