Hacker News Reader

Comment by _fw | Hacker News Reader

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.

View on HN

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.

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

The "general adoption agent" for Earendil is their other product Lefos, that is based on Pi and uses email as the interface.

Good points.

About what Pi/Earendil is going for, I can't really say but a while ago they created quite a stir in the Pi community for adding a trust system[0] which for many (me included) went against the loudly advertized "yolo" phylosophy, at that time I speculated it was a move to make it more palatable for the general population (whatever that actually means), so I'll stay optimist for ACP adoption for now.

[0]: https://pi.dev/docs/latest/security#understand-project-trust

I’m not sure; the integrated GUI seems like a major differentiator for them.

Pi’s agent is supposed to be simple, and a simple ACP agent is like a couple hundred lines of code. Making a system that allows UI plugins is way harder.

Also not sure if you’ve seen but you can get ACP from Pi with https://github.com/svkozak/pi-acp It bridges Pi’s RPC mode to ACP, works okay but not amazingly. My thinking level selector in Zed has never worked with it but everything else I use has worked (I’m sure other things don’t but I must not use them).

FYI Pi can do RPC over stdio (though of course it's a bespoke thing, rather than standardised). I use Pi every day; never used the TUI (I forgot it even had one).

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.

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.

I think MTP is kind of ok, since it's a common protocol, but I think incorporating sub-agents could be a mis-step.

There are a lot of ways to implement sub-agents, and it's not something I need the harness to be opinionated about.

I know builtin tools support opt-out, but it's more bloat. It's also more complexity for the agent to understand when you use it to build extensions for itself.

Every tool marketed as minimal is usually just an excuse to ship something with limited features. Unless there is a strict design ethos at its core [0], it’ll eventually grow its features to no longer be minimal.

Further, pi is now owned by a company which as we all know, tend to explode code with features while chasing product market fit.

[0]: https://bower.sh/smol-contract

Performant and robust are relative. Better than browser or click automation.

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.

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

For that matter, why does OpenAPI need to exist when IDL could have been extended?

Reply on news.ycombinator.com