TL;DR: A post on maharship.com argues MCP was designed for 2024-era models and now causes context bloat and a token tax, sparking a ~165-point Hacker News thread with 100+ comments and pushback on X. If you run agents today, the debate is a prompt to audit what your tools actually cost in context and dollars before you add another server.
What happened
A blog post titled “Why MCP was always a bad idea” (maharship.com) argues that the Model Context Protocol was designed for 2024 models and that it generates context bloat and a token tax. The post is the seed of a renewed debate, not a formal specification change.
The discussion landed on Hacker News as a thread with roughly 165 points and more than 100 comments in the last ~13 hours (news.ycombinator.com/item?id=49779329). The thread is active and divided.
On X, the post is being cited alongside counter-arguments about the value of audit and sandbox controls. Example posts circulating include “MCP was always a bad idea” is today’s HN fight…, I don’t think MCP was a bad idea 🤔 … the vision goes far beyond just server, and Why MCP Was Always a Bad Idea? These are the framings in the conversation, not conclusions.
No benchmark, migration, or incident is claimed by the post itself in the material available. The claim is architectural and cost-oriented: the protocol’s shape, as the author sees it, does not fit how models are used now.
What developers are saying
The conversation on Hacker News and X is split.
On one side, developers criticize token cost and complexity. Some say to “rip out” MCP or to prefer a direct CLI. The argument is that every tool definition, schema, and server handshake consumes context that could be spent on the actual task, and that the cost shows up on every call.
On the other side, developers defend MCP for control and audit. The counter-argument is that for agents that do not have full shell access, a protocol with explicit tool boundaries is safer and easier to review than handing an agent a terminal. Sandboxing and auditability are the stated value, not raw speed.
The X posts cited in the radar show the same split: one framing calls MCP a bad idea, another says the vision goes far beyond just a server. The disagreement is less about whether MCP works and more about whether its overhead is justified for a given agent.
What is not in dispute in the thread: tools consume context, and context costs money. The debate is about the exchange rate.
The practical problem this creates or reveals
The developer pain in the radar is concrete: tools and MCP eat context and cost, and managing multiple providers and keys makes the problem worse.
Here is a scenario that will look familiar. You have an agent that needs to read files, query a database, and call an internal API. You wire up three MCP servers. Each server ships tool definitions with names, descriptions, and JSON schemas. Those definitions are injected into the prompt on every turn. Your system prompt grows. Your tool-selection accuracy gets noisier as the model has to choose among more options. And every turn pays for the same definitions again.
Now add a second model. Maybe you want a cheaper model for classification and a stronger one for synthesis. That means a second provider account, a second key, a second SDK, and a second set of rate limits. The context problem and the key-management problem compound: you are debugging why the agent picked the wrong tool while also rotating credentials across two dashboards.
The MCP critique sharpens this. If the protocol’s overhead is real, then the cost of experimentation goes up. Trying a new model against your existing tool setup is no longer a one-line change; it is a provider migration. That friction is exactly what the “rip out” camp is reacting to, and it is also what the “keep it for audit” camp is willing to pay for.
Neither side is wrong. The mistake is treating the decision as global. Some agents need audited tool boundaries. Some need a fast loop over one or two functions. The audit belongs per agent, not per team.
What to do about it
You do not need to resolve the MCP debate to act on it. You need to measure your own overhead and reduce the friction around model choice. Three steps cover most of the ground.
1. Measure the context your tools consume. Before you argue about MCP, count the tokens. Dump your tool definitions and system prompt to a file and run them through a tokenizer. If you do not have a tokenizer handy, a rough character count divided by four is a starting estimate, clearly marked as an estimate.
# Illustrative only. Replace with your real tokenizer.
import json
with open("tools.json") as f:
tools = json.load(f)
serialized = json.dumps(tools)
approx_tokens = len(serialized) // 4 # rough estimate, not a measurement
print(f"tool definitions: ~{approx_tokens} tokens per turn (estimate)")
Enter fullscreen mode Exit fullscreen mode
Run this for each server you have. If one server contributes a large share of the total and is used in a small share of turns, that is your first candidate to load conditionally. If a server turns out to be cheap and used on most turns, the debate is not about you.
2. Load tools conditionally. Most agents do not need every tool on every turn. Split your tool set by task and only attach the subset the current step needs. This is a plain application change, not a protocol change, and it works whether you keep MCP or not.
# Illustrative only.
TOOL_SETS = {
"read": ["read_file", "list_dir"],
"write": ["write_file", "apply_patch"],
"query": ["run_sql"],
}
def tools_for(step: str):
return [load_tool(name) for name in TOOL_SETS.get(step, [])]
Enter fullscreen mode Exit fullscreen mode
The audit camp’s concern is legitimate, so do not treat conditional loading as a reason to drop boundaries. Keep an allowlist, log every tool call, and review the log. That is the part of MCP’s value that survives the critique, and it is cheap to keep.
3. Put a cost log next to your tool log. Log input tokens, output tokens, and the model name for every call. You cannot settle a token-tax argument with vibes. You can settle it for your own workload with a week of logs.
# Illustrative only.
import logging
log = logging.getLogger("llm.cost")
def record(model: str, usage: dict):
log.info(
"model=%s input_tokens=%s output_tokens=%s",
model, usage.get("prompt_tokens"), usage.get("completion_tokens"),
)
Enter fullscreen mode Exit fullscreen mode
Once you have those logs, the debate becomes a routing question. Which steps actually need the expensive model, and which ones are paying for tool definitions they never use? That is a question you can answer for your own agent in an afternoon, and it is the only version of the question that has a defensible answer.
A worked example, with made-up numbers, of what the routing half looks like in a config file:
# Example only. Token counts and model IDs are placeholders, not measurements.
ROUTES = {
"classify": "YOUR_CHEAP_MODEL_ID", # e.g. a small/fast tier
"summarize": "YOUR_MID_MODEL_ID",
"synthesize": "YOUR_STRONG_MODEL_ID",
}
def model_for(step: str) -> str:
return ROUTES.get(step, "YOUR_DEFAULT_MODEL_ID")
Enter fullscreen mode Exit fullscreen mode
If your client is OpenAI-compatible, changing the model string is the whole migration. If it is not, that is the friction the radar is pointing at, and it is worth removing before the next protocol debate forces your hand.
Where a single key for many models fits
If the MCP debate is really about cost and context, then the model layer is a separate lever you can pull today. An OpenAI-compatible gateway with one key for 21 models and prepaid USD credit removes the multi-provider key juggling that the radar lists as part of the pain, and it makes model experiments a string change rather than an SDK migration. That is the indirect fit here. The post attacks MCP, not model APIs, so a gateway does not resolve the tool-overhead argument, and it should not be sold as if it does.
What to watch next
Open questions from the thread, not predictions:
- Does the post’s core claim get a technical rebuttal with measurements, or does the debate stay at the level of architecture and preference?
- Do MCP maintainers or server authors respond with changes aimed at context cost, such as lazy tool loading or smaller schemas?
- Do teams that say “rip out” publish what they replaced MCP with, and does that replacement keep audit and sandbox properties?
- Does the audit-and-sandbox camp publish concrete threat models where a direct CLI would be unacceptable?
- Does the conversation move from MCP as a protocol to the broader question of how tool definitions are priced and cached across providers?
The useful move for a working developer is not to pick a side in a thread. It is to measure your own tool context, log your own token cost, and make model switching cheap enough that the next debate does not require a migration to test.
Disclosure: I work on BeefAPI.