Jan K. Schlüsener - Blog

MCP From Code

2026-10-07T00:00:00+00:00

Pi</a> said no to MCP for most of a year, then shipped it just before 1.0.
This appears to be a reversal.

Earendil, the company that now ships Pi, put the objection of the anti-MCP crowd in the title of its own write-up, "You Said No MCP!"</a>, and pi.dev links it as "Why we changed our minds".

Pi, the harness of choice for true connoisseurs, now supports something it refused. But how did it actually add MCP?

Since 2025 Pi has kept MCP tool schemas and raw results out of what the model reads. If an MCP server is connected the traditional way, all its tools land right in front of the model, unfiltered, polluting context and driving token spend. In a default Pi 1.0 install, with MCP, they land in a sandbox the model drives through code. That's it.

The Refusal</h2> Mario Zechner laid out his position</a> in November 2025:

pi does not and will not support MCP. </blockquote>
The popular servers he cited load their full tool descriptions into context on every session.

Playwright MCP is 21 tools and 13.7k tokens.</li>
Chrome DevTools MCP is 26 tools and 18k tokens.</li> </ul>
He had written up the alternative in an earlier post</a>. Agents are already good at running bash and writing code. Bash and code actually compose, so let the agent call CLI tools and write code. And results from an MCP server "have to go through the agent's context to be persisted to disk or combined with other results." In a script, joins and disk writes happen inside the script, and the model reads the output.
By February 2026 he was conceding MCP has its uses</a>, three of them:

a remote transport for people without a terminal,</li>
auth kept away from the model, and</li>
statefulness.</li> </ul>
None of the three has anything to do with his complaint, which was about schemas and results sitting in context.
What Shipped</h2>
Zechner joined Earendil in April 2026 and Pi with him. On 29 September, version 0.99.0 made MCP a built-in, and 1.0 followed two days later. Earendil's post</a> still complains about composability:

