MCP Server 的隐性账单：一次连接，先烧掉 20 万 Token 的上下文空间

很多开发者在评估 MCP Server 时，习惯把注意力放在响应延迟和功能覆盖上。但一项针对 10 个热门 MCP Server 的实测显示，真正的成本可能并不在调用阶段，而是在“还没开始提问”之前。研究人员连接 10 个 MCP Server 后，仅工具定义和 JSON Schema 注入，就会在 Claude 的上下文窗口中产生 20 万 Token 的开销。

这项测试覆盖了官方注册表中较受关注的 10 个 MCP Server，共暴露 847 个工具，对应 312K Token 的 JSON Schema。换句话说，如果开发者把一整套常用工具接入 Claude，模型还没有回答第一条消息，上下文窗口就已经被工具说明、参数结构和元数据占满。

Google Drive 一个 Server，就先注入 47,293 Token

在所有被测对象中，Google Drive MCP Server 是上下文占用最突出的案例之一。该 Server 提供了 31 个工具，覆盖文件列表、权限管理、分享、搜索等操作。由于每个工具都带有深层嵌套的 JSON Schema，完整定义合计达到 47,293 Token。

以其中一个文件列表工具为例，Schema 中需要描述查询字符串、语料库范围、是否包含所有云端硬盘内容、排序方式、分页参数、空间类型、字段筛选等多个属性。这类结构对模型理解工具能力是必要的，但当它们被批量注入上下文时，成本会迅速累积。测试结果显示，Google Drive MCP Server 平均每个工具约消耗 1,525 Token。

若以 Claude 3.5 Sonnet 的输入价格计算，即每百万输入 Token 3 美元，这部分开销并非可以忽略的“技术损耗”。素材提到，如果一名开发者每天进行 20 次对话，并挂载 10 个 MCP Server，仅这些前置上下文带来的成本就可能超过 Claude Pro 订阅本身。

Token 都花在哪里：参数结构比工具描述更贵

测试还拆解了这些 Token 的具体去向。结果显示，最大的开销并不是工具名称和描述，而是 inputSchema 中的属性定义。

• 工具名称与描述：39,100 Token，约占 35%
• inputSchema 属性：46,920 Token，约占 42%
• 嵌套类型定义：16,757 Token，约占 15%
• required 字段数组：3,351 Token，约占 3%
• Server 元数据与头部信息：5,586 Token，约占 5%

这意味着，真正吃掉上下文预算的，是每个参数所需的类型、描述、枚举值，以及更深层的对象结构。工具说明只是表面，参数结构才是主体。

除了工具定义，工具调用返回结果也会带来额外开销。MCP 工具结果通常会被包裹在标准结构中，例如实际内容只是 38 个字符的文件名和大小信息，但外层包装就达到 47 个字符。按该案例计算，约 55% 的返回内容属于 JSON 包装开销。如果一次对话中进行 20 次工具调用，这类看似轻微的冗余也会被逐步放大。

对开发者的启示：接入前先算上下文账

这项测试的价值，不只是指出某个 Server “太重”，而是提醒开发者重新审视 MCP 接入策略。官方示例通常只展示 3 到 5 个工具，对应约 2K 到 5K Token，整体仍在可控范围内。但真实生产环境中，一旦工具数量扩展到 100 个甚至 847 个，JSON 开销就会成为主要成本来源。

对于准备接入 MCP Server 的团队，素材给出的选型思路可以概括为几个方向：

• 不要只看工具数量，更要统计注入上下文的 Token 总量
• 优先选择 Schema 更简洁、参数更少的 Server
• 避免一次性挂载全部工具，按任务场景动态启用
• 关注工具返回结构，减少不必要的包装和冗余字段

围绕这一问题，作者也开发了 mcptoon。这是一个 CLI 代理工具，可以放在 Agent 与 MCP Server 之间，用于降低上下文开销。项目可通过 pip install mcptoon 安装，支持 Claude Code、Cursor 以及其他支持 MCP 协议的 Agent。素材称，该项目零依赖，体积约 250KB，并包含 486 项测试，采用 Apache 2.0 开源协议。

从行业角度看，MCP 的意义在于标准化工具接口，这一点并没有被否定。但随着工具生态扩张，上下文膨胀正在成为新的工程问题。对开发者而言，MCP Server 的评估标准也需要更新：除了能力和延迟，工具数量、Schema 大小、Token 消耗，都应成为接入前的必查项。