Glonce

Pi adds MCP to its core, built on a Codemode JavaScript sandbox

toolsThe Glonce editorsHacker News🔥76Glonce rating76Impact58Novelty63Relevance87Surprise52Players48Credibility81
Pi adds MCP to its core, built on a Codemode JavaScript sandbox

The team behind the Pi coding harness has published a post, "You Said No MCP!", on earendil.com. It answers an obvious question. If you visited pi.dev in the past, you found a proud declaration that Pi does not support MCP. The team also made more than one dismissive remark about MCP on podcasts, and Mario wrote a post about it. Yet upgrade to Pi now and MCP is a supported feature.

The authors give three reasons. First, the world moves: they have watched MCP over the last year and say today's MCP is not the MCP of yesteryear. That alone would not justify putting it in the core, and they concede that MCP could have stayed an extension, as it was before. What tipped the decision was a rethink. The changes MCP needed turned out to be generally useful. For example, the same work makes it easier to use Jev inside Pi. Ultimately, they write, what Pi needs is close to what MCP needs: a sandbox in the form of an interpreter.

Second, they are frank that much of MCP has not improved. The biggest remaining issue is that it is hard to compose. Even with Codemode, a small sandbox for composing tool calls, MCP does not fully deliver. The authors say this is now less a problem of MCP itself than of the MCP servers out there and the different ways harnesses work with them. Many servers are still built for harnesses that dump all tools into the context and try to save tokens by returning text. The authors think MCP should be much closer to OpenAPI with intelligent tool discovery: tools return structured data and can be discovered through their documentation and description. CLIs are useful because the agent and model wire things together with efficient shell idioms, and they see no fundamental reason MCP cannot work that way too. MCP in Pi is built on exposing tools to a JavaScript sandbox, as other harnesses such as Codex also do.

Third, why not Codemode without MCP? Part of the answer is how Pi expresses tools. In recent months the team reworked Pi to suit new models that support deferred tool loading, mid-conversation system messages and reasoning-level changes, but did not yet upgrade the tool loadout to scale to those capabilities. In a Codemode world you must decide whether a tool is visible to the LLM or only to the Codemode part. A normal MCP extension does not get enough metadata from Pi's tool loadout to make that work well, so tools had to become configurable as deferred or Codemode-specific. They could have wired up that metadata for better extensions, but they also think MCP with Codemode solves many of MCP's traditional problems. Their stated philosophy: "We believe the best way to positively influence something is to embrace it." They want to help shape MCP for small harnesses rather than watch from the sidelines.

The post then explains Codemode. A harness can run tools in two places: where bash runs, or where the harness agent loop runs. Trust differs: the loop often runs in a trusted environment, while the tools it runs often sit in a sandbox that is not very trusted. Codemode runs where the harness runs. It orchestrates and coordinates tool calls, letting the agent choose the order of calls and combine them with JavaScript. Because it runs on the harness side, its state is kept in the session transcript rather than the file system. Any language could do in theory, but JavaScript is attractive because small versions can be shipped as WASM binaries with reasonable protection.

In Pi, Codemode loads automatically when MCP is configured, or it can be added to the configuration as a default tool; the post suggests asking Pi to reconfigure itself to enable it. It can be used for more than MCP. The example prompt: when logged in with a provider that offers Jev, run "Use typesafe/jev via codemode to find the 20 most frustrated commenters on our issue tracker". The authors say Pi will combine tools such as the Linear MCP and Jev to do that analysis from within Pi, without wasting any context. They promise more on Jev and Codemode later.

Key facts

  • Pi, which previously declared on pi.dev that it does not support MCP, now includes MCP as a supported feature in its core; it had existed as an extension before.
  • MCP in Pi works by exposing tools to a JavaScript sandbox called Codemode, an approach the authors say other harnesses such as Codex also use.
  • The authors say MCP's biggest remaining problem is that it is hard to compose, and they blame MCP servers and harness approaches more than the protocol itself.
  • Codemode runs on the harness side, not where bash runs, and keeps its state in the session transcript rather than the file system.
  • In Pi, Codemode loads automatically when MCP is configured, or can be added as a default tool.

Why it matters

A project that publicly positioned itself against MCP has reversed course and put it in its core. The authors frame the change as a response to MCP's evolution and to a rethink of how tools are exposed, not as a concession. They also set out a view of where MCP should go: closer to OpenAPI, with tools that return structured data and can be discovered by documentation and description, rather than servers that return text to save tokens. The Codemode approach, exposing tools to a JavaScript sandbox so the agent can combine calls, is one the authors say Codex-style harnesses also use.

Who it affects

Users of the Pi coding harness, who now find MCP as a supported piece of functionality after upgrading. Authors of MCP servers, since the post says many servers are still built for harnesses that dump tools into the context and return text, and argues for structured data and good tool descriptions. Developers of other small harnesses, which the authors say they want to help shape MCP for.

How to use it

Upgrade Pi. In Pi, Codemode is automatically loaded when MCP is configured, or it can be added to the configuration as a default tool; the post suggests simply asking Pi to reconfigure itself to enable Codemode. Codemode also works beyond MCP. The post's example, for users logged in with a provider that offers Jev, is the prompt "Use typesafe/jev via codemode to find the 20 most frustrated commenters on our issue tracker", which the authors say combines the Linear MCP and Jev without wasting context. No release date or version number for the Pi release that adds MCP is given.

How solid is it

This is a first-party explanation from the Pi team, written as "we", and it describes design reasoning rather than results. No benchmarks, measurements or token-savings figures are given, and the "20 most frustrated commenters" line is an illustrative prompt, not a measured outcome. No user reactions or adoption figures are given. The claims about Codemode's placement on the harness side, its state in the session transcript and the WASM-shipped JavaScript are the authors' own descriptions.

Risks and caveats

The authors themselves say MCP is still hard to compose and that Codemode does not fully fix this. They say servers and patterns still leave room for improvement, and many servers are built for context-dumping harnesses that return text. They also note that trust levels differ between the harness loop and the tools it runs, which is why Codemode running on the harness side matters. The source does not explain what Jev is beyond its being offered by some providers and usable via Codemode, and the team says more on Jev and Codemode will follow.

“We believe the best way to positively influence something is to embrace it.”

— The Pi team, "You Said No MCP!" on earendil.com