一个 MCP 服务器还没干活就占用了 18,000 个 token。这是解决办法。
内容提要
Pi 曾因 MCP 工具定义占用大量上下文（如 Chrome DevTools MCP 约 1.8 万 token）而拒绝集成，改用 Bash 脚本。Pi 1.0 原生支持 MCP，但通过 Codemode 在 QuickJS 沙箱中按需查找调用工具，默认不将工具定义放入提示，仅保留一行服务器描述，并设 3000 token 预算。开发者可用 toolExposure 控制暴露方式。此举降低了提示开销，但未解决 MCP 可组合性等根本问题。
延伸解读
上下文开销的量化对比
文章给出了具体数据：Chrome DevTools MCP 约占用 1.8 万 token，相当于 20 万上下文窗口的 9%；Playwright MCP 的 21 个工具约需 1.37 万 token，占 6.8%。这些开销在代理执行任何任务前就已产生。作为对比，基于 CLI 的浏览器工具仅需 225 token 的 README。这组数字直观说明了 MCP 工具定义对上下文的挤占程度，也解释了 Pi 此前拒绝集成 MCP 的动机。
Codemode 的按需调用机制
Pi 1.0 将 MCP 工具定义默认排除在提示之外，系统提示中每个服务器只保留一行描述。代理通过 Codemode 在 QuickJS 沙箱中查找并调用所需工具，沙箱无 Node API、文件系统、网络和定时器。脚本可并发执行操作并处理结果后再返回模型。开发者可用 toolExposure 控制暴露方式，例如对 GitHub 服务器直接暴露 search_code、将 get_* 留在 Codemode 后、完全屏蔽 delete_*。
token 预算与优化效果
Codemode 对工具声明设有 3000 token 的默认预算，超出部分仍可被发现。使用默认暴露方式的 MCP 工具不计入该预算。Pi 1.0 还通过缩短 Codemode 描述、将模型 API 文档移出提示、停止重复声明脚本已可访问的工具，使一个使用默认工具和 Codemode 的 GPT-5.6 请求从约 5300 提示 token 降至 3300。这些措施共同降低了提示开销。
未解决的局限
文章明确指出，Pi 1.0 并未解决 Earendil 对 MCP 的更广泛抱怨，包括可组合性问题。此前 Zechner 曾批评 MCP 服务器返回的结果必须经过代理上下文才能持久化到磁盘或与其他结果合并。Codemode 让 Pi 能在不采用 Zechner 最初反对的方式下支持 MCP 协议，但可组合性等根本问题依然存在。
Q&A
为什么 Pi 之前拒绝集成 MCP？
因为 MCP 工具定义会占用大量上下文。例如 Chrome DevTools MCP 约占用 18,000 个 token，相当于 200,000 token 上下文窗口的 9%，而 Playwright MCP 描述 21 个工具也需要约 13,700 个 token。此外，MCP 服务器不可组合，结果必须经过代理上下文才能持久化或与其他结果合并。
Pi 1.0 如何解决 MCP 工具定义占用上下文的问题？
Pi 1.0 默认不将 MCP 服务器的工具定义放入提示中，而是通过 Codemode 在 QuickJS 沙箱中按需查找和调用工具。系统提示中只保留每个服务器的一行描述，工具声明有 3000 token 的默认预算，超出部分仍可被发现。
Codemode 是什么？它有什么特点？
Codemode 是 Pi 的代码模式实现，运行在 QuickJS 沙箱中，没有 Node API、文件系统、网络访问或定时器。脚本可以调用 Pi 的工具和模型，并发运行操作，并在返回结果给模型前进行处理。
开发者如何控制 MCP 工具的暴露方式？
开发者可以通过 toolExposure 控制。例如，在 GitHub 设置中，可以暴露 search_code，将 get_* 保留在 Codemode 后面，并完全阻止 delete_*。
Pi 1.0 在减少 Codemode 占用方面做了哪些优化？
Pi 1.0 缩短了 Codemode 描述，将模型 API 文档移出提示，并停止重复声明脚本已可访问的工具。根据发布说明，一个使用默认工具和 Codemode 的 GPT-5.6 请求，提示 token 从约 5,300 降至 3,300。
Pi 1.0 是否解决了 MCP 的所有问题？
没有。Pi 1.0 并未解决 Earendil 对 MCP 的更广泛抱怨，包括可组合性问题。Codemode 让 Pi 能够支持该协议，而无需采用 Zechner 最初反对的方式。