The biggest issue with MCP continues to be that it's hard to compose. </blockquote>
Their read on the ecosystem picks up the 2025 complaint: many servers are still built for harnesses that put every tool into context.
MCP in Pi exposes a server's tools to a JavaScript sandbox, as Codex does. The tool is called `codemode</code> (Cloudflare` `named the pattern</a> in September 2025). Its input is a JavaScript program written by the model, and Pi runs it in a QuickJS sandbox compiled to WebAssembly, without a filesystem, network or timers.`
`Codemode is off in a bare install. Configure a server with the default exposure, codemode, and the MCP extension switches it on. A direct tool call is something you turn on by hand, per server or per tool. For a configured server the model's context gets one system-prompt entry: how to reach its tools, and one line on what the server offers. Tool names and argument schemas stay out. The script looks them up when it needs them.`
The model writes a script and calls codemode</code> with it.</li> Pi runs the script in the sandbox. It's plain JavaScript, so it does what the model wrote, with the helpers Pi documents</a>: searchTools()</code> to find a tool, describeTool()</code> to read its arguments, tools.mcp<server><tool>(args)</code> to run it. The first two are lookups over tool metadata. The third is Pi executing the real tool on the harness side and handing the result back into the script.</li> The script returns a value, and that value is what lands in the model's context as the codemode</code> output. The raw data stays in the sandbox.</li> The model reads it and answers, or writes the next script.</li> </ol> One turn, and the tool is found, its schema read, the call made and a filtered summary returned. The model can also spread the work over several turns, say one script that returns a schema and a second that uses it. Against the GitHub server, the second of those turns would look like this: const search = tools.mcpgithubsearch_issues; const count = async (state) => { const result = await search({ owner: "earendil-works", repo: "pi", query: `is:${state}` }); return JSON.parse(result.content[0].text).total_count; }; const [open, closed] = await Promise.all(["open", "closed"].map(count)); return { open, closed };</code></pre> The tool name would have come out of searchTools()</code> a turn earlier, the argument shape out of describeTool()</code>. The two GitHub calls and all their JSON stay inside the sandbox, and the model gets back one small object. With classic MCP all of this runs through the model: schemas sit in context, every call is a round trip, and every result comes back into context. Between codemode and a direct declaration sits deferred</code>. A tool_search</code> call loads the matching schemas into context for the next turn (up to eight by default). The GitHub MCP server, v1.14.0 from 2 October 2026, has 46 tools and roughly 11k tokens of definitions in its default set. With every toolset on, I tally up 91 tools and about 23k tokens. Declare it directly and you pay that on every turn. Through codemode the same server costs one line, plus whatever scripts the model writes and whatever they return. Codemode's own tool declaration is a fixed cost once it is on, the same for one server as for ten. The scripts are output tokens, the expensive kind, and what they return comes back into context, so the saving is smaller than 23k suggests. The end-to-end cases summarized in The Agent Wall</a> still cut tokens by around two orders of magnitude. How the GitHub numbers were measured</summary> #!/usr/bin/env -S uv run --script # /// script # requires-python = ">=3.11" # dependencies = ["tiktoken"] # /// """Measure what the GitHub MCP server's tool definitions cost in context. uv run measure-github-mcp.py dump [--toolsets=all] > tools.json uv run measure-github-mcp.py tiktoken tools.json ... dump talks to the server's Docker image over stdio and needs GITHUB_PERSONAL_ACCESS_TOKEN set (`gh auth token` works). MCP_IMAGE overrides the image; the default is the v1.14.0 tag the post measured. tiktoken counts the compact JSON of name, description and schema, in the shape the Claude API takes tool definitions. Its o200k_base encoding stands in for Claude's tokenizer, so the counts are approximate. """ import itertools import json import os import subprocess import sys import tiktoken IMAGE = os.environ.get("MCP_IMAGE", "ghcr.io/github/github-mcp-server:v1.14.0") def send(proc, message): proc.stdin.write(json.dumps(message) + "\n") proc.stdin.flush() def call(proc, rid, method, params): """Send one JSON-RPC request and return the result of the matching response.""" send(proc, {"jsonrpc": "2.0", "id": rid, "method": method, "params": params}) for line in proc.stdout: if line.startswith("{"): message = json.loads(line) if message.get("id") == rid: return message["result"] sys.exit("server closed the pipe:\n" + proc.stderr.read()[-2000:]) def dump(server_args): """Print the server's complete tool list as JSON.""" cmd = ["docker", "run", "-i", "--rm", "-e", "GITHUB_PERSONAL_ACCESS_TOKEN", IMAGE, "stdio", *server_args] proc = subprocess.Popen(cmd, stdin=subprocess.PIPE, stdout=subprocess.PIPE, stderr=subprocess.PIPE, text=True) info = call(proc, 1, "initialize", { "protocolVersion": "2025-06-18", "capabilities": {}, "clientInfo": {"name": "measure", "version": "0"}, }) send(proc, {"jsonrpc": "2.0", "method": "notifications/initialized"}) tools = [] cursor = None for rid in itertools.count(2): page = call(proc, rid, "tools/list", {"cursor": cursor} if cursor else {}) tools += page["tools"] cursor = page.get("nextCursor") if not cursor: break proc.terminate() json.dump({"serverInfo": info["serverInfo"], "args": server_args, "tools": tools}, sys.stdout) def count(paths): """Print the token count of each dump.""" enc = tiktoken.get_encoding("o200k_base") for path in paths: with open(path) as f: d = json.load(f) tools = [ {"name": t["name"], "description": t.get("description", ""), "input_schema": t.get("inputSchema", {})} for t in d["tools"] ] tokens = len(enc.encode(json.dumps(tools, separators=(",", ":")))) print(f"{path}: {d['serverInfo']['version']}, {len(tools)} tools, {tokens} tokens") def main(argv): if argv[:1] == ["dump"]: dump(argv[1:]) elif argv[:1] == ["tiktoken"] and argv[1:]: count(argv[1:]) else: sys.exit(doc) if name == "main": main(sys.argv[1:]) </code></pre>measure-github-mcp.py</a> </details> Same Old Wall</h2> The line between sandbox and context keeps getting drawn, under other pressures: cost, model performance, non-determinism, prompt injection. Each one ends up in about the same place. The model plans, a sandbox executes, and data crosses back once, distilled. I collected some cases in The Agent Wall</a>, and this is the same wall seen from the protocol side. Sandboxing MCP servers predates Pi 1.0. Cloudflare's Agents SDK did it in September 2025, and Earendil's post names Codex. Pi just makes it the default, for every server. Pi changed its answer and kept the wall. MCP fits inside it. Whether anyone should use MCP at all is a different post.

