Pi.dev reverses course and adds MCP support to its core
Pi.dev: You Said No MCP
Pi.dev once proudly declared it would never support MCP, and its team dismissed the protocol on podcasts. Now MCP ships in Pi's core. The shift came after rethinking MCP's evolution and building Codemode, a JavaScript sandbox that orchestrates tool calls. Pi's makers argue MCP should resemble OpenAPI with intelligent tool discovery, and they want to help shape it for small harnesses rather than watch from the sidelines.
We believe the best way to positively influence something is to embrace it.
- alin23
Lately I found MCP to be much more than a coding tool. For example, I implemented it in my more complex macOS apps [0] like rcmd, Clop, Lunar, so they can be configured by natural language.
So even with a local Qwen and Pi you can now say things like:
Set up Clop to optimise any PNG that I drop in my website assets folder and convert to a webp with the same name near it
Get Crank to start Time Machine backups immediately when I connect my HDD and notify me when the backup is done.
I want to be able to hold rcmd and fuzzy search and focus cmux agent panes
BetterTouchTool has a great MCP which can create native SwiftUI views and bind them to hotkeys, trackpad gestures etc. It can leverage its immense macOS automation tools and private APIs to let agents do Computer Use.
You would need a much more capable coding model to code those tools from scratch and get the same fail-safe logic that the apps have honed over the years.
Like, since MCP, Crank [1] has fully replaced my use of crontab, launchd, scattered scripts I run once a week. Not that it could not do that before, but it's so much simpler now to just describe the automation and have it happen reliably and visible in the UI. The friction is gone.
[0] https://reddit.com/r/macapps/comments/1wkv0dy/mcp_in_macos_a...
- gk1
Props to the team not only for changing their minds from a strongly-held belief but making it very public and not hiding the fact that it's a reversal.
The linked post from Armin is gold:
"... whenever you are confronted with a very strong opinion about a topic, reasonable discussions about the topic often involve arguments that have long become outdated or are no longer strictly relevant to the conversation."
(https://lucumr.pocoo.org/2016/11/5/be-careful-about-what-you...)
And that's from 2016! These days if you're arguing from a position you took even a week ago, you already might be out of sync.
- CharlieDigital
This was the easiest call and many like me made it in March[0] among all of the anti-MCP wave of influencers claiming it dead (many, many prominent folks in tech including Garry Tan). Literally every tech influencer in every social feed in March was calling MCP dead and crowning CLI the winner (completely ignoring every reasonable argument around security, observability/telemetry, ease of deployment and operations, etc.)
A direct quote from March, 2026[1]:
> If you’re still not convinced that a lot of this discourse [regarding the death of MCP] lacks nuance and is just hype, congrats on buying into the current AI-influencer FOMO hype cycle; see you in 6 months when the influencers move on to the next revelation of the moment to stay relevant and get your eyeballs and dollars.
It was fairly obvious why MCP would be needed once AI engineering and uptake moved beyond the solo developer and single harness stack of "what works for Me" versus "what works for My Team", particularly in an enterprise context. The key mistake people made was thinking in terms of their own workflows and own local stacks instead of a team's workflow and a team's operational stack. There was also an ignorance of MCP's stateless HTTP mode (yes, it was already a thing in March; the 2026-07-28 revision of the spec just prioritizes it as the primary focus moving forward) versus local `stdio`.
My biggest complaint right now is that OpenAI has still refused to implement the MCP Prompts spec[2] and in g […]
- _fw
I appreciate their reluctance towards MCP, but /something/ is better than nothing.
It’s suboptimal for the reasons the author outlines: but so is USB-C. So is NVME, so is HDMI.
We use these hugely successful technologies in spite of their flaws because they’re widely compatible and easy for the end user.
That’s why MCP is everywhere. It might not be performant, robust and uniform but it WILL get better over time.
And I’d much rather have the broad MCP ecosystem that we have now than seven or eight different “optimal” ways of plugging in an LLM to something useful.
- kingkongjaffa
We need to stop naming companies after lord of rings lore.
- KronisLV
I feel the same way about needing support for sub-agents, those feel pretty foundational to me.
I suspect that a smart model driving multiple dumber models for work and then using sub-agents with the same smart model for adversarial review will be a pretty common pattern.
Personally, I got a bit confused about Pi having most of that stuff as plugins since I remember how much of a mess Eclipse was where so much was just loosely fitting together plugins and just went with OpenCode since it covers most of my needs out of the box. Guess that might also be a sign of me getting older, because my IDEs and desktop environments are all closer to stock too.
- abtinf
> The way we like to think about MCP at this point is that it should be much closer to OpenAPI with intelligent tool discovery. That means tools should return structured data and tools should be discoverable by their documentation and description.
OpenAPI is “intelligent tool discovery” (whatever that is). OpenAPI literally “returns structured data” and is “discoverable by their documentation and description.”
Just once, I’d like to see someone explain MCP in terms that suggest they have any idea what they are talking about.
- statenjason
I use mcporter[0] for consuming MCP when suitable CLIs aren’t available. It exposes MCPs as shell commands. Agents compose using standard shell primitives. Tool returns json? Pipe into jq.
Another perk is it allows me to run tools in the exact same way as agents instead of treating MCP as a special way to call on services. Super valuable when debugging.
- CamilleScholtz
I don't understand MCP still? What can MCP do that a skill + cli can't? I've been using hax (https://usehax.dev) and haven't missed skills at all to be honest.
- NichoPaolucci
I had no idea pi didn't support MCP! I'm a new user, I just started messing around with it. I was getting my tooling up and running and tried to get one of my database MCPs working (Which, in retrospect, seemed a little painful - but I guess I was under the assumption that it was my responsibility to build + maintain those connections).
Another retrospect note, "No MCP" appears to be the first icon on their front page - not sure how I missed that.
Imagine my surprise reading this!