Why We Changed Our Mind About MCP in Pi
We spent months loudly rejecting the Model Context Protocol. Then we reversed course and baked it right into the core....
Let’s get the awkward part out of the way first. If you looked at pi.dev a few months ago, you saw a very blunt declaration: we do not support MCP. Mario wrote a whole piece about it. We talked trash about the Model Context Protocol on podcasts, dismissing it as rigid hype that didn't fit our engineering ethos. And yet. If you pull down the latest update to Pi today, you will find MCP sitting right there in the core.
People change their minds. Software evolves. The version of MCP floating around last year was a mess of brittle assumptions and clunky integrations, but the protocol matured. We originally figured it could live as an endorsed third-party extension if people really wanted it. That was before we sat down, re-examined the underlying architecture, and realized that bringing it into the core unlocked structural improvements we desperately needed elsewhere, particularly for running sandboxed interpreters like Jev.
Truth be told, not everything about the protocol is sunshine and rainbows. It is still surprisingly difficult to compose properly, largely because the broader ecosystem of MCP servers keeps churning out tools designed for naive use that just dump raw text into context windows to save a few tokens. That misses the mark entirely. We think of MCP much more like OpenAPI paired with intelligent tool discovery, where systems rely on clean structured data and rich descriptions rather than brute-force context stuffing.
Bending our principles stung a bit, but stubbornness is a terrible engineering strategy. This you adapt, when a protocol shifts from a clumsy bottleneck into something that genuinely accelerates how models discover and chain tools through a JavaScript sandbox. We dropped our guard, swallowed some pride, and built it right. Sometimes the best thing you can — to be fair — do for your product is publicly eat your own words.
