Hacker News

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.

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!

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?

> 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.

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?

Where I found MCP's really useful is integrating with "consumer AI" (chatgpt.com, claude.ai, etc).

I'm working on a sideproject called Rowbly[1]. It acts as a sharable data store where LLM's can dump research rather than keeping it in their memory or throwing it into a spreadsheet.

At first I thought "I don't need an MCP, I'll just expose a CLI" but that carries a pretty big limitation in that it only works with agents on your computer (Codex, Claude Code, Pi, etc). For the folks on here this is not an issue and is often times preferable but I'm also targeting the average LLM user that primarily interfaces with it via "consumer AI" and with those tools the stuff you can do is very very limited.

I still think MCP's have a long way to go maturity wise and hey maybe in a few years we will figure out a better way to do things but for now, if you want to interact with consumer AI apps, there's just no way around using them.

[1]: https://rowbly.com

I use rcmd daily (and have just taken the time to dial in the configuration, it works even better now!) and I have to say that it's wonderful. It makes using the computer so much faster and easier: with window scripts too, it's like magic.

There were some teething problems on Golden Gate: keystrokes didn't seem to make it to the rcmd popup, but your recent remediations seem to have solved it. It's a beta OS version too, of course :-)

> Get Crank to start Time Machine backups immediately when I connect my HDD and notify me when the backup is done.

Is that not how it works out of the box?

I guess the best way I would put it is that MCP is an RPC for any software in a way that an LLM could interface with easier. Since MCP etc can work with things like Blender.

This has been what everyone who has supported MCP has been telling people, but coders just endlessly screeched about how CLIs are better.

Everyone on this forum has an absolute paucity of imagination when it comes to applying LLMs to any use case that doesnt involve coding.

> "... 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?

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.

> 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.

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.

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?

With stateless MCP, the MCP rube goldberg everyone was calling dead in March is effectively dead though.

These reason why they were proclaiming MCP dead and crowning CLI the influencer is that they aren't serious people. They're either vibe coders who never knew what the meaning of engineering for production or they are those who chose to forget the meaning because it fits their chosen vibe coder narrative.

Decent point - but - the same could be said for skills. You can have enterprise skills that don't require use of MCP.

Yep, number of new MCP servers this month is on track to be the highest it has ever been: https://bloomberry.com/data/mcp/

There is no reason to think about team workflows. Focus on your workflow. Your own custom local workflow is basically your competitive advantage as an employee. The moment everyone else can do exactly the same things you do, there is no reason to really keep you around.

The game has changed in the AI era. Horde secrets, skills, custom processes. Don’t share everything. Stop giving things away or you will have nothing left.

I mean it was a pretty classic hype cycle - MCP was massively inflated, the blowback was also inflated, and now we're in the happy state where there are same cases where it's genuinely better and differentiated and everyone will keep iterating on it. (statelessness was a big step forward).

> The key mistake people made was thinking in terms of their own workflows and own local stacks

We need a dunning-kruger for empathy: people least able to imagine situations not their own trying hardest to influence others.

Important to remember most ai influencers are a joke and spewing nonsense, claiming things are “over” is one of the only reliable and viable ways to for a person not at OpenAI/anthropic to actually make money in this wave.

> prominent folks in tech including Garry Tan

lmao not sure if you are being sarcastic but that guy is joker and a poster child of ai psychosis .

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.

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.

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.

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.

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.

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.

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.

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.

I do sometimes wonder about the value of the whole MCP spec rather than just adding some semi-standard attributes to OpenAPI specs to make them more LLM consumable.

Seriously, it just makes no sense.

https://chatgpt.com/share/6abd1842-cd34-83e8-997e-55c8bc23cd...

"Just use OpenAPI" doesn't handle the question of having a single well-defined OAuth flow that will work with desktop clients across the board, as well as various gotchas like rendering embedded widgets that will use that OAuth flow, elicitations for user decision points outside of the model control, and other such things outside of the API round trip process itself.

Having built out MCP functionality for actual use cases for a small company, the big gotchas for us that can't be handled with "just an API" (putting aside the auth flow thing) have so far been (a) fully custom UI pieces in GUI clients (for example, media embeds with custom rendering) and (b) having the ability to put a user-facing hard stop in the loop for some interactions.

