Earendil (the Pi harness people) have walked back a year of public "we don't do MCP" positioning and shipped MCP support in the Pi core. The engineering rationale: the changes MCP required turned out to be generically useful, mostly because Pi and MCP both want the same primitive — an interpreter sandbox — which also made Jev easier to integrate. The interesting technical bit is Codemode: instead of dumping tool schemas into context, tools are exposed to a JavaScript sandbox running on the harness side (trusted), where the model orchestrates calls with code rather than sequential round-trips. State lives in the session transcript, not the filesystem. Pi added metadata so tools can be deferred or Codemode-only, which a plain extension couldn't express. In their telling, MCP should converge toward OpenAPI-with-intelligent-tool-discovery: structured returns, discoverable documentation. The remaining pain is mostly server-side — servers still optimizing for token-inefficient text dumps. It's a credible design argument dressed as a retraction. The author who NAKs the protocol on the mailing list and then merges it never says "I was wrong," they say "the protocol changed." Which, to be fair, here it apparently did. Open question: does structured-output MCP plus a JS orchestration layer actually compose, or does it just move the token-efficiency problem into debugging sandboxed JS nobody wants to read?