You Said No MCP
- ID
- 30346
- Status
- summarized
- Published
- 30 Sep 2026, 5:55 PM
- Fetched
- 01 Oct 2026, 3:20 AM
- Provider
- Hacker News
- Category
- dev-community
- Original URL
- https://earendil.com/posts/you-said-no-mcp/
- Source URL
- https://hnrss.org/best
Summary
- Score
- 8.0
- Created
- 01 Oct 2026, 3:20 AM
- Tags
- Audience
- developersvibe_codersai_ml_learnersai_agent_users
What happened
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 it matters
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.
Discussion angle
Take the 'MCP should be OpenAPI with intelligent tool discovery' claim literally: what would your own MCP server look like if it returned structured data and was discoverable from its description instead of dumping tools into context — and what breaks when you try it?