Pi now supports MCP. Why we changed our minds, what changed in MCP and in Pi, and what Codemode is.

620 points•yarapavan•about 19 hours ago•349 comments•

349 comments

alin23about 16 hours ago
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...

[1] https://lowtechguys.com/crank

mike-cardwellabout 11 hours ago
I gave claude an API key for Home Assistant. I can tell it to create dashboards, set up automations, diagnose problems etc, all using natural language. No MCP needed.

Yesterday I received a new thermometer for my aquarium to replace an old broken one. Both were bluetooth, but different models. I just told claude "I'm going to set up up my new bluetooth thermometer for my fish tank in a few minutes, keep an eye out for it and replace the old broken one with it in Home Assistant" and then walked away and put a battery in it and put it in my aquarium.

When I came back it had found it, replaced all my existing entities for the broken one with the new one, and verified it was all working with my existing graphs and automations.

FrinkleFrankleabout 10 hours ago
MCP is a tool more for security than anything else. If you give your agents access to an API key, there's a chance they can accidentally or maliciously leak that key. If the MCP server has access to the keys instead, it takes that possibility away. That's not always something you need to care about, but it is very important for some people's threat model.
ash_091about 7 hours ago
Verging away from the topic, but I've found Claude is a great addition to HA. I want smart home features, but don't have the time/inclination to learn HA's way of working. Historically I just defaulted to Google Home because it was easier, but with Claude I barely need to touch HA configuration at all.

Recently I wanted to set up a slightly complex routine involving some lights and a couple of motion sensors. It feels like magic to be able to describe the behavior I want, briefly discuss the implementation, and walk past the sensor and see it in action.

Vegenoidabout 9 hours ago
One of the key points of the comment you replied to is that you don’t need a very powerful model to do MCP stuff, such as local Qwen. The “let the agent figure it out” approach works much better with powerful models, such as Claude (which you mentioned you are using).
30minAdayHNabout 10 hours ago
I +1 this approach. We are doing similarly. Instead of providing MCP, we are simply providing API key and documentation. Folks are able to then just paste that link and use our service.

User will interact or build apps with simply text like: "Give me all the issues that are X, context: https://somedomain.com/llm.txt"

llm.txt will have all the API instructions

alin23about 11 hours ago
That's smart! That reminds me, I have to get back into HomeAssistant. I had my whole house through it a few years ago, but the complexity and things breaking in hard to debug ways made the experience too frustrating for my wife and visiting relatives.

Having an agent keep an eye on stuff and fix things proactively should make the experience much better. Plus I can no longer write yamls at last.

taylor-tgabout 15 hours ago
I just wanted to say thank you for making the tools that you have either free, or very reasonably priced. ZoomHider, MusicDecoy, YellowDot, and IsThereNet are some of the first things I install on my/my family's Macs (often before even Homebrew).

They're so powerful and yet get out of your way when you're not using them. I couldn't imagine being without them. Thanks y'all!

alin23about 15 hours ago
Hey thank you! Always nice to hear when my work helps others ^_^
rudcodexabout 12 hours ago
Had no idea that MusicDecoy existed! I just had music app pop up by accident too. Thank you for pointing those apps out
gojogsabout 14 hours ago
Hi! I've dabbled in implementing an MCP server/client back in March. To me a proper REST API and/or cli tool seems sufficient enough, agents use them with good efficiency. Any reason not to provide CLI or REST interface for your tools, but MCP for agents specifically?
alin23about 13 hours ago
In my apps, CLI came first which works through Mach ports as the IPC, so the "REST equivalent" of macOS apps is also present. MCP takes advantage of the same client-server architecture I created for the CLI, so there's nothing you can't do with the CLI that needs an MCP.

But in my case, a CLI was not enough.

Like, to the MCP I might say:

    Set Clop to make every video copied in ~/shots smaller, 2x and silent 
Then the MCP can use elicitation and say:

    By smaller, you mean re-encode to compress file size (factor can be 0 to 100 max compression) or downscale resolution (100% same size, 50% half size)? 
    And does 2x mean faster speed? In which case do you want to keep frames so the video plays smoother or drop frames for size? Or does 2x mean upscale? 
And the agent will present those as nice choice menus I can decide schematically on.

With the CLI I have to first read, learn and memorize the requests and commands needed for each app, the accepted values and formats and the steps to reach a specific result.

There's only so much space in my head I can leave for implementation details of arbitrary apps. I'd rather have an agent care about that.

