某MCP服务器启动前消耗18000 tokens：问题与解决方案

Pi 在过去一年里一直将 MCP 排除在其编程代理（coding agent）之外，尽管该协议已成为开发者工具的标准。它的创始人 Mario Zechner 有一个具体的理由拒绝它。当他测量流行浏览器自动化服务器的上下文成本时，仅 Chrome DevTools MCP 就占用了大约 18,000 个 token，相当于 200,000 个 token 上下文窗口的 9%，而此时代理还没有做任何有用的事情。

MCP 现已内置于 Pi，但连接服务器并不会将所有工具都呈现在模型面前。Pi 将这些工具定义排除在提示词之外，而是在需要时使用 Codemode 来查找工具、从 JavaScript 调用它们，并只返回有用的输出。

测量 MCP 的上下文成本

Zechner 在去年 11 月详细说明了这个问题。Playwright MCP 需要大约 13,700 个 token 来描述其 21 个工具，占 200,000 个 token 窗口的 6.8%，而每个额外的服务器都会增加更多开销。他还被调用工具后发生的事情所困扰。"MCP 服务器也是不可组合的，"他写道。"MCP 服务器返回的结果必须经过代理的上下文才能持久化到磁盘或与其他结果组合。"

"MCP 服务器返回的结果必须经过代理的上下文才能持久化到磁盘或与其他结果组合。"

他的解决方案是 Bash 和一些脚本。模型已经知道如何使用它们，所以没有理由再教它另一个大型工具接口。他的基于 CLI 的浏览器工具只需要一个 225 个 token 的 README，它们的输出可以通过管道传送到另一个命令、过滤或保存到磁盘，而无需先经过模型。pi-mcp-adapter 等扩展在 Pi 1.0 成为原生功能之前就将 MCP 带到了 Pi。

Pi 通过 Codemode 改变了 MCP

今年早些时候收购了 Pi 的 Earendil 表示，MCP 已经成熟到值得重新审视的程度，尽管该公司的解释指向了更实际的原因。"我们将 MCP 引入核心的原因不仅仅是因为 MCP 发生了变化，还因为我们发现它所需的更改通常是有用的，"Earendil 写道。

"我们将 MCP 引入核心的原因不仅仅是因为 MCP 发生了变化，还因为我们发现它所需的更改通常是有用的。"

Pi 已经在使用相同的理念处理 Jev，将 Codemode（其代码模式模式的版本）放在模型与其工具之间。MCP 可以使用这种架构，而不是将每个工具直接暴露给模型。

Codemode 处理工具发现

Codemode 在 QuickJS 沙箱内运行，没有 Node API、文件系统、网络访问或计时器。脚本可以调用 Pi 的工具和模型，并发运行操作，在向模型返回任何内容之前处理结果。

默认情况下，Pi 将 MCP 服务器的工具排除在模型的上下文之外。系统提示词获取每个服务器的一行描述，而代理使用 Codemode 来查找和调用所需的工具。

开发者可以使用 toolExposure 更改该行为。在同一个服务器上，Pi 可以直接暴露一些工具，将其他工具留在 Codemode 后面或完全阻止它们。例如，一个 GitHub 设置可能会暴露 search_code，将 get_* 保留在 Codemode 后面，并阻止 delete_*。

每个工具的暴露控制

Codemode 有 3,000 个 token 的工具声明默认预算；超出该预算的内容仍然可被发现。Pi 1.0 还减少了 Codemode 的整体占用。

Codemode 有 3,000 个 token 的工具声明默认预算；超出该预算的内容仍然可被发现。

根据发布说明，使用默认工具和 Codemode 的 GPT-5.6 请求在 Pi 缩短 Codemode 描述、将模型 API 文档移出提示词并停止为脚本已可访问的工具重复声明后，从大约 5,300 个提示词 token 减少到 3,300 个。使用默认暴露的 MCP 工具不计入该 3,000 个 token 预算。

Pi 1.0 并没有解决 Earendil 对 MCP 的更广泛抱怨，包括可组合性问题。Codemode 给 Pi 提供了一种支持该协议的方式，而无需采用 Zechner 最初反对的方法。