Pi's latest version v0.82.1 states it plainly in the README: the core does not bundle MCP (Model Context Protocol, the standard that lets AI Agents connect to external tools and data sources). This is happening two years after MCP has been adopted as default by a large number of Agent frameworks, and we think it's worth pausing to look at: this is not a "standard vs anti-standard" stance—it's a shift of engineering responsibility from the product core to the using team.
What this is
MCP's job is to make tools "discoverable, describable, and invocable"—an AI application (the industry calls this a Host) uses an MCP Client to fetch a tool inventory, then decides how to use them. The problem shows up in the second step: when a Coding Agent (an AI assistant that can write code and execute commands) is wired into ticketing systems, databases, monitoring, cloud platforms, and internal knowledge bases, the tool count grows from an initial 4 to several dozen. Every tool's name, description, parameter Schema (structured parameter definitions), and return structure all enter the AI's context—the connection works, but the model doesn't necessarily become more useful: it picks wrong between similar tools, spends meaningful compute on irrelevant Schemas; intermediate results from a batch query come back whole into context, and the next turn is billed again for the same content.
Pi's choice is to keep the core small: a few general-purpose tools (read, write, edit, bash), with domain capabilities loaded per project through CLI (command-line tools), Skill, Extension, or Package. Teams that need MCP can wire it in at the extension layer; the core does not lock all users into a single tool lifecycle, permission model, or UI (interface presentation). The cost is equally real: every team may end up reimplementing connection, naming, timeout, permissions, result trimming, and auditing.
Industry view
Supporters read this as a more honest engineering stance. MCP's official Client Best Practices already lays out two new paths—Progressive Tool Discovery (give the model an index of the tool catalog first, load full Schema only after a candidate matches) and Programmatic Tool Calling (let the model generate code that runs tool calls in an isolated environment, returning only the necessary results). Both of these confirm that "good experience follows naturally from connecting MCP" is a misconception: the protocol solves interoperability; the Host decides what enters context; governance responsibility was never in the protocol.
The opposing view is equally valid: moving the standardization cost from the core to every team means a lot of small and mid-size businesses and indie developers will reinvent the wheel—auth, discovery, caching, auditing, each one must be hand-rolled. CLI and private Extensions tend to lock in non-reusable conventions, and over the long run this is a breeding ground for ecosystem fragmentation. Pi's "small core" philosophy is a relief for mature teams and a burden for resource-limited ones.
Impact on regular people
For enterprise IT: When a company wants an AI Agent to connect to internal systems, the key question is not "how many MCPs did we wire up" but "who handles governance." Once the tool count passes 20, we recommend bringing the IT team in to design progressive discovery and permission boundaries, rather than letting business units connect directly.
For working professionals: If you're using AI to write code or run data queries and you see "AI picking the wrong tool" or "answers getting slower," in most cases the AI did not get dumber—it's that too many irrelevant tool definitions have piled up in the context. This is an engineering problem, not a model problem.
For the consumer market: The maturation of MCP-class standards means we'll see more lightweight "AI + enterprise internal systems" products over the next two years; but the difference users actually perceive will come mainly from how the application side designs context management, not from the protocol itself.