And yes I get the irony, those are my apps, I coded them by hand for years, I should know their implementation details, yet even I forget if I should pass 50% or 0.5 for half size.

Btw Clop is a media file compressor for context: https://lowtechguys.com/clop

brabelabout 13 hours ago
How do they authenticate to your API?? Do you want to ask normal people to store an API key and remember to rotate it every so often?
anthonypasqabout 13 hours ago
agents dont always have access to a terminal. why is this so difficult to imagine
asveikauabout 12 hours ago
> 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

This seems like exactly the sort of thing I've done with shell scripts or even makefiles.

alin23about 11 hours ago
Nothing in there is innovative or unattainable, Clop uses open source tools behind the scenes anyway so obviously you can replicate it with scripts.

But this is for people that already use the app, researchers, writers, students, people that aren't necessarily comfortable with a terminal. And given Clop already implements the basics: an efficient file events watcher, tuned encoders for the Mac silicon, fail safe backups and UI for seeing the result and interacting with it in real time, it has advantages over trying to do it yourself.

kccqzyabout 11 hours ago
I used to do that using the macOS builtin Folder Actions. People forget these exist. Pure GUI.
selicosabout 12 hours ago
So you found them useful to script what other open source tools can do with basic automation tools? How is any of this unique to MCP?

Why is AI involved for any other reason than building the original test implementation?

alin23about 12 hours ago
This is for giving the existing users of my apps the ability to describe what they want the app to do without having to navigate and learn the UI.

Not sure if you got the right context, your question doesn't really make sense to me.

sublinearabout 12 hours ago
I find it exciting that the dust is finally settling.

We're back onto the original use cases for natural language processing. This is where all the value always was, and now the market has proven to itself what anyone with even a bachelor's in computer science already knew.

gk1about 13 hours ago
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.

yieldcrvabout 11 hours ago
> "... 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."

Thats my observation when people retort “whataboutism” in usually a geopolitical context

Its not ever clear to me that people are aware that their own country or a place they respect engages in the same practice as the place they are denigrating

Like, sure I would like both places to fix their problem but dont you have better things to do like fix your own?

CharlieDigitalabout 17 hours ago
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 general, the major clients have spotty implementation for some of the features in the spec.

[0] https://news.ycombinator.com/item?id=47380270

[1] https://chrlschn.dev/blog/2026/03/mcp-is-dead-long-live-mcp/

[2] https://github.com/openai/codex/issues/5059

Aurornisabout 15 hours ago
Everyone is so afraid of being left behind in this period of rapid AI change. The influencers are exploiting that to create anxiety and fear of missing trends.

I follow several influencers from pre-AI times who were (or were trying to become) social influencers thought leader types. People like Theo or many of the JavaScript and training course people. Following them was helpful to follow the trends that more chronically online juniors would be picking up and pushing at the workplace, which set me up in a better position to understand and then defend against it.

All of them, every single one, have dropped their previous influencer topic and pivoted to being AI influencer. Every time I see a post they’re either saying you need to adopt a new trend or that last month’s trend is dead. “Prompting is dead! Graphs are the future!” or “Claude Code is OVER! This new harness is 10X better”

MCP was one of these topics. Everyone went from telling you that you needed to use MCP or be left behind, to declaring that MCP was dead almost in unison.

The only pro-MCP holdouts were the influencers who had built their own MCP courses for sale.

ambicapterabout 15 hours ago
It kind of repulses me when these people will make a video about anti-AI sentiment and splice in an ad for an AI tool at the halfway mark.
rajeevkabout 16 hours ago
> My biggest complaint right now is that OpenAI has still refused to implement the MCP Prompts spec

MCP servers provide three things: tools, resources, and prompts. Of these, tools seem to be the only part implemented consistently across major clients like ChatGPT, Claude.ai, Claude Code, etc.

For prompts and resources, there doesn't seem to be a common understanding of how clients are supposed to consume them.

For example, if an MCP server exposes resources, Claude Code can discover them and consume them when needed without you explicitly asking for a specific resource. Claude.ai behaves differently. It doesn't automatically discover and consume those resources. Instead, it gives you a way to manually add an MCP resource to the prompt.

So while MCP defines tools, resources, and prompts at the protocol level, the actual user experience for resources and prompts varies quite a bit across clients.