Part (a) in particular is pretty prominent for us since our uses cases are all about video, and having "just" an iframe URL to supply, with no other interaction with the model/turns, would give a pretty janky and unpleasant experience if Claude/ChatGPT even allowed it to embed.

As a provider, I can add a tool or change instructions on my MCP server, and you'll get it on your next connection, sometimes even mid-session.

With a skill, updates depend on whatever channel delivered it to you. Whichever channel that is, it's out of my hands as a provider.

So, MCP solves the problem of coordinated distribution of updates to a larger subscriber base. Think inside of a company, for example. I don't have to go around and tell people to `git pull` their skills folder.

Im sure there are more reasons but updates to prompts and tools coming from the server side is a major one.

It's typed so you can build some governance around it, by allowing only some tools or parameters for your org (this is a pretty weak point, but still)

A skill has one giant description from the frontmatter loaded into the context, where MCP loads a smaller one for every tool. Not necessarily better, the skill approach is often better actually, but sometimes the MCP approach fits more

not all agents have access to a terminal. not all agents are coding agents. a cli is a versioned piece of software that the user has to update to get new features. APIs can change in the background and add new capabilities.

MCP's have all the same advantages that a rest api has over a cli.

The biggest win for me is they can have state. So you can log in to an MCP (via oauth) and not worry about having to refresh tokens locally or in the ENV. I use it for Trello. I log in, then I can call all the data about my board. No CLI to install, no token to copy-paste somewhere. It just opens a browser tab to log in when required, next, next, next, and it works.

MCP is like Docker or Kubernetes. If you are operating at a certain level of abstraction (low), these tools look like they are getting in the way more than they are helping. For others, they will seem absolutely mandatory. It depends on what your goals and constraints are with the project.

Plenty of companies will supply an MCP that will never, ever provide a CLI command or free-floating API keys.

To explain, let me rephrase the question: what can a standard API and remote server do, that a local program and AI-hallucinated text file can't do?

To rephrase the question: what can a standard API and remote server do, that a local program and AI-hallucinated text file can't do?

We will write about it. The best way to think about it is that codemode solves a different problem than bash in that bash is a way for the agent to run a particular tool: running bash.

Codemode is a way for the LLM to orchestrate harness level tools. The reason this happening now, is because the models by the labs are increasingly trained on this. Codex for instance in responses lite requires codemode to even perform parallel tool calling.

Codemode is a fancy name some MCP authors coined for the practice of providing scripting/method chaining for their MCP tools. It's generally implemented by providing some kind of code execution tool, the LLM calls it with a script, and the MCP server runs it in a sandbox.

It's pretty effective because of the reasons you noted, but there's a composability problem since each MCP has its own sandbox and can't call into the other ones.

IIUC Pi offer a workaround for this, the harness runs the sandbox and populate it with the MCP tools, that way the composability problem is solved and every MCP do not have to implement their own sandbox.

yes codemode is when you want to utilize this ability AND you want MCP tool calls as part of your scripts

codemode lets you execute scripts in a runtime where your MCP tools are made available as function calls

this matters for cases where the MCP tool is the only way to do something and you do not have an equivalent CLI, API, whatever to script with

From my understanding, code mode came about due to some agents not having access to a shell.

Pi doesn't even support a permissions model. It's extremely barebones, you're expected to customize basically everything.