The Wall Every Agent Builder Finds (Eventually) 2026-07-26T00:00:00+00:00 Recently, I spotted something interesting: Evolution in action. Different corners of agentic LLM engineering began to find similar working solutions to their specific problem spaces. Even though these disciplines experience different evolutionary pressures, they converge at similar solutions. There is a reason why penguins look similar to seals (hydrodynamic hunters that waddle on land), and why life has a tendency to turn into crabs</a>. The solution space was constrained enough that multiple searches found the same peak. In biology, this is called convergent evolution. In software architecture, this is called a convergent design pattern. These structures appear because constraints force convergence. When enough constraints are imposed on a complex system, the range of viable solutions shrinks towards a narrow region. Multiple independent searches will discover the same peaks. This is one of these peaks. Their 2 Cents</h2> The team at Agent Swarm published something insightful</a>. They instrumented a health scan across all their running automations and benchmarked it. The same task, done naively by an LLM agent making sequential tool calls, touched 26 separate API calls and pushed roughly 815,000 tokens through the model's context. Their script accomplished the same in one call, 13 seconds, and ~6,500 tokens. Cost: $0.02 versus a $2.44 floor - a 99.2% reduction per invocation. Great! The billing number was too high, they fixed it. What they built was a hard boundary between where code executes and what the model sees. Intermediate results stay in the execution environment and the model only sees the return value. They were not the first to draw that line, but nevertheless arrived there. Not Just Them</h2> In September 2025, Cloudflare shipped Code Mode</a>. Their motivation was performance. Instead of describing every operation as a separate tool, they let the model write code against a typed SDK and execute it safely in a sandboxed runtime. In a February 2026 follow-up</a> they applied the pattern to their own MCP server, collapsing 2,500+ API endpoints from 1.17 million tokens to roughly 1,000. Anthropic independently explored the same pattern and published their findings</a> in November 2025. A workflow previously consuming 150,000 tokens reimplemented with code execution used 2,000. A 98.7% reduction. LangChain, the framework most agent developers grew up on, had been moving the same direction for different reasons entirely. Their original AgentExecutor was too rigid to debug, retry, and scale in production. Silent failures, lack of branching, and no durable state. In October 2025, LangChain and LangGraph reached simultaneous GA and AgentExecutor</code> was sunset, with an explicit division of labor: LangChain handles model integrations, LangGraph handles execution. The recommended production path is now a graph where planning and execution are decoupled nodes. Four independent teams and problem spaces, their motivations being cost, performance, token efficiency and framework maturity. The Boundary</h2> All three arrived at the same workflow. The model writes a plan or a script, which executes in a sandbox. Intermediate results stay in the sandbox. The model sees only the return value. This is the boundary: execution environment on one side, model context on the other. Data crosses it exactly once, in one direction, distilled. The boundary was identified much earlier. In April 2023, Simon Willison described the Dual LLM pattern</a>. A privileged model that plans and issues instructions, and a quarantined model that executes against untrusted input and never touches the privileged context. The quarantined executor returns only a result. Willison's motivation was protection against prompt injection, not cost or performance. Same boundary but different pressure. Two years later, Google DeepMind formalized this concept further. Their CaMeL paper</a> built on Willison's architecture, adding explicit control and data flow tracking to make the isolation provably secure. Willison noted at the time that CaMeL might be named</a> for having two humps - an improved evolution of the dual LLM proposal. Mario Zechner arrived at the same boundary from model quality. Building pi, the minimal coding agent</a>, he measured that MCP servers flooding context with verbose tool catalogs</a> and intermediate output degraded agent recall and task performance, independently of cost. His conclusion was the same: keep raw data out of context, keep the model as lean as possible, giving it only what it needs to act. The boundary as a quality constraint, not a billing one. That's what makes it worth paying attention to. Four Pressures</h2> The boundary keeps getting rediscovered because the pressures that lead to it are unrelated to each other. Cost. Agent Swarm's 26 tool calls pushed 815,000 tokens through the model. Their script pushed 6,500. The boundary is a billing optimization that happens to be an architectural one. Model performance. Zechner quantified this: verbose tool catalogs and intermediate results flooding context degrade agent recall and task quality, independent of cost. The model becomes less capable the more you pollute its context. The boundary is a quality constraint. Keep as much of the raw data out as possible, the model will perform better on what remains. Non-determinism. The model is the stochastic component clashing with predictable systems, scripted execution inside the sandbox is deterministic. Same inputs, same outputs, unless somebody trips over the cord. Reliability improves when you shrink the surface area where variance can enter. This architectural boundary does that. Everything inside the execution environment is code, only the model handoff introduces randomness but is contained. Prompt injection. Data that never enters context cannot be adversarial to the model output. Willison's quarantined LLM processes untrusted input in isolation, the privileged planner never sees the raw content, only the sanitized result. Here, the boundary is a security primitive that falls out of the architecture for free, if done right. The Wrinkle</h2> Convergent evolution requires truly independent lineages. But most engineers building agents passed through LangChain, and their problem-solving instincts were shaped by its architecture. What looks like independent discovery may be more like a branching tree: a common ancestor, different environments, different adaptations. This changes the story slightly but not fundamentally. The boundary was not discovered independently by teams with no shared priors but was identified early, in a framework many people used, and then repeatedly validated under different pressures. Engineers who learn to read that signal early stop chasing the framework that implements the pattern and start reasoning about the constraint that forces it. The frameworks will change, but the boundary won't: the model plans, the sandbox executes, and data crosses back exactly once, distilled.

Jan K. Schlüsener - Blog

MCP From Code

The Refusal</h2> Mario Zechner laid out his position</a> in November 2025:</p> pi does not and will not support MCP.</p> </blockquote> The popular servers he cited load their full tool descriptions into context on every session.</p> Playwright MCP is 21 tools and 13.7k tokens.</li>

The Wall Every Agent Builder Finds (Eventually)