MCP Debate: Token Tax, Context Bloat, and What Devs Can Do

MCP 争议：Token 税、上下文膨胀以及开发者应对之道

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. 简而言之： maharship.com 上的一篇文章指出，模型上下文协议（MCP）是为 2024 年代的模型设计的，如今却导致了上下文膨胀和“Token 税”。这一观点在 Hacker News 上引发了约 165 分的热议，拥有 100 多条评论，并在 X（原 Twitter）上引发了反弹。如果你目前正在运行 AI Agent，这场辩论提醒你在添加新服务器之前，务必审计你的工具在上下文和金钱成本上的实际开销。

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. 一篇题为《为什么 MCP 从一开始就是个坏主意》（maharship.com）的博文认为，模型上下文协议（MCP）是为 2024 年的模型设计的，它会产生上下文膨胀和 Token 税。这篇文章是这场新辩论的导火索，而非正式的规范变更。相关讨论在过去约 13 小时内登上了 Hacker News，获得了约 165 分和 100 多条评论（news.ycombinator.com/item?id=49779329）。讨论区目前非常活跃且观点分歧明显。

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. 在 X 上，这篇文章被引用并伴随着关于审计和沙箱控制价值的反驳。流传的帖子示例包括：“《MCP 从一开始就是个坏主意》是今天 HN 的争论焦点……”、“我不认为 MCP 是个坏主意 🤔……其愿景远不止于服务器”以及“为什么 MCP 从一开始就是个坏主意？”。这些只是对话中的框架，而非结论。目前可用的材料中，该文章并未声称存在任何基准测试、迁移需求或事故。其主张是架构和成本导向的：作者认为，该协议的形态已不再适应当前模型的使用方式。

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. Hacker News 和 X 上的讨论呈现两极分化。一方面，开发者批评其 Token 成本和复杂性。有人建议“彻底移除”MCP 或倾向于使用直接的 CLI。他们的论点是：每一个工具定义、Schema 和服务器握手都会消耗本可用于实际任务的上下文，且这种成本会体现在每一次调用中。

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. 另一方面，开发者为 MCP 的控制和审计能力辩护。反方观点认为，对于没有完整 Shell 访问权限的 Agent 来说，拥有明确工具边界的协议比直接给 Agent 一个终端更安全、更易于审查。沙箱和可审计性是其核心价值，而非原始速度。X 上的帖子也显示了同样的割裂：一种观点称 MCP 是个坏主意，另一种则认为其愿景远不止于服务器。分歧不在于 MCP 是否有效，而在于其开销对于特定的 Agent 是否值得。讨论中唯一没有争议的是：工具会消耗上下文，而上下文需要成本。辩论的核心在于“汇率”问题。

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. 开发者面临的痛点很具体：工具和 MCP 会消耗上下文并产生费用，而管理多个提供商和密钥使问题变得更糟。以下是一个熟悉的场景：你有一个需要读取文件、查询数据库并调用内部 API 的 Agent。你连接了三个 MCP 服务器。每个服务器都会发送包含名称、描述和 JSON Schema 的工具定义。这些定义在每一轮对话中都会被注入到 Prompt 中。你的系统提示词（System Prompt）变得越来越长。随着模型需要在更多选项中进行选择，工具选择的准确性也会受到干扰。而且每一轮对话都要为相同的定义重复付费。

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. 现在加入第二个模型。也许你想用一个更便宜的模型进行分类，用一个更强的模型进行综合。这意味着第二个提供商账户、第二个密钥、第二个 SDK 和第二套速率限制。上下文问题和密钥管理问题叠加在一起：你既要调试为什么 Agent 选错了工具，又要同时在两个仪表盘中轮换凭证。MCP 的批评者加剧了这种担忧。如果协议的开销是真实的，那么实验成本就会上升。针对现有的工具设置尝试新模型不再是一行代码的改动，而是一次提供商迁移。这种摩擦正是“移除派”所反对的，也是“审计派”愿意支付的代价。双方都没有错。错误在于将这一决策视为全局性的。有些 Agent 需要经过审计的工具边界，有些则需要针对一两个功能的快速循环。审计应基于每个 Agent 进行，而不是基于整个团队。

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. 你不需要解决 MCP 的争论也能采取行动。你需要衡量自己的开销并减少模型选择带来的摩擦。以下三个步骤涵盖了大部分解决方案。

1. Measure the context your tools consume. 1. 衡量工具消耗的上下文。

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. 在争论 MCP 之前，先数数 Token。将你的工具定义和系统提示词导出到文件中，并通过 Tokenizer 进行计算。如果你手头没有 Tokenizer，可以将字符数除以 4 作为初步估算，并明确标注为估算值。

# 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)")

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. 对你拥有的每个服务器运行此操作。如果某个服务器占用了大部分 Token，但在大多数轮次中很少被使用，那么它就是你首选的“条件加载”对象。如果某个服务器成本很低且在大多数轮次中都被使用，那么这场争论与你无关。

2. Load tools conditionally. 2. 条件化加载工具。

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. 大多数 Agent 不需要每一轮都加载所有工具。按任务拆分你的工具集，仅附加当前步骤所需的子集。这是一个简单的应用层改动，而非协议层改动，无论你是否保留 MCP，这都有效。

# 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, [])]

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. 审计派的担忧是合理的，所以不要把条件加载当作放弃边界的理由。保留白名单，记录每一次工具调用，并审查日志。这是 MCP 在批评声中依然保留的价值，且维护成本很低。

3. Put a cost log next to your tool log. 3. 在工具日志旁添加成本日志。

Log input tokens, output tokens, and the model name for every call. You cannot settle a token… 记录每一次调用的输入 Token、输出 Token 和模型名称。你无法解决 Token……（原文截断）