// HACKER NEWS — CYBERSECURITY
Pi.dev: You Said No MCP
If you went to pi.dev in the past, you found a proud declaration that Pi does
not support MCP. If you listen to podcasts where we talked about Pi, you will
have found more than one dismissive statement about MCP from us. Including a
post by Mario about
it. And
yet, if you upgrade to Pi you will find MCP is now a supported piece of
functionality. What happened?
The first thing to remember is that the world is not
static.
We have been paying attention to MCP over the last year and the MCP of today is
not the MCP of yesteryear. That alone would not be much of a reason to put it
into the core, however. As you know, Pi has a great ecosystem of extensions,
surely MCP could have been an extension? Maybe even an Earendil endorsed
extension. And yes you are indeed correct in that MCP could have been an
extension, as it was. That MCP
is now part of the core is a result of us putting our heads together and
rethinking it.
The reason we brought MCP into the core is not just about how MCP has changed,
but also because we found that the changes it would require were generally
useful. For example, the changes we have made to MCP also enable the use of Jev
more easily within Pi. Ultimately what Pi needs is quite similar to what MCP
needs: a sandbox to play with in the form of an interpreter.
While a lot of things have improved about MCP, quite a few have not. The biggest
issue with MCP continues to be that it’s hard to compose. Even with codemode,
which is just a neat little sandbox to allow composing of tool calls, MCP
doesn’t fully deliver on this. But that at this point is less the problem of MCP
but the MCP servers out there and different approaches of harnesses to work with
them.
Many MCP servers are still built for harnesses that just dump tools into the
context and are trying to optimize on their side for token efficiency by
returning text. The way we like to think about MCP at this point is that it
should be much closer to OpenAPI with intelligent tool discovery. That means
tools should return structured data and tools should be discoverable by their
documentation and description.
The reason CLIs are so functional is that the agent and model just wire stuff
together with efficient bashisms. But there is no fundamental reason why you
can’t do that with MCP either. MCP in Pi is just built on exposing those tools
to a JavaScript sandbox like other harnesses like Codex do too.
This will raise the question why we didn’t just do Codemode without MCP. Part of
the answer to this has to do with how tools are expressed in Pi today. We did a
lot of work in recent months to allow Pi to make sense with new models that
allow deferred tool loading, mid-conversation system messages and reasoning
level changes. However we did not yet upgrade our tool loadout to better scale
to these new capabilities.
In a Codemode world one needs to decide if the tool is available to the LLM or
only the codemode part of the LLM. A normal MCP extension does not have enough
metadata available from Pi’s tool loadout to make that experience work well. So
we needed to ensure that tools can be configured to just be deferred or be a
Codemode specific thing.
And while we could have just wired up the metadata to enable better MCP
extensions, we also think that MCP with Codemode solves quite a few of the
issues that it traditionally had. We believe the best way to positively
influence something is to embrace it. And while we think that modern MCP is in a
much better spot than MCP ever was, the servers and patterns still leave room
for improvement. So we want to be part of that conversation and help shape it to
work well in small harnesses instead of standing on the sidelines and just
watching.
Now we talked so much about Codemode, it might be worth explaining what that
even is. When a harness executes tools, for the most part it has two sides: it
can do it where bash runs, or it can do it where the harness agent loop runs.
The trust level on both sides is very differen