hobofanabout 15 hours ago
In practice, the problem with resources is that many resource collections are too large to list exhaustivley, and if that's the case you will need to need to implement a proper search tool anyways (as the Completions utility isn't a good fit), at which point there is little use in also implementing all of that as a resource, rather than `list_`,`search_`,`get_` for a resource.
spennantabout 15 hours ago
The idea of "model controlled", "application controlled" and "user controlled" for tool, resources and prompts (respectively) was aligned with the chat interface. It breaks for the autonomous agent paradigm where the agency is the user and the lines are blurred. Unfortunately MCP has been mostly relegated to tool calling leaving potentially powerful capabilities on the table due to lac of client support for them.
CharlieDigitalabout 15 hours ago
I disagree on Prompts since virtually all of the mainstream harnesses implement them: Cursor, Claude, OpenCode, Copilot. Prompts are very clearly just a remotely delivered `/` command and it is easy to see why this is really powerful (single entry point, no need to update/sync skills, dynamic sets by audience, dynamic construction of the payload by audience, etc). For all intents and purposes, it should be viewed as an analog to local, text-only skills.

Codex is the only mainstream harness that does not implement this in the client.

justinhjabout 14 hours ago
Prompts I am not that sold on but it seems silly to not implement it in clients.

A good use case for resources is small amounts of commonly needed state that can be fetched and proactively updated by the mcp server, saving latency when the model requests it.

everforwardabout 14 hours ago
I’m still not entirely sold. I do hear you about team workflows, I’m just not sure MCP does that dramatically better (as of today).

I can see the snap appeal. One protocol, we can chuck an auth reverse proxy in front of all the MCPs, compliance has their integration point, etc.

I don’t think MCP is structured enough to give a huge edge over bash there. Looking at MCP messages, they aren’t immediately more legible than a bash command, output and exit code. You also don’t own a lot of the MCP servers you use, so backtracking for audits will require knowing what MCP commands did what back then.

I do suspect something more like MCP than bash will be the winner. MCP just feels very open source rather than enterprise. Eg I don’t think I’ve seen any sort of privilege escalation and logging scheme. The enterprise will want some sort of “request admin privileges” scheme. Likewise they’ll probably want more context on ACP requests; who is calling this MCP, using what agent, and for what project?

CharlieDigitalabout 10 hours ago
MCP is about the server side, not the client side.

MCP over HTTP buys you server side telemetry, composability, remotely held credentials (security), etc.

MCP is about enterprise control of the server side; no advantages on the client side at all.

brabelabout 13 hours ago
You’re out of the loop! I’ve myself implemented access escalation on top of MCP and it’s not rocket science. It’s already being used by Enterprise everywhere!
bmurphy1976about 14 hours ago
To be fair, the MCPs of 8 months ago are not the MCPs of today. You had to mess around with headers and .env files and local npm proxies and other bullshit only cli jockeys would tolerate. The MCPs of today are fully remote, stateless, oauth enabled, and integrated much more nicely into the the user experience. Click a button and it works.

I do agree, the "MCPs are dead" narrative was overblown, but there were legit reasons we weren't ready to go all in on them back then.

stymaarabout 15 hours ago
With stateless MCP, the MCP rube goldberg everyone was calling dead in March is effectively dead though.
CharlieDigitalabout 12 hours ago
MCP was already stateless capable in March. All the build I was doing was already stateless HTTP (which is why it felt certain that it was the future).
_fwabout 18 hours ago
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.

alexfortinabout 17 hours ago
Agreed. I personally don't use any MCP but I think it was a good move.

I hope they'll do the same and eventually add native support for ACP (https://agentclientprotocol.com/get-started/introduction) which, on the contrary, I use quite.

msdzabout 17 hours ago
Arguably, adopting ACP might even help Pi’s case, in that it could escape the terminal interface into one of many wrapper GUIs. TUIs inherently tend to limit your userbase to those who know what a terminal is… And given OpenAI’s latest product announcement [0] in response to Meta’s, the trend seems to be to attempt an expansion of customers to the general population, away from just developers and maybe “business” people.

Then again, I don’t even know if general adoption is what Pi/Earendil is going for.

[0] https://news.ycombinator.com/item?id=49896604

skohanabout 15 hours ago
You could already use MCP perfectly well on pi via extensions.

I'm not so sure about this move, or the general inclusion of code mode in the core editor as one of pi's main selling points was its minimal nature.

warmwafflesabout 12 hours ago
If Armin and Mario want, they can just as easily move this back into a package and make it an optional thing to support if they want. There was already a heavily used mcp adapter package that they appear to have just finally incorporated fully.

