Honestly, the provided argument for it is rather weak. They are basically adding a way of running scripts that are contained within harness to execute harness's own tools (that's the Codemode). A coding agent can already compose any arbitrary logic by invoking shell scripts (or python scripts, or node scripts), etc - so this is just entirely unnecessary in the core, from my perspective.

If you feel that Pi has been drifting away from its original vision, try hax (https://usehax.dev/) - you might like it.

Generally, I use skills with a CLI tool instead of MCP and tools. Usually in most cases I also get a coding agent to generate the CLI tool.

I find this approach is easier to debug and I can also use the tool myself to ensure it's working well.

Over the last week or so on Twitter, I've seen a lot of people talking about how various ways of using MCP don't compose, but nobody seems to be clarifying what that means with a concrete fashion; which leads me to try and read between the lines.

In this very post:

> 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.

Can we get a bit more clarity on this? With codemode, what's the gap? I've also been investigating the search+execute MCP server pattern evangelised by Cloudflare (it uses codemode inside the MCP server to bypass the need to expose a large number of individual tools), but i've seen people say that doesn't compose well either.

As far as I can tell MCP is just "we bothered to document our api in a programatically readable way".

Just generate CLI tools, with docs, from MCP servers on demand.

Swival.dev has a tool to run Python code, and it can expose the MCP tools as Python functions.

This saves a couple prompts and tokens, but only in very specific cases, only with MCP servers that don't already support code mode, and only with large models.

In practice, I've not found that to make a real difference.

Plus, it's likely that more and more MCP servers are going to use code mode natively anyway.

Never complain, never explain

Good to hear. We have our MCP Running inside Larkspur, an Oil and Gas Operater in OKC. It's been six months with c-suite use. Everything runs local models, the DBs (all three) Postgres w/ Tiger and Neo4j. The local models are for processing messy energy data. And the oil bros access the mcp currently from Claude.

Spec wise: Ampere 128C, 256gb, 4xa4000,& 7800x3d, 96gb, Blackwell 24gb, 4070s. Nvidia fiber and mirkotik. Working on RDMA (but isn't really needed yet, but we have it)

OS - Tumbleweed ARM headless, CachyOS x86 hyprland. It's been easier staying on the edge of the kernel with less abstractions.

Can we talk about the point the article makes that the MCP servers should implement JSON apis instead of text APIs? It makes sense if your harness supports code mode, but an embedded code sandbox is a pretty big piece of machinery and not everyone implements it. It seems like a massive change to the way one should build an MCP. Also why again are we using MCPs instead of OpenAPI when it's now supposed to be just stateless JSON APIs?

How come i have been using mcp with pi for the past year?

It sounds like the main value-add of codemode is security, since its a sandboxed language that can call your MCPs with elevated privs.

But pi doesn't have security. Pi is full yolo, it's on the user to run it in an environment that minimizes the blast radius if the LLM goes haywire.

So I'm not sure what the plan is here. Will pi support running certain tools like bash as a different OS user than owner of the pi process?