AI Weekly Malaysia

Earendil Engineering published a post explaining why Pi reversed its public position on MCP: Pi's site and podcasts had previously declared that Pi does not support MCP, and MCP was available only as an extension, but it is now part of Pi's core. The post says the change came from rethinking MCP rather than from MCP improving alone, and that the same sandbox/interpreter work needed for MCP also makes it easier to use Jev inside Pi. Earendil argues MCP's biggest remaining problem is composition — even with codemode — and that MCP should be closer to OpenAPI with intelligent tool discovery, returning structured data instead of text.

Why: If you maintain an MCP server that returns prose text to save tokens, this post is a direct argument that you are optimizing for the wrong harness: Earendil says tools should return structured data and be discoverable by their documentation and description. It also matters if you build on Pi specifically, because MCP moved from optional extension to core, so upgrade behaviour changes rather than being opt-in. The composition complaint is the practical warning — even a core MCP implementation with a sandbox does not fully solve chaining tool calls, so plan for that gap rather than assuming the integration removes it.