I happen to think codemode is useful, but not the full answer. I have a long and skewed history with chaining things in MCP and built a dozen or so enterprise ones (see https://taoofmac.com/space/blog/2026/04/29/2341 for notes) and it all falls back into the trade-off between agent scope/context and tool coverage: If you are using a coding agent it will have no trouble sorting out any tool regardless of how many are exposed (it's just a matter of either progressive tool disclosure or good tool metadata, since the coding agent will just go at it and expend whatever tokens are needed), whereas in a "normal", limited, scoped agent that has only a few things it needs to do (like handling a ticketing system) codemode is pretty much overkill.

Pi is primarily a coding agent, so yeah, code mode makes sense, but I've found that better MCP design saves everyone a lot of trouble and would also probably have improved the thing's reputation overall (I personally am not fond of the line protocol, would rather have protobuf and more typing, but it is what it is).

> Normally if LLMs want to compose multiple operations, they have the perfect tool for this: bash, or whatever other OS shell is available.

I many scenarios, e.g. running the harness server-side, as is the case for chat interfaces, you don't really want to expose OS shell access as that opens up a huge security attack surface.

Cloud products based orchestrations with proper security mechanisms configured, don't have shell access and should only communicate over proper network mechanisms.

Rootless immutable containers without shell access, or SaaS products from multiple vendors with WebAPIs as the only touch point.

Uh, you just figured out their motivation and you somehow came to the opposite conclusion?

Bash is an interface to operate Linux computers. It's not a web interface at all. It's the worst interface for the web.

Code mode is just them running JavaScript for web based APIs. They are using the web native programming language for web tasks. It's actually completely logical once that is clear.

Bash for the web is a terrible idea.

> Is this how "MCP" server is typically implemented (no encryption).

No idea. The boring (in a positive sense) answer I'd expect for any backend API server is that encryption in transit is handled by TLS. So I'd expect either the MCP server in question can be configured to support TLS connections & refuse plaintext HTTP connections, or that for a production-like deployment it expects to be deployed behind a reverse proxy that is responsible for terminating TLS.

I still don’t understand why it wouldn’t be able to navigate an API or CLI the same way it does mcp. But honestly, I don’t care anymore. The agents are so intelligent it doesn’t matter tbh.

MCP makes my boss happy so I’m happy

Soon https://developers.openai.com/plugins/build/mcp-events

I think the concern is less over this specific feature and more about what this means for the project roadmap, now that they've chosen the route of built-in rather than first-party extensions.

Add in the context that they're also building their own inference provider[1], and there's certainly a non-zero risk that the project trends away from the barebones platform to build on that people signed up for.

[1] https://radius.earendil.com/

also consider oh-my-pi. it is much more "batteries included" than Pi

Pi

You could turn it on its head and it could be exactly the opposite - that the people who are the most angry, sarcastic, etc are exactly the kind of issues that you should automatically close and ban from creating issues for being non-civilized productive contributors.

Doesn't have to be used for prioritization purposes. Obviously a little annoyance is to be expected at times, but you could explicitly ban egregious angry behavior in your project.

this is how i've been solving the problem before some of these newer techniques around deferred loading etc. came out

a subagent per mcp toolset, basically sub agent per saas in the configuration at $WORK

I don't have any hard evals on this but it feels like it works more than it doesn't, especially now that subagent use has gotten better in general, but you do feel drawbacks if you ever need to do something that involves coordinating multiple sub agents, there's some communication overhead that wouldn't be there if it was just one agent with all the tools to do the whole job

that seems more niche and also covered by extensions.

Even Anthropic moved to auto-approve by default and they are kings of fearmongering.

Have a go at https://github.com/rcarmo/memento, I would appreciate Claude testers since I mostly use Codex. Just trying it and filing an issue about what doesn't work would be great...

I'm pretty sure MCP will degrade to a bridge for authentication plus an adapter for the main protocol types. After that you just use whatever industry standard protocol that suits your specific application.

Same here. At the moment I upload the file to s3 and pass the file link, but there should be a way to pass files alongside the chat.

We are working on it! https://www.arcade.dev/blog/model-never-needs-to-see-the-fil...

To be clear: absolutely not the plan and nothing is loaded by default that was not loaded before.

You can turn those tools off. In fact, that is what I am doing right now in https://github.com/rcarmo/piclaw until I am positive the new MCP stuff has full parity with the MCP adapter I've been shipping for the past six months or so.

I'm actually pretty happy that they did it, since 90% of what I have to integrate in enterprises is MCP-driven (it's a security and auth boundary that has become pretty much mandatory for any third-party agents wanting to reach into corporate data) and this lets me use Pi directly. Am just being cautious about the first version, because, well... it's a first version, and I like my tools stable.

(I actually played around with the idea of using QuickJS myself for codemode, but since I rely on Bun that gives me the ability to use other things... never got around to do it though.)

