MCP隐藏的Token税：一个服务器开工前烧掉1.8万Token

MCP本该简化工具调用，却成了新的瓶颈

Model Context Protocol（模型上下文协议，MCP）的初衷是让AI智能体接入工具和数据变得更简单。然而现实中，一个Chrome DevTools服务器在执行第一个真正有意义的动作之前，就可能烧掉约18,000个Token。

问题的根源在于加载方式。许多MCP实现会在真正开始工作前，预先加载全部工具描述和JSON Schema。这意味着模型还没开始推理，上下文窗口就已经被大量元数据占满。换句话说，MCP本身可能先于模型智能成为性能瓶颈。

Model Context Protocol connects AI systems to tools and data

这是一个容易被忽视的成本。开发者往往关注模型本身的能力和响应质量，却忽略了接入层在无形中消耗的预算。当这部分开销被量化出来，很多人会惊讶于「还没干活就已经花掉这么多」。

MCP（Model Context Protocol）是由Anthropic于2024年底发布的开放标准，旨在为大语言模型提供统一的工具与数据接入接口。其设计理念类似于USB-C：通过标准化的协议层，让不同的AI应用无需为每个外部工具单独开发集成代码。MCP服务器本质上是一个中间层，它向模型暴露可调用的工具列表（tool catalog），每个工具附带名称、描述和JSON Schema格式的参数定义。模型在推理时读取这些描述，决定调用哪个工具、传入什么参数。正是这份「工具说明书」在每次对话开始时被整体注入上下文，构成了文中所说的隐性Token开销。JSON Schema本身是一种用于描述和验证JSON数据结构的规范，虽然对工具调用的准确性至关重要，但其详细的字段说明、类型约束和示例往往占据相当大的Token空间。

工具目录越大，代价越高

随着接入的工具越来越多，MCP带来的隐性成本会线性放大。更大的工具目录意味着三重代价：更高的输入账单、更少的推理空间，以及更差的工具选择准确度。

Bigger tool catalogs mean higher input bills

这里存在一个反直觉的权衡。直觉上，给智能体接入更多工具应该让它更强大。但实际上，当工具描述塞满上下文窗口，留给模型实际推理的空间被压缩，模型反而更容易在众多相似工具中选错。工具多并不等于智能体强，有时恰恰相反。

输入成本的增长也不容小觑。每一次调用都要重复携带这些工具描述，在高频使用的场景下，这笔「Token税」会随调用次数不断累积，成为运营成本中一块看不见却持续增长的开销。

先测量，再剪枝

既然成本来自前期的设置阶段，解决的第一步就是测量——量化每个服务器的完整提示成本（full prompt cost）。只有把隐藏的开销显式化，才能判断哪些工具真正值得保留。

start by measuring the full prompt cost of every server

测量之后进入剪枝环节：移除特定智能体任务并不需要的高开销工具。不同的智能体任务对工具的需求差异很大，一个负责数据分析的智能体，没必要背着一整套浏览器调试工具的描述。按任务裁剪工具目录，是降低Token税最直接有效的手段。

这个思路把工具目录当作一种「依赖」来管理——就像你不会在项目里引入一堆用不到的第三方库一样，智能体的工具集也应该保持精简和针对性。

用懒加载、作用域暴露和混合模式优化

剪枝之后，还有一系列更精细的优化策略值得采用：

延迟加载与作用域暴露

懒加载（lazy loading）：不在启动时一次性加载所有工具描述，而是按需加载，避免前期的集中开销。
作用域暴露（scoped exposure）：只向当前任务暴露相关的工具子集，而非整个目录。
工具搜索（tool search）：让智能体在需要时检索工具，而不是把全部选项都塞进上下文。

混合模式让代码承担重活

一个关键的架构模式是「混合模式」（hybrid patterns）：由代码处理繁重的工作，只向模型返回简洁的输出。

Use hybrid patterns so code handles heavy lifting and returns concise outputs

这意味着不要让模型直接消费冗长的原始数据或完整的工具交互细节，而是用确定性的代码完成繁重的处理逻辑，再把精炼后的结果交给模型推理。这样既节省Token，又提升了结果的可靠性。

懒加载（lazy loading）这一概念源自软件工程中的延迟初始化模式，核心思想是「用到时再加载，不用不加载」。在MCP场景中，懒加载意味着智能体启动时只注册工具的最小元信息（如工具名称），完整的Schema描述仅在该工具被实际调用前才注入上下文。作用域暴露（scoped exposure）则更进一步：根据当前任务阶段或用户意图，动态筛选出相关工具子集呈现给模型，类似于基于角色的权限控制（RBAC）在工具层面的应用。工具搜索（tool search）通常借助向量嵌入（embedding）技术实现——将工具描述向量化存储，在推理时通过语义相似度检索最相关的若干个工具注入上下文，而非全量加载。这三种策略的共同目标是将上下文中的工具描述从「全量静态」转变为「按需动态」，从而在工具目录不断扩大的情况下，依然维持可控的Token消耗。

像管理依赖一样管理工具目录

在给智能体接入更多服务器之前，有两条纪律值得确立：

一是设定每个智能体的Token预算（per-agent token budgets），为接入层的开销划定明确上限，避免成本失控。

二是像审查其他依赖一样审查工具目录。每新增一个工具或服务器，都应该评估它带来的收益是否值得其Token成本，而不是无脑接入。

MCP的价值板上钉钉，但它的隐性成本提醒我们：智能体架构的优化不止于模型选择和Prompt设计，接入层的工程纪律同样决定着系统的效率与经济性。先测量、再剪枝、善用懒加载与混合模式，才能让MCP回归它简化工具调用的初衷，而不是成为新的瓶颈。