You said no MCP

Original Article ↗ Hacker News Discussion ↗

Pi, a minimalist coding agent harness, is reversing its earlier “no MCP” stance by adding built-in support for the Model Context Protocol and a new “Codemode” scripting layer, sparking debate over whether this undermines its original philosophy. Commenters contrast MCP with traditional CLIs and OpenAPI-style APIs, arguing over composability, security, enterprise governance, and how tools should be exposed to LLMs and agents. Many see MCP and Codemode as pragmatic compromises that align with how modern models are trained and how teams actually operate, while others worry about creeping bloat and the proliferation of overlapping standards.

What MCP Is and Why It’s Contentious

  • MCP (Model Context Protocol) is described as a standardized way for agents/LLMs to discover and call tools/APIs, including auth, docs, and structured tool metadata.
  • Supporters see it as “API + docs” or “self‑documenting RPC” that makes tools discoverable and easier for average users and “consumer AI” UIs (ChatGPT, Claude, etc.).
  • Critics argue much of this could have been done by extending OpenAPI or existing IDLs; some see MCP as NIH and redundant with “CLI + skills” or REST.

Pi’s Philosophy Shift: From “No MCP” to Built‑In MCP

  • Pi was originally valued as a minimal, highly customizable, yolo‑style coding harness: no permissions model, no MCP, very barebones core with extensions for everything.
  • Some users welcome MCP in core because MCP has become common in enterprises and other harnesses; using extensions for such a central capability felt awkward.
  • Others worry this is the start of feature bloat and a move away from “this harness is yours” toward “opinionated coding product,” especially with other commercial offerings around it.
  • Maintainers emphasize nothing new is enabled by default; features can be turned off or kept as extensions/forks.

Codemode: Why Not Just Bash?

  • Codemode is a sandboxed scripting environment (often JS/TS) for orchestrating tool and MCP calls at the harness level.
  • Proponents:
    • Fewer round trips to the model, fewer tokens, better parallelization.
    • Works in environments without shell access and enables permission models distinct from OS accounts.
    • Lets MCP tools be composed inside one sandbox instead of each MCP server having its own.
  • Skeptics:
    • Models already chain bash/Python extremely well; adding codemode feels like reinvention and complexity.
    • For local coding agents, a restricted shell in a sandbox VM/container may be simpler and more transparent.
    • Codemode mainly solves problems created by MCP/harness design, not inherent limitations.

MCP vs CLI/Skills/OpenAPI and Enterprise vs Local

  • “Team/enterprise” side:
    • MCP over HTTP gives centralized auth, OAuth flows, telemetry, revocable skills/prompts, and easier distribution/versioning of tools across many users.
    • Some use MCP prompts/resources to centrally manage /‑style commands and small shared state.
  • “Local/power‑user” side:
    • CLI + skills are easier to debug, composable via bash, and work with any harness supporting shell tools.
    • MCP can bloat context, is inconsistently implemented across clients, and lags on basics like file upload.
  • There’s agreement MCP is improving (stateless HTTP, better tooling) but disagreement on whether it’s fundamentally necessary or just one more API style.

Sub‑Agents, Context, and Composability

  • Some lean heavily on sub‑agents and separate sessions to manage context and cost; others find sub‑agents opaque, cache‑unfriendly, and prefer long single sessions plus custom compaction.
  • “MCP doesn’t compose” is debated:
    • One view: codemode plus harness‑level sandboxes largely fixes composition of multiple MCPs.
    • Another: proper tool design and REST/HATEOAS could provide better incremental discovery and composition than current MCP patterns.

Meta: Hype Cycles and Influencers

  • Several comments criticize the earlier “MCP is dead, CLI won” wave as influencer‑driven hype, now reversed as MCP adoption grows.
  • Some see MCP vs CLI as partly cultural: local‑UNIX‑oriented devs vs enterprise and non‑terminal users.
  • Overall sentiment: MCP is neither magic nor useless; it’s a trade‑off that fits some stacks (especially enterprise/GUI) better than others (local dev with shell).