> @the_mitsuhiko - How is the session replay of Pi embedded in the article?

Some bespoke slop :)

There is a MCP SEP that outlines multiple ways, that I hope will sooner or later be accepted: https://github.com/modelcontextprotocol/modelcontextprotocol...

While we are waiting on that to become stabilized, we implemented a inspired/co-evolved way to do that in our tool[0], where you mark individual fields in the request/response schema as being file payloads, so that file exchange can be properly orchestrated by the harness and doesn't pollute the context. We just do inline base64 uploads of the required payloads, which in practice we've seen to work quite will until ~100MB files (which is otherwise also the size limit we usually recommend for file processed).

It's annoying that it's not stabilized yet, but for most bigger customers we've seen, they implement 80% of the MCP servers they connect in-house, so doing adjustments to the tool surface, and metadata has been less of a pain for them than we expected.

[0]: https://erato.chat/docs/features/mcp_servers#file-support

I just implemented this with oauth - basically I have a tool that returns a signed URL that the client can PUT the file to. Works in ChatGPT Work mode. My use-case was to have the client generate an image and upload it.

I have had to hack a couple of workarounds in https://github.com/rcarmo/memento to do uploads, and there's a draft going around, but the general practice in enterprise MCPs seems to be to do it "out of band" and have MCP tools to hand-over storage handles/URLs so the MCP server can do the imports itself "safely".

Author of the post here: I don't think it's a good idea to put your clanker to a PR and then try to explain it. That's because you are then reading a derivative work of a derivative work instead of going to the source.

If we fail to explain it, then we need to do a better job explaining it :)

> Key Feature: Respects your terminal — Streaming Markdown and live tool output, reflowed for display in the terminal. Only redraws the current streaming line or the input area, native scrollback is preserved. Does not take over or mess with your terminal.

Thank you. I've been frustrated by harnesses hijacking the terminal and breaking basic features such as scrolling and text selection.

It even sends BEL when the agent completes, which makes so much sense, yet Pi never implemented it.

I'm definitely going to use it over the next few days and hopefully make the switch.

In enterprise integrations, that is just not an option. MCP has pretty much taken over there.

Theres transport and context management. A cross agent status cache with semaphore over a testing harness driving a browser that can rewind and retry is much easier for agents to drive from mcp than selenium or whatever is fashionable these days. Didn't replace unit testing per se but to rca and fix it's a much better tool.

It's exactly that, but I don't see the issue. API+Docs under a single URL looks like a win for me. It also warrants a new name.

That seems a bit unfair. The choice isn't between opinionated vs unopinionated, it's "which layer do the options live at?". The harness has to be somewhat opinionated about the implementation of the agent loop, otherwise what is the harness exactly. I guess the question is if I don't want the new "code mode" changes in the loop can I trivially ignore it, but it seems it has to be implemented in the core.

I find it pretty handy. I run any bash tools in a restricted sandbox, and so that it cannot hit the network (usually). I don't want any credentials to be available to the agent, and my trust boundary for that is precisely the harness vs. the agent. Harness can touch secrets, agent can't (filesystem is restricted from it being able to read any secrets as well).

that's my one problem with the cli vs mcp debate. I prefer cli, because they're tools I'm familiar with, and they're composable. My problem with it is some cli tools need to use secrets to access things. By making sure they only go to the harness, then I've got my problem solved.

Now it is http, but previously it was some kind of binary protocol. And it was ... statefull, which is mind blowing, why would it be in the first place.

Nowadays they moved to http and stateless.

MCP is only for agents, bash (and CLI) is for agents and people.

Most people using pi probably know. MCP is “model context protocol”, a protocol by which models can connect to apis and services and conversely a way to expose those apis and services so they can be used by llms and agents. https://modelcontextprotocol.io/docs/2026-07-28/getting-star...

1. The first paragraph has a callback and link 2. You're not the intended audience of the post most likely

It's just like API-s, but with built in documentation.

If you don't know MCP by now that's between you and google

MCP is the NIH non-standard version of OpenAPI.

How on earth does the article no address the title? Literally the first paragraph basically "spoils" the entire article and you have your answer, then you can continue reading for more justification of why it was like X before but now it's like Y.