Though as time progresses, they are probably going to do the same with sub-agents.

mikeocoolabout 14 hours ago
Except there already was "something" that the creators of MCP just ignored.

Imagine a world where you could:

* Configure your favorite harness/chat client with any OpenAPI spec for an API that supports Oauth2.

* The harness would walk you through the Oauth flow and securely store the token.

* And then insert some tools for discovering the API methods and making requests in to the context.

* The agent could then formulate a request, call the request tool, and the harness would 1) makes sure it's allowed to make a request to that API, and 2) insert the Auth Token into the request.

It would be basically exactly the same way MCP is setup today, except all you would need is an OpenAPI spec. You wouldn't have setup a server for a janky new standard that's half implemented slightly differently by every harness/chat client.

internetterabout 13 hours ago
Yeah I'm not a huge AI bull but I've just never understood why MCP needs to exist when OpenAPI could've just been extended
KronisLVabout 18 hours ago
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.

sunaookamiabout 18 hours ago
Hah, it's the complete opposite for me :D. In Claude Code I disabled all sub-agents stuff, disabled nearly all tools but Bash, Edit, Write and WebSearch and replaced WebFetch with my own tool that doesn't summarize anything because the results were always worse with sub-agents, they always lack the necessary context and weaker models summarize bad. I also replaced the system prompt with my own that cuts a LOT of tokens, agents don't need a 10k+ system prompt anymore.
KronisLVabout 18 hours ago
That's interesting! You don't have cases where the main session has important planning stuff but the actual work to execute has so much crap in it that context compaction will probably dig into the important plan stuff too much and make it too lossy? Also what about the cache read costs for longer context sizes?

Using sub-agents for example also lets me decrease the default context size in Claude Code instead of running at the full 1M like:

  /autocompact 420k
or deal with Codex's 258k tokens (seriously quite tiny by modern standards).

Same idea with something like OpenCode, there I even configured custom agents for review: https://opencode.ai/docs/agents/

Pxtlabout 17 hours ago
That sounds like you just NIH'd mr Zechner's Pi Coding Agent. Those were basically its founding design: yolo-mode security, simple design, minimalist system prompts, plug-in based for anything fancy (even sub-agents and web).
buserrorabout 18 hours ago
I did the same, also, the fact the tools evolve so fast, I dont want to waste time on a particular one while it might be obsolete next week. So either it works now, other I pick something else.
DanielHBabout 17 hours ago
oh-my-pi is a fork of Pi that adds a lot of this stuff

https://github.com/can1357/oh-my-pi

I haven't tried it much though, can't vouch how well it works.

spiffytechabout 17 hours ago
Pi vs omp is hotly debated within my friend group. It has most things you could want, ready out of the box, but also a lot of things you'd never want and it's constantly 5% broken. Some people love that trade, others don't.
probstabout 17 hours ago
Exceptionally well is my takeaway. It’s the only harness I am using these days. I was previously using pi and codex mostly, but also the ones built into editors like zed, vscode, and the jetbrains IDEs.

On top of that, somewhat unrelated I’ll agree but still, it has support for vim keybindings

surgical_fireabout 17 hours ago
It's actually the main reason I chose Pi.

I did create some extensions where it spawns sub agents for specific tasks, especially when I want to keep the context clean or when I really want to offload a piece of work to a cheaper model. And for that I have a high degree of control over, I know which model is being used for each subtask.

I find Claude Code too unwieldy for my tastes. Pi's philosophy of being very light on features nut highly flexible for customization, clicked very well for the way I work.

embedding-shapeabout 18 hours ago
Some things are impossible to just tack on or work around though, like MCP, while other things, can be done by just composing stuff.

Like sub-agents, you could just instruct pi/any harness with a user prompt/system prompt to start new invocations of itself, if you share what the exact command is, and pi or any other harness will do their own poor man's version of sub-agent via standard unix programs.

none_to_remainabout 13 hours ago
I had the model write up a pi extension for logging the transcript to the syslog, and all on its own initiative it spawned a subagent to generate test output. It decided to spawn a lighter model for this trivial task, apparently unaware that I can only fit one model at a time so my llama-server ended up thrashing to the lighter model then back to the original model. My own personal n=2 semi- rogue swarm
k__about 18 hours ago
What would you say is a good harness with subagents?
fwipabout 16 hours ago
I found the MCP extension for Pi to work fine.

Read the full thread on Hacker News →

Related stories