Why Pi Changed Its Mind About MCP

A software project can make a very public promise, and then a release can make that promise look awkward. Pi once made its refusal to support MCP part of its identity. Upgrade now, however, and MCP is built into the workflow.

MCP, the Model Context Protocol, is a standard way for an AI application to discover and call outside tools such as issue trackers, file services, or databases. A program that exposes those capabilities is an MCP server; the application running the model and deciding what to call is the harness. Pi’s current documentation describes connections to MCP servers through local process pipes or streamable HTTP, with tool exposure controlled in mcp.json. So what changed? (earendil.com)

The answer is less a U-turn than a change in where the difficult problem lives. Pi’s team still identifies MCP’s weak spot as composition: knowing how to call one tool is different from coordinating a search, several lookups, a labeling model, and a final summary without pouring every intermediate result into the conversation. That matters because a language model’s context window—the amount of text it can consider in one request—is limited. A token is a small unit of text used to measure that space, and tool descriptions plus verbose results can consume it before useful reasoning begins.

The old MCP problem was not connectivity

Many integrations make the composition problem worse by returning prose. A tool might send back a large paragraph that the model must reread and interpret, even though the useful information could have been represented as fields such as id, status, and commentCount. Structured data means information arranged in predictable fields rather than packed into conversational text. It gives a program something reliable to filter, sort, combine, or pass to another tool.

That is the direction Pi now wants MCP to take. The protocol supplies a shared contract for discovering and calling tools, while the surrounding harness decides how much of that contract should be shown to the model at each moment. MCP does not need to look like a giant menu of functions pasted into every prompt.

The wider protocol changed too. On July 28, 2026, the MCP project released a specification built around a more stateless core, optional capability discovery, cacheable tool listings, formal extensions, and stronger authorization rules. Stateless means a request can be handled independently instead of depending on one long-lived connection and its stored session. Those changes do not solve composition by themselves, but they make MCP more suitable for different kinds of clients and deployments. (blog.modelcontextprotocol.io)

Pi separates the catalog from the work

Pi now treats tool exposure as a design choice. A tool can be direct, meaning its declaration is given to the model like a built-in function. It can be deferred, meaning the model searches for it and loads it only when needed. Or it can use codemode, where the tool is available to a script but is not added to the model’s ordinary tool declarations. Current Pi documentation lists codemode as the default exposure for MCP tools, helping large tool collections stay out of the model’s main loadout. (pi.dev)

A small configuration might look like this:

{
 "mcpServers": {
 "tracker": {
 "command": "tracker-mcp-server",
 "args": [],
 "exposure": "codemode"
 }
 }
}

The command name is illustrative, but the important line is exposure. It says that the tracker’s tools should be reached through codemode rather than declared individually to the model. The model can still use them; it reaches them through a smaller orchestration tool that knows how to discover and call the underlying functions.

Codemode is the missing middle layer

Codemode is best understood as an interpreter: a program that reads and executes code during a session. In Pi, that code is JavaScript, and its purpose is to coordinate tool calls. Instead of asking the model to call one function, wait for a huge result, then decide what to do next, codemode can fetch data, run several calls in parallel, filter the responses, and return only the useful portion.

Here is an illustrative script for an issue-tracking server:

const page = await tools.mcp__tracker__list_items({
 state: 'open',
 limit: 200
});

const items = page.items?? [];
const results = [];
let next = 0;

async function worker {
 while (true) {
 const index = next++;
 if (index >= items.length) return;

 const item = items[index];
 const details = await tools.mcp__tracker__list_comments({
 id: item.id
 });

 results.push({
 id: item.id,
 title: item.title,
 commentCount: details.comments.length
 });
 }
}

await Promise.all([worker, worker, worker, worker]);
return { total: results.length, items: results };

The script first retrieves a list, then uses four workers to process comments concurrently. The model does not need to watch every intermediate response. It receives a compact object at the end, which is easier to reason about and cheaper to carry through the context window. Pi’s MCP documentation describes this same pattern: codemode scripts can call several tools, work with the complete tool result, and return the part the model actually needs. (pi.dev)

Why would an agent need both MCP and codemode? Because they solve different problems. MCP is the interface contract and transport: it describes how a server advertises and receives tool calls. Codemode is the composition layer: it gives the harness a place to sequence, parallelize, transform, and combine those calls. Without MCP, every integration would need custom glue. Without codemode, the harness could end up dumping a growing catalog of tools into the model.

Why this belongs in Pi’s core

The surprising part is that supporting MCP required more than adding a connector. Pi needed metadata describing which tools should be active, which should remain deferred, which could be called only from scripts, and which should be hidden. That same machinery helps Pi work with modern models that change their tool loadout during a session. It also makes extensions more predictable because tool exposure becomes part of the agent’s runtime rather than a special case owned by one adapter. (earendil.com)

There is a useful safety distinction here. Codemode’s sandbox is an execution boundary for organizing calls; it should not be mistaken for a complete operating-system security boundary. Pi’s security documentation warns that generated commands, extensions, and child processes can run with the permissions of the account starting Pi unless a container, virtual machine, or other isolation layer limits them. MCP calls do pass through Pi’s tool pipeline, where permission handlers and tool annotations such as read-only or destructive hints can be applied, but the surrounding machine still deserves careful protection.

Pi’s change of heart is therefore less about declaring MCP perfect. It is about finding a better division of labor. MCP makes tools portable; codemode makes them composable; Pi decides what the model needs to see. The interesting design move was not adding another protocol. It was moving tool orchestration out of the conversation and into a place where code can handle the busywork.