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.
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.
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.
> MCP is a tool more for security than anything else.
+1 to this; API keys mean:
a) Your agents are overprivileged by default
b) Your API key is more likely to get into logs and pre-training / leaked as FrinkleFrankie mentioned
c) You can't manage it centrally with granular tool policies in Enterprises. (e.g. "you're not allowed to read slack channel for #finances")
Also, you can always collapse MCP to CLI, so MCP as auth/security middleware makes a lot of sense.
> MCP is a tool more for security than anything else.
The agent can get to the resource through the MCP server or using API key. I personally do not see the benefit MCP is providing here. Sure you can reduce the exposed surface at MCP layer, but I do that at the API layer. I don't need to add another layer here.
I can kinda understand if you do not have control of the API layer and/or you have to expose the API layer to the public Internet as well. Most of the time that is not the case for me.
There are many ways to do this without using mcp, for example one of the many proxy servers that inject the token into requests. I use a custom solution that redacts all secrets to agent transcripts before the agent sees them in a hook.
I find it way better to be able to confidently tell agents to use CLIs than worrying about partially implemented mcps that need configuration and are often yolo’d with npx @latest anyway
My own approach is to put the API key in the MCP server, apply principle of least privilege there, and firewall access to MCP with agents being on same private network with Tailscale.
Not only giving an API key to an agent can leak to the model because of harness issues or too broad reading rights, but also most providers don't give the ability to apply principle of least privilege to an API key.
I don't want to give an agent full R/W access to any of my services/accounts.
The agent doesn't, the harness does. It's separate from a normal conversation / agent runtime environment. How do you suspect auth keys can leak from an MCP that's been added to chatgpt.com?
With a different key, obviously. This lets you keep the MCP server firewalled to your local network only while still allowing home assistant itself to access the internet
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"
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).
It still takes decent hardware to run local LLMs that are at all useful. What would be really cool is if we could get useful LLMs on hardware cheap enough to go into “things”.
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.
For Home Assistant, the MCP can enable the LLM to make changes without using up excessive tokens.
For example, the only way to make a change to an HA automation via the API is to POST a whole new copy of the YAML, even if changing one things. The skill and HA MCP I use allows the LLM to use tools which make more precise changes without excessive context usage.
Certainly still works either way though. And of course your LLM instance could just roll its own tools to do the exact same thing.
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.
Developing for HA with Claude has been great. Not only can it make all of those yaml changes based on natural language goals, but it's so easy now to create a custom dashboard or configure various apps. I was struggling with both the ChoreOps docs and its fairly cumbersome interface until I pointed Claude at it and told it what I was trying to do.
One of the nice things about MCP is that the tools have descriptions that provide guidance to the LLM. You can provide documentation in other formats like OpenAPI but its nice that the documentation is so closely coupled with MCP servers.
> One of the nice things about MCP is that the tools have descriptions that provide guidance to the LLM.
It is more of a curse than a blessing. MCP pollutes agent context even when you are not using it. Use a manually invoked skill instead if you don't want to be wasting tokens on every turn and bloating up agent context making it dumber in the process.
Thanks. It sounded like something more since you asked it to look in a few minutes time. I’m not familiar with the cli tool (I just use vscode) but I assumed it was openclaw you were using or something.
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?
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.
You answered "Why use MCP with your agent instead of using CLI manually?" but the more interesting question is "Why build an MCP when you could already point your agent to the CLI?". The user experience of "the agent will present those as nice choice menus I can decide schematically on" will probably be the same since agents are very adept at using cli tools and gathering required/optional arguments, examples, and warnings/errors to present you with useful choices on how to proceed.
The most important reason is that I can keep the CLI output and help for humans, while the MCP can be crammed with information for agents.
Plus I can add some complex commands like in the rcmd Stages [1] case where the agent can create a 4 monitor layout with apps and windows placed where you want, with every window opening the document/folder/project/URL you want and running the terminal commands you need. Sure you can do that with the CLI, but it's hard enough to get right because of shell quoting issues, that even an agent can get it wrong.
For simple tasks though, sure, the CLI is just enough and the agent can use it without needing to install yet another MCP. You'll know when you need it.
EDIT: I just remembered, you can even hook the Claude/Codex/Gemini desktop app to the MCP, while you can't get it to use the CLI. so there's that for users that still don't feel comfortable at a terminal, which is a number higher than you might estimate.
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.
I'm not intending to denigrate your tool. I'm just commenting on the "look at how we go full circle" aspect.
I will point out that the shell script way uses less resources than an LLM making a tool call. But I understand that these scenarios are not necessarily meant for the same user.
Oh for sure, I would prefer to have the automations as invisible things running at the system level, doing exactly what I want and nothing else, not wasting resources on UIs and event watchers I might not need. I would get rid of my own apps if that was easy to do.
But it seems we need to waste some resources to get some usability in return.
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.
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.
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 :-)
Thank you! Yes, macOS 27 continues to be a pain with the all new rewritten window manager.
Still working on finding all the edge cases, so sorry if you still encounter problems there. I've been using it since June and still find problems in input handling.
Like there's this thing, where if an app has Accessibility Permissions and listens to key events (like rcmd does) and then you revoke that permission while the app is running, then your whole system will stop responding to keys and clicks. Until you kill the app in question, but how are you going to do that without a keyboard?
All apps have this problem, even established ones like BTT, because it's a recently introduced macOS behavior in how the internals of CGEventTap work.
Yeah, I thought so -- I imagine quite a lot has changed behind the scenes. It does seem much better than Tahoe, though.
Yikes, that accessibility bug is bad LOL. It seems a bit like Linux in that way: certain bugs hang around for years. I always found that with Linux, you could either use an LTS and stick with the same bugs for years, or try your luck with a rolling release and trade them for new ones. Anyway...
I've just started leaning more heavily on the window switcher (moved it to Lcmd) and it's made me so much faster. Had rcmd for ages but never changed it to that; it solves the problem of "where the hell did I put that window?!" when I try to organize stuff into different spaces. It's a better candidate for Lcmd too IMO: I very rarely wonder where I put a random window of an app (and after all, if it's already open I usually want to choose a window), but I'm always switching between certain windows of one app, like Safari. Swiping back and forth between desktops was a nightmare!
I haven't even considered using MCP for locally-running apps! I mean I used to, but they almost always got associated with cloud service access and integrations nowadays, and most local stuff is trivially handled with agent skills.
Thanks for the tips. TIL about BTT having MCP support. Crank looks very promising too, since it looks like a more effective Shortcuts and Hazel replacement
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.
Not really. macOS may wait for idle time, may prioritize internal disk and the backup will go extremely slow on an HDD, there's no notification whatsoever.
It's a very specific thing for me really, I connect the HDD specifically for doing backups as fast as possible then I want to disconnect and store it back so I can keep using my laptop. I don't have a desk anymore where I can keep these things connected all the time.
This isn't restricted to agents. It's generally annoying when any service I may want to use programmatically is exposed through a CLI but not an API. Sure, I can call a CLI from most programming languages, but I/O beyond arguments and return values is at best awkward, and especially on non-UNIX OSes performance can suffer due to process creation overhead for every command.
Recent example: The AWS CLI has a convenient "s3 sync" command that does a one-way directory sync, only downloadiong new files if existing files with matching sizes and timestamps don't exist, but the closest thing the .NET SDK has unconditionally overwrites destination files.
Another example: one of the nicest things about C# is how the compiler exposes itself as extensive library functionality, so, not only can I compile and run code at runtime, I can generate this code from programmatically created ASTs instead of text, parse expressions into ASTs, etc.
Yes - Or a working directory that’s under version control where they can write arbitrary memory files and maintain working state across contexts.
These are things devs often take for granted as being part of ‘how chat agents operate’ but they are specific to how claude code/opencode/pi/codex operate.
Giving agents a Unix computer account they can play with is definitely a powerful tool that makes them capable of doing a lot more (see: meta muse, OpenAI dots), in much the same way that giving a human a computer they are trained to use makes them way more capable… but it’s surely not the only way we can run these things.
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."
> "... 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?
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.
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.
Spliced in likely refers to ads they splice into their own videos, which they control completely. The platform ads are separate from the video and the creators do not have control over what is shown.
> 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.
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.
That feels like it should be the obvious use case for something like a `?q` query param, formalized or not, but it seems like nobody working on the spec and libraries ever considered query params as a use case, since they're still broken in the Typescript library.
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.
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.
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.
Prompts is possibly one of the most useful enterprise features for MCP.
Dynamically target sets of `/` commands to teams in an enterprise by their identity+claims? Legal team gets a set of skills? Finance team gets another just by their roles? Always up-to-date delivery of what are effectively remotely served skills? Telemetry on who is using which skill? Server-side rendering of skills so that common skills can be composed? With placeholders replaced by user- or team-custom options? Easy to ship new skills as long as the user has connected the MCP? Easy to retire skillsets that are outdated across the entire enterprise?
MCP Prompts is one of the most powerful capabilities in the spec for enterprises.
OpenAI team: if you are angling for enterprise, you need to get this solved. Your FDEs are going to make a killing getting this set up for enterprises. Build an enterprise skills management platform around this that's integrated to their directory. Streamlined setup of the MCP via MDM. Telemetry on enterprise wide usage of curated skills across the enterprise, by team, by individual. You need this.
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?
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!
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.
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).
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.
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.
If that works for you great but I am where I am in my career by helping everyone I can around me. Making my team and the company better pays dividends and you stand out from people that only work for themselves.
This is now an outdated mentality in the AI era, where people will quickly use whatever you put out to make themselves better but little to no benefit will return to you beyond maybe a fuzzy feeling. People already feel proud just prompting huge projects out and claiming it as their own work. You will not be recognized.
“When a favor becomes too large to repay, the gratitude turns to resentment.”
With the v2 spec, MCP became a lot closer to APIs by becoming stateless. And there is now a push to use HTTP verbs more extensively to improve caching even better in v3.
MCP is converging into APIs but wit great auth and auditing
I'm not trying to be a dick, but it's pretty hilarious that we made these two posts at the exact same time [0]. I totally get what you're saying, but I don't understand the motivation behind it. A properly designed HTTP API is what Roy Fielding was discussing in his dissertation, but he was obviously talking about HTML pages full of hyperlinks. At the end of the day, does it really matter much if the definition is only 80% correct if the majority of the population understands the basic gist of the conversation?
If you can build the ultimate evolvable client, then you can collapse all UI into a single client.
Basically Roy Fielding told us to build an API that can only be operated by a human like intelligence, nobody could implement that because such an intelligence did not exist (hence the switch to imperfect HTTP APIs), and now that LLMs are a thing, said human like intelligence exists. This means Roy Fielding wasn't wrong, he was 25 years too early and ironically people should be building real REST APIs in the pendantic academic sense from today on and not the "pragmatic" HTTP API.
It's annoying, but that's been pretty common for the last decade. It's just like how everyone uses "REST" to mean "JSON RPC". In the end, we all basically know what the other ones are talking about, so it's pretty pointless to get bogged down in semantics.
It's common when talking about web services, where the kind of API is generally unambiguous. The problem here is we're discussing different kinds of APIs (shell commands, MCP, REST / JSON RPC) and so calling one of those kinds of APIs "API" is very confusing.
MCP is not strictly an API; it's a protocol shape (thus the "P" for Protocol) for delivering an API.
The API surface exists in the MCP payload.
Whereas application teams previously would have focused on APIs for external access, they now have to focus on MCP entry points (often to those same APIs, but with a different shape).
Yeah I always just thought of MCP as best for the average user and then CLI as one of the tools of choice for power users. Never had to be one or the other, I use both daily
Sure, but now you have a distribution and telemetry challenge.
It's hard to customize those skills. How can I tweak my skill a bit to match my workflow? With MCP Prompts over HTTP, this is easy: you can server render the text with my personalization specific to me.
It's hard to tell which skills are being used. With MCP over HTTP, each Prompt call, each Tool call is an HTTP request and you get telemetry on activation. You can server compose the response and ask the agent requesting it to return a score on how useful it is, too. Or ask it to call another endpoint to rate the skill.
Enterprise skills delivered to the disk you cannot do this. If a skill is flawed or outdated, you cannot revoke the skill at an enterprise level. MCP Prompts: it's easy to do.
An MCP and a skill are just two ways of distributing capabilities.
For telemetry ... well the agent should still have it's http logs? Also, I'm not sure MCP Telemetry is the primary point of concern for most things? Like thats a skill debugging thing?
I sync a skill in a file with my repo. I can't edit that skill. I can't combine that skill. I can't customize the skill without affecting the other folks on my team or I have to put that in a gitignore.
A user getting a skill via a plugin and wants to keep it in sync with the source has the same problem. Next update/sync wipes out their changes.
Skills delivered via file system download/git are like Deck.final.v2.real-final.2026-10-01.published.pptx. Skills delivered via MCP over HTTP are "live" and dynamic.
An HTTP MCP server is just a server returning text. The MCP prompt can be a template. It can have placeholders. I can build a UI to allow the user who logs in to customize the prompt/skill by filling in the placeholders. If they don't put a value for the placeholder, I render it to the HTTP response stream with defaults. I can dynamically render the skill, tailored for each user like I can render JSON or HTML for each logged in user. MCP Prompts just returns text. I can render any text I want on a server. I can return a different, more suitable skill text for the user. I can personalize it based on their workflow. The base template is always up to date for every user, etc.
Try it. Go write an MCP HTTP endpoint delivering a prompt. Now make that dynamic and serve different text back based on different users. Now your users are in different teams. Render variants of the same prompt/skill by team. It's powerful.
You can't do it in a team environment. You are missing the key point. Teams.
Please, go build the simplest MCP server you can that serves a prompt. Now make it dynamic by user. Now let you users share a common template. Now look at the telemetry you see on the server when someone uses the skill. Now add a flag to turn some on and off. Now imagine you are in an enterprise and you want to centrally manage all skills across the teams mapping some skills to some teams, revoke skills, force update skills, compose skills by user automatically using rules.
Please. Just try it. You can literally vibe code this in a few minutes and connect the dots.
A file on disk is static. An HTTP request-response for text is not. Build just one prompt endpoint. Now imagine dynamically injecting text into the skill as well because it's just HTTP.
You are arguing why we need web servers when we can just email text files to each other, save them on disk, and open them in Notepad. Do you not understand the power of using an HTTP server for sending text?
I built an MCP server almost on the first day MCP came out; and have built many.
I have been working on 'teams' with MCP since then.
Similarly with 'skills'.
I have been working with NLP and AI for decades.
I've worked (a little bit) with one of the 'Godfathers of AI'
And FYI (although I can't be certain obviously) odds are I have been coding since before you were born.
By your answers - don't seem to have demonstrated a grasp of the technology in question, and are glibly project as though you have some kind of insight.
The 'general service concept' you are describing can be quite useful, yes, but at that level of sophistication - especially with 'user management', and the inherent issues around that aka privileges, SSO, telemetry, whatever etc. - that would likely be best used as a common service, accessed via regular REST calls. The 'agent instructions' for that service would be trivially described in a 'skill'.
Alternatively, a 'skill' which merely instructs the Agent on how to use a local tool via CLI (which can be anything really), is very useful as well. Almost universally so.
After that 'skills' oriented towards REST services and local CLI tooling - MCP has little to no value.
The only scenario in which we continue to use MCPs, are for those published by 3rd parties, for which MCP provides a relatively plug-and-play solution. But even then, if MCP were to be deprecated, everyone would merely switch to rest/cli-facing skills, and nothing would be lost.
MCP has a bit of value due to it's incumbency, but it never existed, nobody would invent it today, it really doesn't solve any real problem, given how much better AI is at using standard tooling.
> I built an MCP server almost on the first day MCP came out
Build the Prompts implementation and try it. Built a user interface to compose prompts together (e.g. like old school server side includes) so you can inject a standard fragment into multiple MCP prompts. Add a telemetry layer and a dashboard to show which skills are being used and by whom.
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).
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.
I was watching something on YouTube last night and it really reminded me of informercials from the 80s/90s. Imagine trying to divine actual useful information about business, technology, and industry from infomercials..
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.
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.
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).
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.
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).
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.
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.
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.
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.
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.
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).
I never hit compaction, most of my sessions are 150-300k tokens long with the longest being around 700k. Using sub-agents means that they can't use that cache, have to re-read everything and now multiply this for every sub-agent you call and it just wastes money/tokens. I also don't like how intransparent sub-agents are, I can't follow what they are doing and I can't really steer them. Claude Code has the /agents view but it's clunky and awful to use.
GPT context window is way too low for me and my last experience with it (GPT 5.6 Sol) was so awful and I hit limits way too fast that I cancelled it (and at least got my money back).
I'm no longer using Pi since it got worse IMHO and Claude subs can only be used in Claude Code but I miss the /tree feature which is perfect for first letting the model read & cache the important bits of the codebase and then start your plan from there (as long as you stay in the Cache TTL). Claude Code has /rewind but it's not as good.
I admit I'm not a heavy user of subagents but isn't one of the standard use cases for subagents to run a single command, take the output, summarize it for the main agent and pass it up instead of polluting the context?
When cargo fails to build and creates a massive amount of compile errors, you're better off having this preprocess step.
I usually have my main agent write a wrapper command around things like that as it hits them. The wrapper only surfaces the important info, writes the full log to a file, and the agent gets some instructions on using sed and the like to navigate the output.
running local models, now with Qwen3.8-Flash-Next, they have 256k, but when they get up there their speed is just too slow. So i've taken https://github.com/Tarquinen/opencode-dynamic-context-prunin... and started improving it. It already worked well to get a lot of mileage out of just taking tool calls, code modifications, etc, and dumping them in favor of a summary.
But they'd still inevitably get to long in the tooth, and context poisoning meant they'd just eventually not be able to stay in the preferred context size, which for me is 64k-128k. So, I extended it with an eviction command and required a ratio. So instead of a summary of work, it now just places a waypoint. The waypoint basically means the context has a semi-coherent context but without all the baggage.
I'm on like day 3 of a single session with 3m tokens removed and still in the sweet spot. So it evicts to beneath the lower limit, compresses to the upper limit, then evicts again.
It's amazing how resilient it is if you give it a good plan. The work flow has basically been:
1. Write up an implementation document for some new set of features.
2. Rewrite the implementation as a TDD document
3. Set it to work.
The only thing I haven't figured out is it likes to stop when it hits the finish line of the subparts, but likely we're going to end up with the master of puppets monitoring these things and just set them to evaluating what they've done.
Yes-ish. The compressed summary sits atop the cache stack, so if we got to 96k, it'll take say 30k, compress to 10k, and that 66k+10k is the new stack, so 66k is still cached and retrievable.
So it is designed like a heap, where we're taking raw context off the heap, compressing it, and putting it back on the heap. So cache during compression is mostly unperturbed, since we're rarely digging all the way to the bottom of the stack, but that could happen.
Eviction though is cache busting; but again, I'm valuing the session's roadmap as the valuable product and context size slows computation size, so I have to bust the cache to sacrifice immediate re-processing for longer term compute speed up.
Because that's faster than getting to the end of the context (remember, every 1k adds to the compute time of the next 1k). So speed at 200k is much lower than at 100k. It's also local, so I'm only paying time+watts for the trade off. As far as I can tell, speed is not being lost since if I let the context grow, the kv cache doesn't help with the compute throughput.
So, yes, but it's "smart"; we're only busting it at the top of the context, so rebuilding it isn't from the bottom up, it's just at the top. Those summaries sink on the heap until you get to the eviction limit, and then, they're evicted, and we rebuild from some intermediate place in the heap.
The benefit of it all is I can have lots of projects, and keep a single session that tends to have the context necessary to avoid having to write AGENTS.md or other context bloats. Set large implementation goals and come back to them as needed, etc. I've had it running like this for awhile and it seems Qwen3.8-Flash-Next has no trouble understanding the rolling window.
> 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?
For that is it not better to have separate sessions for planning stuff and doing actual work? Pi is super flexible with session management, and a lot of that can be automated by its extension system.
> For that is it not better to have separate sessions for planning stuff and doing actual work?
Personally, seems like too much effort for something that would still need to (and fail to) have some sort of a link between the two, so I could go from the planning over to implementation and back easily. In reality, that'd get lost in the noise of dozens of sessions - I mostly just want the harness to help me do work and otherwise get out of my way, not make me dance around it. Ergo, the more context management it handles, the better!
Eh, I find managing sessions in Pi extremely easy. In fact, I customized how it mages session as part of my workflow, and how agents in different sessions communicate with one another.
It's part of why I really dislike to work in Claude Code, and found it too unwieldy. There I have to keep dancing around it to manage the context in a sensible way.
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).
Yep, I've used Pi in the past (see my other comment https://news.ycombinator.com/item?id=49908276) but I don't like the direction it went (selling out, forgetting their principles/throwing them out). And since Anthropic wants you to use Claude Code with their sub I just switched to CC again. I've only used Pi for a few months though when GitHub Copilot gave you 300 requests for like 10$.
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.
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.
Glad I'm not the only want to find it a bit janky/broken at times. They seem to constantly be pushing updates which is nice, but I treat it mostly as a black box.
Anecdotally, I find the auto compaction (or what I assume is happening when the context magically drops) to be hit or miss. I do like how easy it is to use my work cursor sub and business chat gpt at the same time. Then I use nearly free cursor models for dumb shit and Sol for real problems.
I used it for a while, and I thought it was quite hard to follow what was going on. And in the end it just went off the rails anyway, though that might have been a GPT-6 kind of thing.
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
Oh thank you for mentioning it has vim mode that's been my only gripe and I had no idea it had it. don't know if it's new or not never noticed the setting.
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 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
> 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.
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.
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.
There were OSS implementations of that but MCP came with anthropic backing and won.
Like VHS and Betamax, sometimes you just have to accept that marketing wins over engineering purity.
"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.
I think it's fair to say I know quite a bit about MCP (I built a company on it) so I'll take a crack at this. TLDR: MCP is an Oauth protocol now
MCP started out as this sudo browser replacement protocol for AI integrations. Similar to how a browser opens tabs and loads in JS, the idea was that MCP hosts load in MCPs and interact with them that way. Thus the original spec shipped as a stateful server client protocol with prompts, resources, a bunch of other stuff... and tools (the only thing anyone really ended up using). If you want to learn more about the original idea behind it, the creators did a pretty good podcast where they go through the conception and their design partnership with the Zed guys.
It became pretty clear early on that that way people wanted to use it was basically "I heard if I download this thing called an MCP the AI can manage my Jira tickets". so it's been almost 2 years now of rolling back all the opinions of the original protocol (statefulness, esoteric features) and bringing it closer to OpenAPI + JSONRPC + OAuth. Since the July spec release, you will start seeing alot more of this: https://redocly.com/docs/realm/content/api-docs/openapi-exte...
The biggest "win" of MCP is that the hype behind it let the Oauth guys swoop and use it to formalize a bunch of Oauth specs into a coherent story for API auth.
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.
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.
Because why should you have to load "here's how to update this skill!" information into the context window every time you use it? Would you expect the agent to go to that URL and look for more recent skill files every time you use it? Is this a real question?
Nothing says that agents can't read skills, interpret them and fetch stuff. Needing to agent to pass things off to powerful LLMs to interpret doesn't have to be done for everything.
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.
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.
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.
Your cli is slightly different than how a LLM uses it. We use 'export' and 'cd' to store state. LLMs dont do that generally.
There is an argument for and against having the model repeat this state.
I'm still on team CLI in that i think even designing an interface from the CLI perspective gets you a better domain interface compared to when you can 'cheat' with the MCP state.
But the thing MCP is just better at is credentials.
The thing that _was_ the dealbreaker between CLI and MCPs is that MCP's couldn't be composed. Maybe `codemode` fixed this; haven't tried enough to say 1 way or another.
My customers (non technical people) don’t know how to install a CLI. They’ve never opened a terminal.
But they can use an MCP. That’s the main difference.
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.
I'm still confused about what this codemode is. Models have been trained to chain bash and other typical unix tools well. They're so good at that to an uncanny level. Why do we want to not utilize this ability? Is it just a permission management issue in case you don't want the model to use shell directly?
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.
Bash (including `python3 <<EOF...`) is how you orchestrate CLI calls.
If all your tools are CLI calls, all you need is bash.
The one and only impedance mismatch is subagents; nobody's come up with a good way to turn the "subagent" tool into something you can access via the CLI. But I think fixing that would be a more productive direction than surrendering to the MCP insanity.
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.
My understanding is that code mode is supposed to be implemented by the harness, not the MCP provider. You chain multiple MCP providers as well as other harness provided tools inside the sandbox.
My timeline might be wrong (I remember a cloudflare article mentionning the "in MCP" case), but anyway yes there's tools to do it in the harness now and it's the better idea.
The value is that rather than an agent chaining together tool calls itself (which means each step sends the result back to the agent for it to analyse and work out what to do next), it writes a script for the harness to execute that chains together all the calls. The major benefits are:
* speed - much fewer hops back to the LLM
* fewer tokens - intermediate execution steps in the script don't leak into context, only the final result does.
* repeatability - if the LLM needs to repeat work, it can reuse a script it wrote last time.
If you have a harness that has access to a full shell and knows how to use bash or python, you'll often see it writing little scripts. For setups that don't (ie normal model API requests with tool calls), you can give it an lightweight secure execution environment like just-bash, or quickjs.
Agents just do this anyway, how is it a “mode”? I always see the agent writing scripts in a tmp dir to execute or even just inlining bash and python scripts.
We're in an HN submission about the least locked down by default harness. Pi is aimed at being extended, openclaw is a good example of this. You can buy a box of razor blades and put them in any number of razors.
Right the benefit of pi's customization is that it is exactly as locked down or not as you want it to be, in exactly the way you want it to be, and you can inspect it to verify.
What if I have an MCP Tool LookupZip(City) and want to chain it with a bash tool that prodcues a list of 100 cities. And then I want to filter again to the largest Zip code.
Not in my testing. A lot of the benefit comes from the tool definitions (from mcp) existing in the context window of the first turn. You could replicate this of course by describing your cli tool in the initial user/system prompt- but, mcp is already 'built' for this at the client (harness) level generally.
And I said that they do this in my last paragraph. But you need an execution environment for this, and you don’t get this automatically when just interacting with models via their API
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.
... and after using it for a while you might end up forgetting most of the extra stuff you thought you needed in the first place. That's what happened to me and I've never looked back and still am a happy Pi user (https://a.l3x.in/ai if you're curious)
I have already basically removed any extensions I had installed. There are still a couple, but I am going to remove those as well. Except maybe a web search one as that is something I use often. Going to remove all skills and anything else as well. I am a simple man when it comes to agent programming.
I'm a bit bumped when I first saw pi is moving from bash to codemode and also adding MCP, since I thought that loses the purity and simplicity of the "use bash for everything" philosophy. However, after reading more about it, I realized codemode is just a slightly enhanced version of bash: more complex, sure, but likely more robust, secure, and efficient. For those who, like me, don't get the point of this change, here is how I understand it.
The first tool execution runtime in harnesses are direct tool calls with JSON or XML, such as the Read and Edit tools. As an escape hatch, we have Bash tool that allows arbitrary code execution on the host running the agent. The downsides of using bash (on the host) as the main tool execution runtime are:
- Syntax and obvious errors only surface at runtime
- Unergonomic orchestration of parallel and background tasks
- Verbose command output cluttering context
- Dependent on the host environment, packages versions, etc.
- No security measures by default.
To me the last point is the biggest inherent weakness, usually mitigated by creating a dedicated unprivileged user or running bash in a sandbox.
Note that direct tool calling is kind of the polar opposite on these points: syntax errors are caught early, orchestration can be done with some wrapping tools, command output is controlled, and most importantly they are more sandboxed. On the flip side, they obviously have way less power, necessitating Bash tool in the first place.
Codemode is the middle ground between these two extremes. It actually can be derived simply by one idea: what if we replace Bash by another language that can be checked for obvious errors, i.e. type checked?
Everything else falls out from there:
- Any language would do, but I think TypeScript fits the balance between safety, speed, conciseness, and popularity in training data.
- If we use TypeScript, might as well run it in a sandbox as JS runtimes have been designed with this in mind for 20 years
- Orchestration comes for free from the JS runtime. It's not more powerful, just more ergonomic.
- Since the tools are controlled by the harness and not dependent on the host, cloud agent becomes easier.
- With this in place, MCP are not very different from a tool provided to this sandboxed runtime.
Overall I find the benefits compelling enough, but we'll see if the heavily-RLed models these days will use it effectively.
> And while we could have just wired up the metadata to enable better MCP extensions, we also think that MCP with Codemode solves quite a few of the issues that it traditionally had.
There's just something that bothers me about this. Normally if LLMs want to compose multiple operations, they have the perfect tool for this: bash, or whatever other OS shell is available. It's why I was always confused by Codemode-type constructs for direct chaining of tool calls; see also the way highly-RL'd modern models will fall back to sed or python for complex file edits.
It seems like Codemode is raised here as the perfect tool for chaining or composing MCPs, but isn't that backwards? LLMs are already given the perfect tool for that, and the problem is that MCPs aren't exposed to that tool.
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.
> 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.
It does, but a restricted user account mitigates the large majority of those issues. A sandbox mitigates even more.
The number of remaining exploits left is probably going to be the same as the number in the harness. More, in fact, as many of them have no human review anyway.
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.
Yeah, I'm probably over-indexing on local use cases due to my own preferences, prejudices, biases etc. For a coding agent like Pi it does seem reasonable to expect some kind of shell access though, unless some people are using it as a CLI chat client with MCP?
the trouble is that bash inherits the ambient authority of the shell. most of times, if you run MCP in a cli the agent will have access to the key for example (unless your agent do something exotic)
writing python or JavaScript for tool calls make it possible to have an actual permission system (rather than the one usually employed that consists in a regex matching the cli - trivially defeated if the agent has access to an interpreter for instance)
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.
Right, because MCP != web. In fact most of my exposure to MCP has been local tools. Also, for context, we're talking about a coding agent harness that runs on a local machine, and Codemode applies to all of its tools, not just MCP.
I don't use "AI" but I'm using "MCP" to remotely control software running on another computer on the local network by sending JSON-RPC with netcat
I send an Authorization header with a Bearer token but the procedure calls are sent in cleartext. Is this how "MCP" server is typically implemented (no encryption)
NB. I didn't write the aforementioned software implementing "MCP" server, that's someone else's work
> 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.
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.
Exactly! Swagger descriptions+GUI[1], HATEOAS[2], and JSONAPI[3] all coming together in jubilous harmony if MCP pulled its head out of the sand, but instead we get the XKCD#927[4] situation.
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.
As many others have commented: good, I too am an mcp hater.
However- in my testing, mcp is really quite fast, and its pretty much free at this point- with frontier models. Context rot is, from what ive tested, not as much of a concern now. I genuinely was not able to hillclimb skills/extensions to beat out the speed of mcp in some cases I've been testing.
This is somewhat similar to HuggingFace smolagents where the model writes code that calls tools, instead of emiting json to describe the tool call per turn. Here Codemode is one tool that the model calls when it needs to compose many tool calls, especially MCP ones. Is what i understand of this.
Just because they were gracious enough to change their mind and talk about it in public doesn't make it universally OK.
Second, the point of Pi as a bare-bones BUT extensible harness is just that - a bare-bones harness, that can get anything one wants. Make that "thing" easy to get. Besides, bloat is bloat and every bloat is someone's must-have and vice versa.
I had also read somewhere that they have launched (already? not sure) their hosted model infra or something like OpenRouter (not sure). Nothing wrong with running a paying business along with a FOSS project but that's also there.
The shimmering effect on the web page... it does not add to the experience. It subtracts. It is very distracting. I want to read what you wrote but keep getting distracted with things moving on the screen.
The advantage I see for MCP over CLIs or APIs, is that once you release the CLI/API and people start coding scripts against it, your interface is set it stone, you're never allowed to change it again, or you break everyone's scripts.
With an MCP, agents are very tolerant of changes, since each usage is fresh with no prior knowledge, so nothing to break. This allows you to experiment and iterate on the MCP, see how people use it and what gaps you still need to cover. Once it stabilizes, you can lock it down into and API/CLI interface.
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.
I'm going to pick on the example. Love both pi and use mcp, so it's a welcome change. However, I don't want to live in the world where anger is the prioritisation criteria for fixing bugs, and civil conversation about severe issues goes ignored.
criteria: {
none: "Neutral, factual, or friendly, even about a serious bug",
mild: "Explicit annoyance, impatience, or disappointment",
high: "Clearly angry, exasperated, sarcastic, or fed up",
},
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.
Good. I too I'm not a fan of MCPs, but these days I do find them useful. In Claude Code I connected to my company's MCP which made Claude Code infinitely more useful for everyday work stuff
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...
The crazy thing with the anti-MCP wave to me could be boiled down to "you don't like it? Then don't use it."
It's like people hate it so much they forget how easy it is to spin one of these up; it's not like I spent weeks and weeks working on this.
I spun up an MCP server for a personal finance app I've been working on. OAuth with personal tokens and all the tools I added- guess how long it took me? Like 2 hours maybe. Some people find it useful, including me, and some don't. That's okay!
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.
I wish the MCP protocol supported push notifications from the app to the model. That'd make for a much nicer integration, with less overhead for this kind of interaction.
Ok! I trust that you and the maintainer will steward the project properly. It's just that I really like Pi as is and am a natural worrier. I'm also not sold on Jev(-likes), so that reasoning rung a bit hollow to me.
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.)
Swival.dev has a tool to run Python code, and it can expose the MCP tools as Python functions.
This saves a couple prompts and tokens, but only in very specific cases, only with MCP servers that don't already support code mode, and only with large models.
In practice, I've not found that to make a real difference.
Plus, it's likely that more and more MCP servers are going to use code mode natively anyway.
> That means tools should return structured data and tools should be discoverable by their documentation and description.
Treating MCP as a part of OpenAPI rather than a tool connector is a direction in which we're heading. It is important for the users to have the flexibility of deciding the model, work to be done and the tool call in one prompt. The framework sets up the configuration and gets the output.
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.
I am in the process of setting up a demo local-hosted-model using either vLLM or SGLang for my not-in-software-business enterprise. What harness would you recommend? I mean what are the top 5 open source ones. Trying to avoid unsustainable ( from the business model of agent developers ) harness. Personally I have used only OpenCode / Codex / ClaudeCode / Antigravity.
the conversation seems to dwell on things you could substitute Bash for but the real need stems from completely opaque systems that nothing can reach but which are now getting MCP support. This is where being left out of having MCP support will hurt. I'm still quite happy to let all the harnesses compose bash commands to their hearts content (inside their sandboxes ...)
This is a potentially polarizing (but very welcome imo) change to pi. I'm such a huge fan of the pi SDK, and just yesterday I was trying to wire up the pi mcp extension to be used in a project and sonnet told me about the ongoing work in the 0.99.x tags. Didn't realize the next day it would be merged! Fantastic news.
My biggest frustration with MCP at the moment is that it has no built-in way of uploading and downloading files. Every argument has to go through the context.
Sure you can use curl along with it - but many MCP friendly harnesses don't have access to a tool like that. Wish they had added this before moving on to stuff like MCP apps.
It is bizarre that Marco said MCP is hard to compose. It's like he doesn't understand how composability works.
Unix programs are said to be composable, in that you can combine them in different ways to get more complex and useful functionality. But the applications themselves are not composeable. They just take input, perform calculation, and return output. Each app has unique input and output, and none know about other apps. So how can they possibly work together?
Bash acts like a programming language, allowing you to write a new program on the fly. It is very lightweight, but gives enough functionality to do two things: 1) call arbitrary programs, 2) connect their inputs and outputs, 3) make decisions about how to do this to result in a novel solution. It uses Unix pipes to make writing the program easier, but actually it could work fine without pipes, reading/writing program input/output with files.
The important thing is bash is a "glue" program that ties together the other programs. Bash is what makes those programs composeable. That, and the Unix API (execve(), open(), read(), write(), close()) that allows making the call, passing input, reading output, in one standard way for all programs.
MCP is both the application to call, and the Unix API to call them. Your agent harness is bash. Codemode is certainly a neat/more efficient way to write the code, but it's not necessary. What's necessary is getting a very large library of programs, like Unix programs (find, cat, grep, sed, awk, tr, cut, sort, tail, head, etc) that each have powerful functionality. The more programs you have, the more your bash script can do to chain them together and get more powerful results.
LLMs only use Bash because they didn't yet have MCP and a large library of MCP programs. Bash is a stopgap solution. The future is MCP (or whatever replaxes it).
Perhaps I'm not understanding Pi's architecture correctly, but (unless you want to use popular MCP servers) what is the advantage of MCP vs. Pi's tools? Ins't calling a Pi tool in an extension exactly the same as an MCP tool, in the end?
not to troll, but the CLI vs. MCP feels very much like the SOAP vs. REST discussion. The "CLI works for me, so therefore MCP is sh#t"
AI/SI is having crazy impact on the entire world, and we are left with just 2 ways of doing things ? THAT is crazy to me. With all this creativity and intelligence we are down to two standards, pretty soon Thomas Watson is correct, we only have 5 computers in the world.
That being said, MCP has been truly magical for us, I just wish that the LLM labs would support their connector systems better. Too many "refresh tools" or "sign in again" ..
I thought the whole point of pi was to be minimal. Why are they adding features a user could create themselves? This just seems like the treadmill of endless bloat overwriting the projects principals.
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.
Hmm what is this JavaScript sandbox? container, separate process, same Node process? Also does it have access to the MCP tokens? The harness credentials?
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
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.
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".
The core idea of Codemode that I understood is - The script doesn't actually write any code itself; rather, it acts as a workflow automation and program management tool. It pulls data from an issue tracker, delegates the analysis to a model, and synthesizes the results to help manage Pi's development priorities.
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 :)
Yeah, since pi is my first agent harness I barely understand what MCP is beyond an API standard. When the essay started talking about codemode without any introduction I was having trouble following it.
Honestly, the provided argument for it is rather weak. They are basically adding a way of running scripts that are contained within harness to execute harness's own tools (that's the Codemode). A coding agent can already compose any arbitrary logic by invoking shell scripts (or python scripts, or node scripts), etc - so this is just entirely unnecessary in the core, from my perspective.
If you feel that Pi has been drifting away from its original vision, try hax (https://usehax.dev/) - you might like 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.
Over the last week or so on Twitter, I've seen a lot of people talking about how various ways of using MCP don't compose, but nobody seems to be clarifying what that means with a concrete fashion; which leads me to try and read between the lines.
In this very post:
> While a lot of things have improved about MCP, quite a few have not. The biggest issue with MCP continues to be that it’s hard to compose. Even with codemode, which is just a neat little sandbox to allow composing of tool calls, MCP doesn’t fully deliver on this. But that at this point is less the problem of MCP but the MCP servers out there and different approaches of harnesses to work with them.
Can we get a bit more clarity on this? With codemode, what's the gap? I've also been investigating the search+execute MCP server pattern evangelised by Cloudflare (it uses codemode inside the MCP server to bypass the need to expose a large number of individual tools), but i've seen people say that doesn't compose well either.
Can we talk about the point the article makes that the MCP servers should implement JSON apis instead of text APIs? It makes sense if your harness supports code mode, but an embedded code sandbox is a pretty big piece of machinery and not everyone implements it. It seems like a massive change to the way one should build an MCP. Also why again are we using MCPs instead of OpenAPI when it's now supposed to be just stateless JSON APIs?
This just reads like Pi is becoming Armins and Marios opinions on what a good harness is instead of letting us build our own with the features we want and need.
There were already tons of third party MCP extensions that were every bit as good as this half baked built in.
Already lots of code mode extensions too, which is also opinionated.
Sad to see Pi to go from being:
"This harness is yours"
As someone who maintains own coding harness, arguably more capable and powerful than Pi, I assure you the level of integration required to have something working really well nowadays goes against "this harness is yours" philosophy. "Codemode" completely changes the inter-workings of the harness, which spills all over everything else. And codemode is likely the inevitable future, as it's just much more efficient and powerful way for agents to do stuff. I'm planning to completely abandon non-codemode and make codemode the only "mode" in my harness as soon as open source models that I can run on my GPU can handle it well. I'm holding back as I don't want to deal with the complexity of having to support both.
> This just reads like Pi is becoming Armins and Marios opinions on what a good harness is instead of letting us build our own with the features we want and need.
Realistically it was always their harness. If you want "your own harness" you can always click the Fork button.
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.
Good to hear. We have our MCP Running inside Larkspur, an Oil and Gas Operater in OKC. It's been six months with c-suite use. Everything runs local models, the DBs (all three) Postgres w/ Tiger and Neo4j. The local models are for processing messy energy data. And the oil bros access the mcp currently from Claude.
Spec wise: Ampere 128C, 256gb, 4xa4000,& 7800x3d, 96gb, Blackwell 24gb, 4070s. Nvidia fiber and mirkotik. Working on RDMA (but isn't really needed yet, but we have it)
OS - Tumbleweed ARM headless, CachyOS x86 hyprland. It's been easier staying on the edge of the kernel with less abstractions.
I feel like a broken record, but I still don't get the point of MCP. Is this really just another attempt at undoing the mistake of abandoning actual REST APIs?
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...
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.
REST APIs built with HATEOAS are far superior to MCP. It allows AI to perform incremental, intelligent discovery of your APIs. MCP fills up the context with tons of needless tools upfront. HATEOAS can also communicate state, informing what tools are available, what are disabled and why, in a way that can change dynamically.
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:
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
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.
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.
> MCP is a tool more for security than anything else. +1 to this; API keys mean: a) Your agents are overprivileged by default b) Your API key is more likely to get into logs and pre-training / leaked as FrinkleFrankie mentioned c) You can't manage it centrally with granular tool policies in Enterprises. (e.g. "you're not allowed to read slack channel for #finances")
Also, you can always collapse MCP to CLI, so MCP as auth/security middleware makes a lot of sense.
PoC of MCP -> CLI: https://github.com/edison-watch/cli
> MCP is a tool more for security than anything else.
The agent can get to the resource through the MCP server or using API key. I personally do not see the benefit MCP is providing here. Sure you can reduce the exposed surface at MCP layer, but I do that at the API layer. I don't need to add another layer here.
I can kinda understand if you do not have control of the API layer and/or you have to expose the API layer to the public Internet as well. Most of the time that is not the case for me.
The idea is that with an MCP, the agent doesn’t have access to any credentials. It can’t leak an API key.
There are many ways to do this without using mcp, for example one of the many proxy servers that inject the token into requests. I use a custom solution that redacts all secrets to agent transcripts before the agent sees them in a hook.
I find it way better to be able to confidently tell agents to use CLIs than worrying about partially implemented mcps that need configuration and are often yolo’d with npx @latest anyway
Sooo, how does the agent authenticate with the MCP server?
My own approach is to put the API key in the MCP server, apply principle of least privilege there, and firewall access to MCP with agents being on same private network with Tailscale.
Not only giving an API key to an agent can leak to the model because of harness issues or too broad reading rights, but also most providers don't give the ability to apply principle of least privilege to an API key.
I don't want to give an agent full R/W access to any of my services/accounts.
The agent doesn't, the harness does. It's separate from a normal conversation / agent runtime environment. How do you suspect auth keys can leak from an MCP that's been added to chatgpt.com?
With a different key, obviously. This lets you keep the MCP server firewalled to your local network only while still allowing home assistant itself to access the internet
You give it a key of course! And if that doesn’t fit your security model and threat vectors, simply give the key to another MCP.
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
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).
So MCP is useful until cheap models get better?
It still takes decent hardware to run local LLMs that are at all useful. What would be really cool is if we could get useful LLMs on hardware cheap enough to go into “things”.
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.
For Home Assistant, the MCP can enable the LLM to make changes without using up excessive tokens.
For example, the only way to make a change to an HA automation via the API is to POST a whole new copy of the YAML, even if changing one things. The skill and HA MCP I use allows the LLM to use tools which make more precise changes without excessive context usage.
Certainly still works either way though. And of course your LLM instance could just roll its own tools to do the exact same thing.
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.
Developing for HA with Claude has been great. Not only can it make all of those yaml changes based on natural language goals, but it's so easy now to create a custom dashboard or configure various apps. I was struggling with both the ChoreOps docs and its fairly cumbersome interface until I pointed Claude at it and told it what I was trying to do.
> No MCP needed
Definitely helps that the home assistant api is documented online most likely in the training data.
One of the nice things about MCP is that the tools have descriptions that provide guidance to the LLM. You can provide documentation in other formats like OpenAPI but its nice that the documentation is so closely coupled with MCP servers.
> One of the nice things about MCP is that the tools have descriptions that provide guidance to the LLM.
It is more of a curse than a blessing. MCP pollutes agent context even when you are not using it. Use a manually invoked skill instead if you don't want to be wasting tokens on every turn and bloating up agent context making it dumber in the process.
> MCP pollutes agent context even when you are not using it
MCP in some harnesses bloats context. MCP in some harnesses doesn't bloat context.
How are you interacting with Claude for this?
Same question… but I would assume he’s running Claude Code on a PC that is on the same network.
I just run claude's cli tool?
Thanks. It sounded like something more since you asked it to look in a few minutes time. I’m not familiar with the cli tool (I just use vscode) but I assumed it was openclaw you were using or something.
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!
Hey thank you! Always nice to hear when my work helps others ^_^
Love Lunar. Love it.
Had no idea that MusicDecoy existed! I just had music app pop up by accident too. Thank you for pointing those apps out
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?
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:
Then the MCP can use elicitation and say: 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
You answered "Why use MCP with your agent instead of using CLI manually?" but the more interesting question is "Why build an MCP when you could already point your agent to the CLI?". The user experience of "the agent will present those as nice choice menus I can decide schematically on" will probably be the same since agents are very adept at using cli tools and gathering required/optional arguments, examples, and warnings/errors to present you with useful choices on how to proceed.
The most important reason is that I can keep the CLI output and help for humans, while the MCP can be crammed with information for agents.
Plus I can add some complex commands like in the rcmd Stages [1] case where the agent can create a 4 monitor layout with apps and windows placed where you want, with every window opening the document/folder/project/URL you want and running the terminal commands you need. Sure you can do that with the CLI, but it's hard enough to get right because of shell quoting issues, that even an agent can get it wrong.
For simple tasks though, sure, the CLI is just enough and the agent can use it without needing to install yet another MCP. You'll know when you need it.
[1] https://lowtechguys.com/rcmd
---
EDIT: I just remembered, you can even hook the Claude/Codex/Gemini desktop app to the MCP, while you can't get it to use the CLI. so there's that for users that still don't feel comfortable at a terminal, which is a number higher than you might estimate.
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?
How does my browser authenticate to a website/service? Can't agents have session storage to store such information?
agents dont always have access to a terminal. why is this so difficult to imagine
Yes and harnesses can't provide any interface for an agent to send REST requests for example.
> 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.
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.
I'm not intending to denigrate your tool. I'm just commenting on the "look at how we go full circle" aspect.
I will point out that the shell script way uses less resources than an LLM making a tool call. But I understand that these scenarios are not necessarily meant for the same user.
No offense taken, I can see the irony myself :)
Oh for sure, I would prefer to have the automations as invisible things running at the system level, doing exactly what I want and nothing else, not wasting resources on UIs and event watchers I might not need. I would get rid of my own apps if that was easy to do.
But it seems we need to waste some resources to get some usability in return.
This is how engineers end up justifying why my doorbell needs to contact the cloud to confirm it should run when someone is at my door.
I used to do that using the macOS builtin Folder Actions. People forget these exist. Pure GUI.
I had no idea this was a thing: https://developer.apple.com/library/archive/documentation/Ap...
Definitely saving it for further use, I sometimes need to have small invisible watchers and I don't want a full fledged app or shell scripts for that.
That guide seems like an extremely roundabout way of doing things. Just open Automator and use the GUI.
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?
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.
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.
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 :-)
Thank you! Yes, macOS 27 continues to be a pain with the all new rewritten window manager.
Still working on finding all the edge cases, so sorry if you still encounter problems there. I've been using it since June and still find problems in input handling.
Like there's this thing, where if an app has Accessibility Permissions and listens to key events (like rcmd does) and then you revoke that permission while the app is running, then your whole system will stop responding to keys and clicks. Until you kill the app in question, but how are you going to do that without a keyboard?
All apps have this problem, even established ones like BTT, because it's a recently introduced macOS behavior in how the internals of CGEventTap work.
Yeah, I thought so -- I imagine quite a lot has changed behind the scenes. It does seem much better than Tahoe, though.
Yikes, that accessibility bug is bad LOL. It seems a bit like Linux in that way: certain bugs hang around for years. I always found that with Linux, you could either use an LTS and stick with the same bugs for years, or try your luck with a rolling release and trade them for new ones. Anyway...
I've just started leaning more heavily on the window switcher (moved it to Lcmd) and it's made me so much faster. Had rcmd for ages but never changed it to that; it solves the problem of "where the hell did I put that window?!" when I try to organize stuff into different spaces. It's a better candidate for Lcmd too IMO: I very rarely wonder where I put a random window of an app (and after all, if it's already open I usually want to choose a window), but I'm always switching between certain windows of one app, like Safari. Swiping back and forth between desktops was a nightmare!
Oh it's MacOS.
I haven't even considered using MCP for locally-running apps! I mean I used to, but they almost always got associated with cloud service access and integrations nowadays, and most local stuff is trivially handled with agent skills.
Thanks for the tips. TIL about BTT having MCP support. Crank looks very promising too, since it looks like a more effective Shortcuts and Hazel replacement
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.
Yep like a self-documenting RPC since you don't have to read docs first to use it. You just ask.
> 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?
Not really. macOS may wait for idle time, may prioritize internal disk and the backup will go extremely slow on an HDD, there's no notification whatsoever.
It's a very specific thing for me really, I connect the HDD specifically for doing backups as fast as possible then I want to disconnect and store it back so I can keep using my laptop. I don't have a desk anymore where I can keep these things connected all the time.
In the before times, you could use Applescript to expose those things. Is MCP preferable to (LLM generated) Applescript?
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.
I think the issue is that any mcp could be a cli and llms are very good and using bash.
Of course MCP has its use case like if you want auth, or session based actions.
> any mcp could be a cli
NO IT CANT!!! why dont you understand that not all agents have access to a terminal!
This isn't restricted to agents. It's generally annoying when any service I may want to use programmatically is exposed through a CLI but not an API. Sure, I can call a CLI from most programming languages, but I/O beyond arguments and return values is at best awkward, and especially on non-UNIX OSes performance can suffer due to process creation overhead for every command.
Recent example: The AWS CLI has a convenient "s3 sync" command that does a one-way directory sync, only downloadiong new files if existing files with matching sizes and timestamps don't exist, but the closest thing the .NET SDK has unconditionally overwrites destination files.
Another example: one of the nicest things about C# is how the compiler exposes itself as extensive library functionality, so, not only can I compile and run code at runtime, I can generate this code from programmatically created ASTs instead of text, parse expressions into ASTs, etc.
Yes - Or a working directory that’s under version control where they can write arbitrary memory files and maintain working state across contexts.
These are things devs often take for granted as being part of ‘how chat agents operate’ but they are specific to how claude code/opencode/pi/codex operate.
Giving agents a Unix computer account they can play with is definitely a powerful tool that makes them capable of doing a lot more (see: meta muse, OpenAI dots), in much the same way that giving a human a computer they are trained to use makes them way more capable… but it’s surely not the only way we can run these things.
you probably shouldn't complain about people "screeching" when this is the tone you respond to calm, measured discussion with.
im only bothered by people screeching about things that are wrong.
Some coders, those that equate being a developer with UNIX, mostly.
They pay tons of money for hardware, only to use it the same way I was using those DG/UX terminals at the university.
Naturally there are no coders in other operating systems as well.
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.
> These days if you're arguing from a position you took even a week ago, you already might be out of sync.
"Might be out of sync" is a unique spelling of "crucified online". :-D
> "... 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?
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]:
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
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.
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.
Do content creators have a lot of say over what advertising gets spliced in to their creation?
Spliced in likely refers to ads they splice into their own videos, which they control completely. The platform ads are separate from the video and the creators do not have control over what is shown.
Yes. I'm talking about the sponsored segment where the creator reads ad copy of whoever's sponsoring that episode that day.
> 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.
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.
That feels like it should be the obvious use case for something like a `?q` query param, formalized or not, but it seems like nobody working on the spec and libraries ever considered query params as a use case, since they're still broken in the Typescript library.
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.
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.
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.
Prompts is possibly one of the most useful enterprise features for MCP.
Dynamically target sets of `/` commands to teams in an enterprise by their identity+claims? Legal team gets a set of skills? Finance team gets another just by their roles? Always up-to-date delivery of what are effectively remotely served skills? Telemetry on who is using which skill? Server-side rendering of skills so that common skills can be composed? With placeholders replaced by user- or team-custom options? Easy to ship new skills as long as the user has connected the MCP? Easy to retire skillsets that are outdated across the entire enterprise?
MCP Prompts is one of the most powerful capabilities in the spec for enterprises.
OpenAI team: if you are angling for enterprise, you need to get this solved. Your FDEs are going to make a killing getting this set up for enterprises. Build an enterprise skills management platform around this that's integrated to their directory. Streamlined setup of the MCP via MDM. Telemetry on enterprise wide usage of curated skills across the enterprise, by team, by individual. You need this.
An MCP server should be self-describing, so I use prompts to deliver skills or skill-like context.
[dead]
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?
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.
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!
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.
You could serve MCP over HTTP 8+ months ago and deal with none of that? Lots of people did? Especially internally within Enterprise
With stateless MCP, the MCP rube goldberg everyone was calling dead in March is effectively dead though.
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).
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.
>It was fairly obvious why MCP would be needed once AI engineering and uptake moved beyond the solo developer and single harness stack
This was already happening back in March. Lesser technical users were looking to hook up web LLMs to various SaaS apps so they could pull data in.
It was quite surprising people were forming such strong opinions when there were very clear and objective differences in use case.
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.
If that works for you great but I am where I am in my career by helping everyone I can around me. Making my team and the company better pays dividends and you stand out from people that only work for themselves.
This is now an outdated mentality in the AI era, where people will quickly use whatever you put out to make themselves better but little to no benefit will return to you beyond maybe a fuzzy feeling. People already feel proud just prompting huge projects out and claiming it as their own work. You will not be recognized.
“When a favor becomes too large to repay, the gratitude turns to resentment.”
It sounds like you and I are having very different experiences in the AI era.
Good luck
Yep, number of new MCP servers this month is on track to be the highest it has ever been: https://bloomberry.com/data/mcp/
"MCP" is the new "API" (MCP over streaming HTTP, after all, is just an API with a structured payload wrapper and defined interactions).
It is only going to continue to proliferate in usage and adoption.
With the v2 spec, MCP became a lot closer to APIs by becoming stateless. And there is now a push to use HTTP verbs more extensively to improve caching even better in v3. MCP is converging into APIs but wit great auth and auditing
... Are both of you using "API" as a synonym for "REST"?
This is the worst moment in time to talk about "REST".
Do you mean the Roy Fielding "REST" or the HTTP API "REST"?
Calling the latter "REST" is wrong. It's like calling a hermit crab a snail.
Edit: I forgot to mention, the former is gaining relevance as the elusive evolvable clients are now a thing.
I'm not trying to be a dick, but it's pretty hilarious that we made these two posts at the exact same time [0]. I totally get what you're saying, but I don't understand the motivation behind it. A properly designed HTTP API is what Roy Fielding was discussing in his dissertation, but he was obviously talking about HTML pages full of hyperlinks. At the end of the day, does it really matter much if the definition is only 80% correct if the majority of the population understands the basic gist of the conversation?
[0] https://news.ycombinator.com/item?id=49908582
Unironically, Roy Fielding had a point.
If you can build the ultimate evolvable client, then you can collapse all UI into a single client.
Basically Roy Fielding told us to build an API that can only be operated by a human like intelligence, nobody could implement that because such an intelligence did not exist (hence the switch to imperfect HTTP APIs), and now that LLMs are a thing, said human like intelligence exists. This means Roy Fielding wasn't wrong, he was 25 years too early and ironically people should be building real REST APIs in the pendantic academic sense from today on and not the "pragmatic" HTTP API.
It's annoying, but that's been pretty common for the last decade. It's just like how everyone uses "REST" to mean "JSON RPC". In the end, we all basically know what the other ones are talking about, so it's pretty pointless to get bogged down in semantics.
It's common when talking about web services, where the kind of API is generally unambiguous. The problem here is we're discussing different kinds of APIs (shell commands, MCP, REST / JSON RPC) and so calling one of those kinds of APIs "API" is very confusing.
"REST" is one of many way to implement APIs.
Exactly. It's confusing to talk about MCP vs API when "API" describes the whole class of possible values, of which "MCP" is one of them.
MCP is not strictly an API; it's a protocol shape (thus the "P" for Protocol) for delivering an API.
The API surface exists in the MCP payload.
Whereas application teams previously would have focused on APIs for external access, they now have to focus on MCP entry points (often to those same APIs, but with a different shape).
Seems like in this context API means HTTP API lol
Yeah I always just thought of MCP as best for the average user and then CLI as one of the tools of choice for power users. Never had to be one or the other, I use both daily
Decent point - but - the same could be said for skills. You can have enterprise skills that don't require use of MCP.
Sure, but now you have a distribution and telemetry challenge.
It's hard to customize those skills. How can I tweak my skill a bit to match my workflow? With MCP Prompts over HTTP, this is easy: you can server render the text with my personalization specific to me.
It's hard to tell which skills are being used. With MCP over HTTP, each Prompt call, each Tool call is an HTTP request and you get telemetry on activation. You can server compose the response and ask the agent requesting it to return a score on how useful it is, too. Or ask it to call another endpoint to rate the skill.
Enterprise skills delivered to the disk you cannot do this. If a skill is flawed or outdated, you cannot revoke the skill at an enterprise level. MCP Prompts: it's easy to do.
"It's hard to customize those skills."
I don't see what you mean?
An MCP and a skill are just two ways of distributing capabilities.
For telemetry ... well the agent should still have it's http logs? Also, I'm not sure MCP Telemetry is the primary point of concern for most things? Like thats a skill debugging thing?
I sync a skill in a file with my repo. I can't edit that skill. I can't combine that skill. I can't customize the skill without affecting the other folks on my team or I have to put that in a gitignore.
A user getting a skill via a plugin and wants to keep it in sync with the source has the same problem. Next update/sync wipes out their changes.
Skills delivered via file system download/git are like Deck.final.v2.real-final.2026-10-01.published.pptx. Skills delivered via MCP over HTTP are "live" and dynamic.
An HTTP MCP server is just a server returning text. The MCP prompt can be a template. It can have placeholders. I can build a UI to allow the user who logs in to customize the prompt/skill by filling in the placeholders. If they don't put a value for the placeholder, I render it to the HTTP response stream with defaults. I can dynamically render the skill, tailored for each user like I can render JSON or HTML for each logged in user. MCP Prompts just returns text. I can render any text I want on a server. I can return a different, more suitable skill text for the user. I can personalize it based on their workflow. The base template is always up to date for every user, etc.
Try it. Go write an MCP HTTP endpoint delivering a prompt. Now make that dynamic and serve different text back based on different users. Now your users are in different teams. Render variants of the same prompt/skill by team. It's powerful.
Use your imagination.
?
You can trivially build a skill that uses a set of customizable, per user values.
You can also build a (non-MCP) 'gateway' to do those things you just described, and not have it bound or limited by 'MCP' at all.
We already do both things.
I don't see what MCP has to do with any of this; it's a standard, that has very narrow value.
You can't do it in a team environment. You are missing the key point. Teams.
Please, go build the simplest MCP server you can that serves a prompt. Now make it dynamic by user. Now let you users share a common template. Now look at the telemetry you see on the server when someone uses the skill. Now add a flag to turn some on and off. Now imagine you are in an enterprise and you want to centrally manage all skills across the teams mapping some skills to some teams, revoke skills, force update skills, compose skills by user automatically using rules.
Please. Just try it. You can literally vibe code this in a few minutes and connect the dots.
A file on disk is static. An HTTP request-response for text is not. Build just one prompt endpoint. Now imagine dynamically injecting text into the skill as well because it's just HTTP.
You are arguing why we need web servers when we can just email text files to each other, save them on disk, and open them in Notepad. Do you not understand the power of using an HTTP server for sending text?
I built an MCP server almost on the first day MCP came out; and have built many.
I have been working on 'teams' with MCP since then.
Similarly with 'skills'.
I have been working with NLP and AI for decades.
I've worked (a little bit) with one of the 'Godfathers of AI'
And FYI (although I can't be certain obviously) odds are I have been coding since before you were born.
By your answers - don't seem to have demonstrated a grasp of the technology in question, and are glibly project as though you have some kind of insight.
The 'general service concept' you are describing can be quite useful, yes, but at that level of sophistication - especially with 'user management', and the inherent issues around that aka privileges, SSO, telemetry, whatever etc. - that would likely be best used as a common service, accessed via regular REST calls. The 'agent instructions' for that service would be trivially described in a 'skill'.
Alternatively, a 'skill' which merely instructs the Agent on how to use a local tool via CLI (which can be anything really), is very useful as well. Almost universally so.
After that 'skills' oriented towards REST services and local CLI tooling - MCP has little to no value.
The only scenario in which we continue to use MCPs, are for those published by 3rd parties, for which MCP provides a relatively plug-and-play solution. But even then, if MCP were to be deprecated, everyone would merely switch to rest/cli-facing skills, and nothing would be lost.
MCP has a bit of value due to it's incumbency, but it never existed, nobody would invent it today, it really doesn't solve any real problem, given how much better AI is at using standard tooling.
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).
Either way still seems like the issue is people giving influencers too much power over them.
> 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.
I was watching something on YouTube last night and it really reminded me of informercials from the 80s/90s. Imagine trying to divine actual useful information about business, technology, and industry from infomercials..
> 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 .
I agree with your sentiment to degrees, but he is indeed prominent in the tech industry with many folks that will follow his lead.
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.
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
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).
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
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).
The "general adoption agent" for Earendil is their other product Lefos, that is based on Pi and uses email as the interface.
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.
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
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.
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?
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.
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.
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:
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/
I never hit compaction, most of my sessions are 150-300k tokens long with the longest being around 700k. Using sub-agents means that they can't use that cache, have to re-read everything and now multiply this for every sub-agent you call and it just wastes money/tokens. I also don't like how intransparent sub-agents are, I can't follow what they are doing and I can't really steer them. Claude Code has the /agents view but it's clunky and awful to use.
GPT context window is way too low for me and my last experience with it (GPT 5.6 Sol) was so awful and I hit limits way too fast that I cancelled it (and at least got my money back).
I'm no longer using Pi since it got worse IMHO and Claude subs can only be used in Claude Code but I miss the /tree feature which is perfect for first letting the model read & cache the important bits of the codebase and then start your plan from there (as long as you stay in the Cache TTL). Claude Code has /rewind but it's not as good.
I'm only using the 20$ plans.
I admit I'm not a heavy user of subagents but isn't one of the standard use cases for subagents to run a single command, take the output, summarize it for the main agent and pass it up instead of polluting the context?
When cargo fails to build and creates a massive amount of compile errors, you're better off having this preprocess step.
I also don't like subagents.
I usually have my main agent write a wrapper command around things like that as it hits them. The wrapper only surfaces the important info, writes the full log to a file, and the agent gets some instructions on using sed and the like to navigate the output.
It seems to work reasonably well.
>When cargo fails to build and creates a massive amount of compile errors, you're better off having this preprocess step.
Claude already greps and tails every output by itself, a sub-agent would do the same.
> Using sub-agents means that they can't use that cache
They can, when they're forked off the main session instead of spawned from scratch.
running local models, now with Qwen3.8-Flash-Next, they have 256k, but when they get up there their speed is just too slow. So i've taken https://github.com/Tarquinen/opencode-dynamic-context-prunin... and started improving it. It already worked well to get a lot of mileage out of just taking tool calls, code modifications, etc, and dumping them in favor of a summary.
But they'd still inevitably get to long in the tooth, and context poisoning meant they'd just eventually not be able to stay in the preferred context size, which for me is 64k-128k. So, I extended it with an eviction command and required a ratio. So instead of a summary of work, it now just places a waypoint. The waypoint basically means the context has a semi-coherent context but without all the baggage.
I'm on like day 3 of a single session with 3m tokens removed and still in the sweet spot. So it evicts to beneath the lower limit, compresses to the upper limit, then evicts again.
It's amazing how resilient it is if you give it a good plan. The work flow has basically been:
1. Write up an implementation document for some new set of features.
2. Rewrite the implementation as a TDD document
3. Set it to work.
The only thing I haven't figured out is it likes to stop when it hits the finish line of the subparts, but likely we're going to end up with the master of puppets monitoring these things and just set them to evaluating what they've done.
> taking tool calls, code modifications, etc, and dumping them in favor of a summary
Doesn't that destroy the cache? I find that caching significantly sped up my Qwen, especially on said larger contexts.
Yes-ish. The compressed summary sits atop the cache stack, so if we got to 96k, it'll take say 30k, compress to 10k, and that 66k+10k is the new stack, so 66k is still cached and retrievable.
So it is designed like a heap, where we're taking raw context off the heap, compressing it, and putting it back on the heap. So cache during compression is mostly unperturbed, since we're rarely digging all the way to the bottom of the stack, but that could happen.
Eviction though is cache busting; but again, I'm valuing the session's roadmap as the valuable product and context size slows computation size, so I have to bust the cache to sacrifice immediate re-processing for longer term compute speed up.
Because that's faster than getting to the end of the context (remember, every 1k adds to the compute time of the next 1k). So speed at 200k is much lower than at 100k. It's also local, so I'm only paying time+watts for the trade off. As far as I can tell, speed is not being lost since if I let the context grow, the kv cache doesn't help with the compute throughput.
So, yes, but it's "smart"; we're only busting it at the top of the context, so rebuilding it isn't from the bottom up, it's just at the top. Those summaries sink on the heap until you get to the eviction limit, and then, they're evicted, and we rebuild from some intermediate place in the heap.
The benefit of it all is I can have lots of projects, and keep a single session that tends to have the context necessary to avoid having to write AGENTS.md or other context bloats. Set large implementation goals and come back to them as needed, etc. I've had it running like this for awhile and it seems Qwen3.8-Flash-Next has no trouble understanding the rolling window.
> 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?
For that is it not better to have separate sessions for planning stuff and doing actual work? Pi is super flexible with session management, and a lot of that can be automated by its extension system.
> For that is it not better to have separate sessions for planning stuff and doing actual work?
Personally, seems like too much effort for something that would still need to (and fail to) have some sort of a link between the two, so I could go from the planning over to implementation and back easily. In reality, that'd get lost in the noise of dozens of sessions - I mostly just want the harness to help me do work and otherwise get out of my way, not make me dance around it. Ergo, the more context management it handles, the better!
Eh, I find managing sessions in Pi extremely easy. In fact, I customized how it mages session as part of my workflow, and how agents in different sessions communicate with one another.
It's part of why I really dislike to work in Claude Code, and found it too unwieldy. There I have to keep dancing around it to manage the context in a sensible way.
What’s the difference between sub agents and separate sessions?
I'd assume separate sessions are not aware of each other, sub-agents are spawned by an orchestrator agent?
Almost correct, separate sessions can communicate with one another. In my case, planning and coding communicate by writing files locally.
And subagents don't always communicate with each other, AFAIK that is the most common case.
separate session need more hand holding, i guess?
Er, no?
I mean, not in Pi at least. In Claude Code it is a chore.
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).
Yep, I've used Pi in the past (see my other comment https://news.ycombinator.com/item?id=49908276) but I don't like the direction it went (selling out, forgetting their principles/throwing them out). And since Anthropic wants you to use Claude Code with their sub I just switched to CC again. I've only used Pi for a few months though when GitHub Copilot gave you 300 requests for like 10$.
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.
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.
Glad I'm not the only want to find it a bit janky/broken at times. They seem to constantly be pushing updates which is nice, but I treat it mostly as a black box.
Anecdotally, I find the auto compaction (or what I assume is happening when the context magically drops) to be hit or miss. I do like how easy it is to use my work cursor sub and business chat gpt at the same time. Then I use nearly free cursor models for dumb shit and Sol for real problems.
I used it for a while, and I thought it was quite hard to follow what was going on. And in the end it just went off the rails anyway, though that might have been a GPT-6 kind of thing.
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
Oh thank you for mentioning it has vim mode that's been my only gripe and I had no idea it had it. don't know if it's new or not never noticed the setting.
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 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
What would you say is a good harness with subagents?
I found the MCP extension for Pi to work fine.
> 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.
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.
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.
There were OSS implementations of that but MCP came with anthropic backing and won. Like VHS and Betamax, sometimes you just have to accept that marketing wins over engineering purity.
"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.
I think it's fair to say I know quite a bit about MCP (I built a company on it) so I'll take a crack at this. TLDR: MCP is an Oauth protocol now
MCP started out as this sudo browser replacement protocol for AI integrations. Similar to how a browser opens tabs and loads in JS, the idea was that MCP hosts load in MCPs and interact with them that way. Thus the original spec shipped as a stateful server client protocol with prompts, resources, a bunch of other stuff... and tools (the only thing anyone really ended up using). If you want to learn more about the original idea behind it, the creators did a pretty good podcast where they go through the conception and their design partnership with the Zed guys.
It became pretty clear early on that that way people wanted to use it was basically "I heard if I download this thing called an MCP the AI can manage my Jira tickets". so it's been almost 2 years now of rolling back all the opinions of the original protocol (statefulness, esoteric features) and bringing it closer to OpenAPI + JSONRPC + OAuth. Since the July spec release, you will start seeing alot more of this: https://redocly.com/docs/realm/content/api-docs/openapi-exte...
The biggest "win" of MCP is that the hype behind it let the Oauth guys swoop and use it to formalize a bunch of Oauth specs into a coherent story for API auth.
Hey, I just wanted to say thank you for explaining MCP in those terms, it finally makes sense to me now!
Seriously, it just makes no sense.
https://chatgpt.com/share/6abd1842-cd34-83e8-997e-55c8bc23cd...
Don't be a meat proxy
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.
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.
How is this different from a skill giving you are a URL to another skill file where you can find an up to date list of everything that is available?
Because why should you have to load "here's how to update this skill!" information into the context window every time you use it? Would you expect the agent to go to that URL and look for more recent skill files every time you use it? Is this a real question?
Versus having an agent read MCP config and fetch the existing tools every time it wants to use the MCP? It's duplicate functionality.
The agent doesn't do that. The harness does the fetching and provides the tool definitions to the agent without the agent having to do anything.
Nothing says that agents can't read skills, interpret them and fetch stuff. Needing to agent to pass things off to powerful LLMs to interpret doesn't have to be done for everything.
[dead]
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.
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.
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.
Why do think CLI programs can't store state (locally or on a server)?
Your cli is slightly different than how a LLM uses it. We use 'export' and 'cd' to store state. LLMs dont do that generally.
There is an argument for and against having the model repeat this state.
I'm still on team CLI in that i think even designing an interface from the CLI perspective gets you a better domain interface compared to when you can 'cheat' with the MCP state.
But the thing MCP is just better at is credentials.
The thing that _was_ the dealbreaker between CLI and MCPs is that MCP's couldn't be composed. Maybe `codemode` fixed this; haven't tried enough to say 1 way or another.
CLI support using oauth to authenticate via a browser too.
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?
My customers (non technical people) don’t know how to install a CLI. They’ve never opened a terminal. But they can use an MCP. That’s the main difference.
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?
Plenty of companies will supply an MCP that will never, ever provide a CLI command or free-floating API keys.
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.
[0] https://mcporter.sh/
I'm still confused about what this codemode is. Models have been trained to chain bash and other typical unix tools well. They're so good at that to an uncanny level. Why do we want to not utilize this ability? Is it just a permission management issue in case you don't want the model to use shell directly?
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.
Bash (including `python3 <<EOF...`) is how you orchestrate CLI calls.
If all your tools are CLI calls, all you need is bash.
The one and only impedance mismatch is subagents; nobody's come up with a good way to turn the "subagent" tool into something you can access via the CLI. But I think fixing that would be a more productive direction than surrendering to the MCP insanity.
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.
My understanding is that code mode is supposed to be implemented by the harness, not the MCP provider. You chain multiple MCP providers as well as other harness provided tools inside the sandbox.
My timeline might be wrong (I remember a cloudflare article mentionning the "in MCP" case), but anyway yes there's tools to do it in the harness now and it's the better idea.
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.
The value is that rather than an agent chaining together tool calls itself (which means each step sends the result back to the agent for it to analyse and work out what to do next), it writes a script for the harness to execute that chains together all the calls. The major benefits are:
* speed - much fewer hops back to the LLM
* fewer tokens - intermediate execution steps in the script don't leak into context, only the final result does.
* repeatability - if the LLM needs to repeat work, it can reuse a script it wrote last time.
If you have a harness that has access to a full shell and knows how to use bash or python, you'll often see it writing little scripts. For setups that don't (ie normal model API requests with tool calls), you can give it an lightweight secure execution environment like just-bash, or quickjs.
Agents just do this anyway, how is it a “mode”? I always see the agent writing scripts in a tmp dir to execute or even just inlining bash and python scripts.
Perhaps the appeal is a stronger and more customizable lockdown on agent capabilities.
We're in a HN submission about the least locked down LLM harness, it's too late for that.
We're in an HN submission about the least locked down by default harness. Pi is aimed at being extended, openclaw is a good example of this. You can buy a box of razor blades and put them in any number of razors.
Right the benefit of pi's customization is that it is exactly as locked down or not as you want it to be, in exactly the way you want it to be, and you can inspect it to verify.
but these bash scripts can not execute MCP tools.
What if I have an MCP Tool LookupZip(City) and want to chain it with a bash tool that prodcues a list of 100 cities. And then I want to filter again to the largest Zip code.
Yeah but arguably that tool should be a cli anyway, or could easily be converted to one. The benefit of MCP is that it's _less_ capable than bash.
Not in my testing. A lot of the benefit comes from the tool definitions (from mcp) existing in the context window of the first turn. You could replicate this of course by describing your cli tool in the initial user/system prompt- but, mcp is already 'built' for this at the client (harness) level generally.
These bash scripts certainly can curl the mcp server which is exposing the tool, however.
But agents do write scripts, in bash. And they are very good at it. And bash is quite efficient with its pipeing.
And I said that they do this in my last paragraph. But you need an execution environment for this, and you don’t get this automatically when just interacting with models via their API
this seems to be an incomprehensible point for these people to understand. its really quite bizarre
Bash scripts don't really help when you're dealing with MCP tools or other tools that are local to the harness itself.
Then give them a shell in a VM sandbox. VM sandboxes are way cheaper than LLMs.
thanks! it now clicked for me. so instead of cat its read_file, even if read_file resolves to cat, cat is not always available.
Rather, instead of shell_tool(command: "cat ...")
https://blog.cloudflare.com/code-mode/
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!
Pi doesn't even support a permissions model. It's extremely barebones, you're expected to customize basically everything.
I was enticed by the promise of it being barebones but I still found it too bloated
So I cut out a lot of functionality in my own fork
https://github.com/Pyrolistical/mi
I took “expected to customize basically everything” to heart
... and after using it for a while you might end up forgetting most of the extra stuff you thought you needed in the first place. That's what happened to me and I've never looked back and still am a happy Pi user (https://a.l3x.in/ai if you're curious)
I have already basically removed any extensions I had installed. There are still a couple, but I am going to remove those as well. Except maybe a web search one as that is something I use often. Going to remove all skills and anything else as well. I am a simple man when it comes to agent programming.
I'm a bit bumped when I first saw pi is moving from bash to codemode and also adding MCP, since I thought that loses the purity and simplicity of the "use bash for everything" philosophy. However, after reading more about it, I realized codemode is just a slightly enhanced version of bash: more complex, sure, but likely more robust, secure, and efficient. For those who, like me, don't get the point of this change, here is how I understand it.
The first tool execution runtime in harnesses are direct tool calls with JSON or XML, such as the Read and Edit tools. As an escape hatch, we have Bash tool that allows arbitrary code execution on the host running the agent. The downsides of using bash (on the host) as the main tool execution runtime are:
- Syntax and obvious errors only surface at runtime
- Unergonomic orchestration of parallel and background tasks
- Verbose command output cluttering context
- Dependent on the host environment, packages versions, etc.
- No security measures by default.
To me the last point is the biggest inherent weakness, usually mitigated by creating a dedicated unprivileged user or running bash in a sandbox.
Note that direct tool calling is kind of the polar opposite on these points: syntax errors are caught early, orchestration can be done with some wrapping tools, command output is controlled, and most importantly they are more sandboxed. On the flip side, they obviously have way less power, necessitating Bash tool in the first place.
Codemode is the middle ground between these two extremes. It actually can be derived simply by one idea: what if we replace Bash by another language that can be checked for obvious errors, i.e. type checked?
Everything else falls out from there:
- Any language would do, but I think TypeScript fits the balance between safety, speed, conciseness, and popularity in training data.
- If we use TypeScript, might as well run it in a sandbox as JS runtimes have been designed with this in mind for 20 years
- Orchestration comes for free from the JS runtime. It's not more powerful, just more ergonomic.
- Since the tools are controlled by the harness and not dependent on the host, cloud agent becomes easier.
- With this in place, MCP are not very different from a tool provided to this sandboxed runtime.
Overall I find the benefits compelling enough, but we'll see if the heavily-RLed models these days will use it effectively.
> And while we could have just wired up the metadata to enable better MCP extensions, we also think that MCP with Codemode solves quite a few of the issues that it traditionally had.
There's just something that bothers me about this. Normally if LLMs want to compose multiple operations, they have the perfect tool for this: bash, or whatever other OS shell is available. It's why I was always confused by Codemode-type constructs for direct chaining of tool calls; see also the way highly-RL'd modern models will fall back to sed or python for complex file edits.
It seems like Codemode is raised here as the perfect tool for chaining or composing MCPs, but isn't that backwards? LLMs are already given the perfect tool for that, and the problem is that MCPs aren't exposed to that tool.
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).
Addendum: My unfettered notes on chaining MCP operations are here: https://github.com/rcarmo/umcp/blob/main/docs/CHAINING.md
> 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.
> 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.
It does, but a restricted user account mitigates the large majority of those issues. A sandbox mitigates even more.
The number of remaining exploits left is probably going to be the same as the number in the harness. More, in fact, as many of them have no human review anyway.
You can give the LLM a bash without giving it the full /usr/bin.
That's been a trivially solved problem for decades.
That has been one of the most common exploits for decades.
And as a result it is the most hardened.
So how do you explain it still being in the "OWASP Top 10" and the "CWE Top 25 Most Dangerous Software Weaknesses"?
Yes, and also MCP does literally nothing to prevent these sorts of exploits.
Like I said, AI bros vibecoding slop because they literally have no clue what they're doing.
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.
Yeah, I'm probably over-indexing on local use cases due to my own preferences, prejudices, biases etc. For a coding agent like Pi it does seem reasonable to expect some kind of shell access though, unless some people are using it as a CLI chat client with MCP?
the trouble is that bash inherits the ambient authority of the shell. most of times, if you run MCP in a cli the agent will have access to the key for example (unless your agent do something exotic)
writing python or JavaScript for tool calls make it possible to have an actual permission system (rather than the one usually employed that consists in a regex matching the cli - trivially defeated if the agent has access to an interpreter for instance)
[flagged]
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.
Right, because MCP != web. In fact most of my exposure to MCP has been local tools. Also, for context, we're talking about a coding agent harness that runs on a local machine, and Codemode applies to all of its tools, not just MCP.
Generally, I use skills with a CLI tool instead of MCP and tools. Usually in most cases I also get a coding agent to generate the CLI tool.
I find this approach is easier to debug and I can also use the tool myself to ensure it's working well.
> The first thing to remember is that the world is not static.
I will use this to talk to my manager about the project status
I don't use "AI" but I'm using "MCP" to remotely control software running on another computer on the local network by sending JSON-RPC with netcat
I send an Authorization header with a Bearer token but the procedure calls are sent in cleartext. Is this how "MCP" server is typically implemented (no encryption)
NB. I didn't write the aforementioned software implementing "MCP" server, that's someone else's work
> 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.
As far as I can tell MCP is just "we bothered to document our api in a programatically readable way".
Just generate CLI tools, with docs, from MCP servers on demand.
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.
> new name
Swagger was the new old name for the concept
Exactly! Swagger descriptions+GUI[1], HATEOAS[2], and JSONAPI[3] all coming together in jubilous harmony if MCP pulled its head out of the sand, but instead we get the XKCD#927[4] situation.
1: https://swagger.io/docs/specification/v3_0/adding-examples/
2: https://en.wikipedia.org/wiki/HATEOAS
3: https://jsonapi.org
4: https://xkcd.com/927/
It sounds like the main value-add of codemode is security, since its a sandboxed language that can call your MCPs with elevated privs.
But pi doesn't have security. Pi is full yolo, it's on the user to run it in an environment that minimizes the blast radius if the LLM goes haywire.
So I'm not sure what the plan is here. Will pi support running certain tools like bash as a different OS user than owner of the pi process?
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.
I'm wondering why these aren't extensions rather than baked in. Extensions would be consistent with the historical development mantra of pi.
As many others have commented: good, I too am an mcp hater.
However- in my testing, mcp is really quite fast, and its pretty much free at this point- with frontier models. Context rot is, from what ive tested, not as much of a concern now. I genuinely was not able to hillclimb skills/extensions to beat out the speed of mcp in some cases I've been testing.
This is somewhat similar to HuggingFace smolagents where the model writes code that calls tools, instead of emiting json to describe the tool call per turn. Here Codemode is one tool that the model calls when it needs to compose many tool calls, especially MCP ones. Is what i understand of this.
Just because they were gracious enough to change their mind and talk about it in public doesn't make it universally OK.
Second, the point of Pi as a bare-bones BUT extensible harness is just that - a bare-bones harness, that can get anything one wants. Make that "thing" easy to get. Besides, bloat is bloat and every bloat is someone's must-have and vice versa.
I had also read somewhere that they have launched (already? not sure) their hosted model infra or something like OpenRouter (not sure). Nothing wrong with running a paying business along with a FOSS project but that's also there.
The shimmering effect on the web page... it does not add to the experience. It subtracts. It is very distracting. I want to read what you wrote but keep getting distracted with things moving on the screen.
The advantage I see for MCP over CLIs or APIs, is that once you release the CLI/API and people start coding scripts against it, your interface is set it stone, you're never allowed to change it again, or you break everyone's scripts.
With an MCP, agents are very tolerant of changes, since each usage is fresh with no prior knowledge, so nothing to break. This allows you to experiment and iterate on the MCP, see how people use it and what gaps you still need to cover. Once it stabilizes, you can lock it down into and API/CLI interface.
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
I'm going to pick on the example. Love both pi and use mcp, so it's a welcome change. However, I don't want to live in the world where anger is the prioritisation criteria for fixing bugs, and civil conversation about severe issues goes ignored.
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.
True that.
Good. I too I'm not a fan of MCPs, but these days I do find them useful. In Claude Code I connected to my company's MCP which made Claude Code infinitely more useful for everyday work stuff
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...
The crazy thing with the anti-MCP wave to me could be boiled down to "you don't like it? Then don't use it."
It's like people hate it so much they forget how easy it is to spin one of these up; it's not like I spent weeks and weeks working on this.
I spun up an MCP server for a personal finance app I've been working on. OAuth with personal tokens and all the tools I added- guess how long it took me? Like 2 hours maybe. Some people find it useful, including me, and some don't. That's okay!
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/
I wish the MCP protocol supported push notifications from the app to the model. That'd make for a much nicer integration, with less overhead for this kind of interaction.
Soon https://developers.openai.com/plugins/build/mcp-events
That's great!
So Pi is also accruing cruft now :(
To be clear: absolutely not the plan and nothing is loaded by default that was not loaded before.
Ok! I trust that you and the maintainer will steward the project properly. It's just that I really like Pi as is and am a natural worrier. I'm also not sold on Jev(-likes), so that reasoning rung a bit hollow to me.
I think Jev is worthy of your reconsideration, the OP article has a pretty good use-case for it right within Pi.
It's the cost efficiency that's a big deal. Jev is an excellent cheap "first pass" model.
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.)
Swival.dev has a tool to run Python code, and it can expose the MCP tools as Python functions.
This saves a couple prompts and tokens, but only in very specific cases, only with MCP servers that don't already support code mode, and only with large models.
In practice, I've not found that to make a real difference.
Plus, it's likely that more and more MCP servers are going to use code mode natively anyway.
> That means tools should return structured data and tools should be discoverable by their documentation and description.
Treating MCP as a part of OpenAPI rather than a tool connector is a direction in which we're heading. It is important for the users to have the flexibility of deciding the model, work to be done and the tool call in one prompt. The framework sets up the configuration and gets the output.
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.
I am in the process of setting up a demo local-hosted-model using either vLLM or SGLang for my not-in-software-business enterprise. What harness would you recommend? I mean what are the top 5 open source ones. Trying to avoid unsustainable ( from the business model of agent developers ) harness. Personally I have used only OpenCode / Codex / ClaudeCode / Antigravity.
also consider oh-my-pi. it is much more "batteries included" than Pi
Pi
the conversation seems to dwell on things you could substitute Bash for but the real need stems from completely opaque systems that nothing can reach but which are now getting MCP support. This is where being left out of having MCP support will hurt. I'm still quite happy to let all the harnesses compose bash commands to their hearts content (inside their sandboxes ...)
This is a potentially polarizing (but very welcome imo) change to pi. I'm such a huge fan of the pi SDK, and just yesterday I was trying to wire up the pi mcp extension to be used in a project and sonnet told me about the ongoing work in the 0.99.x tags. Didn't realize the next day it would be merged! Fantastic news.
Best mcp I’ve seen is the chrome devtools one
My biggest frustration with MCP at the moment is that it has no built-in way of uploading and downloading files. Every argument has to go through the context.
Sure you can use curl along with it - but many MCP friendly harnesses don't have access to a tool like that. Wish they had added this before moving on to stuff like MCP apps.
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...
Oh nice! The hook installation response is clever.
It is bizarre that Marco said MCP is hard to compose. It's like he doesn't understand how composability works.
Unix programs are said to be composable, in that you can combine them in different ways to get more complex and useful functionality. But the applications themselves are not composeable. They just take input, perform calculation, and return output. Each app has unique input and output, and none know about other apps. So how can they possibly work together?
Bash acts like a programming language, allowing you to write a new program on the fly. It is very lightweight, but gives enough functionality to do two things: 1) call arbitrary programs, 2) connect their inputs and outputs, 3) make decisions about how to do this to result in a novel solution. It uses Unix pipes to make writing the program easier, but actually it could work fine without pipes, reading/writing program input/output with files.
The important thing is bash is a "glue" program that ties together the other programs. Bash is what makes those programs composeable. That, and the Unix API (execve(), open(), read(), write(), close()) that allows making the call, passing input, reading output, in one standard way for all programs.
MCP is both the application to call, and the Unix API to call them. Your agent harness is bash. Codemode is certainly a neat/more efficient way to write the code, but it's not necessary. What's necessary is getting a very large library of programs, like Unix programs (find, cat, grep, sed, awk, tr, cut, sort, tail, head, etc) that each have powerful functionality. The more programs you have, the more your bash script can do to chain them together and get more powerful results.
LLMs only use Bash because they didn't yet have MCP and a large library of MCP programs. Bash is a stopgap solution. The future is MCP (or whatever replaxes it).
MCP is only for agents, bash (and CLI) is for agents and people.
Perhaps I'm not understanding Pi's architecture correctly, but (unless you want to use popular MCP servers) what is the advantage of MCP vs. Pi's tools? Ins't calling a Pi tool in an extension exactly the same as an MCP tool, in the end?
MCP is a lot like XML these days, it's not bad and still useful, but no longer trending
But I want mayors, animals, gas reservoirs and data lakes. Can Pi offer in game purchases?
Interesting - I didn’t even notice it’s not supported. Must have been added via extension because I definitely have mcp active on pi.
The idea of using jev as a cheaper faster subagent for specific use cases is interesting. Will have to experiment with that!
not to troll, but the CLI vs. MCP feels very much like the SOAP vs. REST discussion. The "CLI works for me, so therefore MCP is sh#t"
AI/SI is having crazy impact on the entire world, and we are left with just 2 ways of doing things ? THAT is crazy to me. With all this creativity and intelligence we are down to two standards, pretty soon Thomas Watson is correct, we only have 5 computers in the world.
That being said, MCP has been truly magical for us, I just wish that the LLM labs would support their connector systems better. Too many "refresh tools" or "sign in again" ..
Welcome to the world all running jsonl.
I thought the whole point of pi was to be minimal. Why are they adding features a user could create themselves? This just seems like the treadmill of endless bloat overwriting the projects principals.
I would like they add websearch and tool approval model of codex.
that seems more niche and also covered by extensions.
Even Anthropic moved to auto-approve by default and they are kings of fearmongering.
What's Pi? Oh an AI agent. Isn't MCP designed for agents? There's still some anti-MCP movement or something?
MCP is just REST with meta data folks. It's all just HTTP and JSON.
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.
We need to stop naming companies after lord of rings lore.
Hmm what is this JavaScript sandbox? container, separate process, same Node process? Also does it have access to the MCP tokens? The harness credentials?
This is good news, I like Pi with local models, but the MCP needing an external plugin and extra "discovery" proxies was never smooth.
> The way we like to think about MCP at this point is that it should be much closer to OpenAPI with intelligent tool discovery.
So, exactly like OpenAPI?
Maybe they can start on sandboxing next. Pi doesn't have a good sandboxing extension that offers Claude/Codex style auto approvals
I might be dumb, but I don't quite understand why just running stuff in sub agents isn't sufficient for the context problem.
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
>The first thing to remember is that the world is not static.
Lol, mammonists truly say the darndest things.
MCPs are nice, but where things really start getting fun is when you have an extensible MCP like jilebi or hyper-mcp
Anyone found a good file upload solution for MCP? Or is the best practice to use HTTP to upload files outside MCP?
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".
The core idea of Codemode that I understood is - The script doesn't actually write any code itself; rather, it acts as a workflow automation and program management tool. It pulls data from an issue tracker, delegates the analysis to a model, and synthesizes the results to help manage Pi's development priorities.
Codemode isn't replacing MCP; it's fixing MCP's biggest flaw—its lack of composability.
This will make it easy to add Pi.dev to a web application and connect it via WebMCP or a backend MCP.
> The first thing to remember is that the world is not static
And you didn’t remember that when you said no to MCP?
No, no MCP for now?
@the_mitsuhiko - How is the session replay of Pi embedded in the article?
It doesn't look to be asciinema?
> @the_mitsuhiko - How is the session replay of Pi embedded in the article?
Some bespoke slop :)
The post mixes Codemode and MCP yet the explanation is strange IMO and both appear to be new things in the latest release
If you are a Pi user it may be better to just ask your agent to explain https://github.com/earendil-works/pi/pull/10040
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 :)
Yeah YMMV. FWIW I did that earlier today and I think I got a better idea about what codemode is than the changelog and the post
As we said in the post, we will write about Codemode more in the future. This post in many ways was necessary to address an Elefant in the room.
"Now we talked so much about Codemode, it might be worth explaining what that even is."
Yeah, since pi is my first agent harness I barely understand what MCP is beyond an API standard. When the essay started talking about codemode without any introduction I was having trouble following it.
> MCP of today is not the MCP of yesteryear
MCP is 22 months old. Pi is 10 months old :)
MCP should have been an HTTP protocol from the get-go.
Honestly, the provided argument for it is rather weak. They are basically adding a way of running scripts that are contained within harness to execute harness's own tools (that's the Codemode). A coding agent can already compose any arbitrary logic by invoking shell scripts (or python scripts, or node scripts), etc - so this is just entirely unnecessary in the core, from my perspective.
If you feel that Pi has been drifting away from its original vision, try hax (https://usehax.dev/) - you might like 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.
Over the last week or so on Twitter, I've seen a lot of people talking about how various ways of using MCP don't compose, but nobody seems to be clarifying what that means with a concrete fashion; which leads me to try and read between the lines.
In this very post:
> While a lot of things have improved about MCP, quite a few have not. The biggest issue with MCP continues to be that it’s hard to compose. Even with codemode, which is just a neat little sandbox to allow composing of tool calls, MCP doesn’t fully deliver on this. But that at this point is less the problem of MCP but the MCP servers out there and different approaches of harnesses to work with them.
Can we get a bit more clarity on this? With codemode, what's the gap? I've also been investigating the search+execute MCP server pattern evangelised by Cloudflare (it uses codemode inside the MCP server to bypass the need to expose a large number of individual tools), but i've seen people say that doesn't compose well either.
Never complain, never explain
Can we talk about the point the article makes that the MCP servers should implement JSON apis instead of text APIs? It makes sense if your harness supports code mode, but an embedded code sandbox is a pretty big piece of machinery and not everyone implements it. It seems like a massive change to the way one should build an MCP. Also why again are we using MCPs instead of OpenAPI when it's now supposed to be just stateless JSON APIs?
This just reads like Pi is becoming Armins and Marios opinions on what a good harness is instead of letting us build our own with the features we want and need.
There were already tons of third party MCP extensions that were every bit as good as this half baked built in.
Already lots of code mode extensions too, which is also opinionated.
Sad to see Pi to go from being: "This harness is yours"
to
"Just another coding harness"
As someone who maintains own coding harness, arguably more capable and powerful than Pi, I assure you the level of integration required to have something working really well nowadays goes against "this harness is yours" philosophy. "Codemode" completely changes the inter-workings of the harness, which spills all over everything else. And codemode is likely the inevitable future, as it's just much more efficient and powerful way for agents to do stuff. I'm planning to completely abandon non-codemode and make codemode the only "mode" in my harness as soon as open source models that I can run on my GPU can handle it well. I'm holding back as I don't want to deal with the complexity of having to support both.
> This just reads like Pi is becoming Armins and Marios opinions on what a good harness is instead of letting us build our own with the features we want and need.
Realistically it was always their harness. If you want "your own harness" you can always click the Fork button.
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.
How come i have been using mcp with pi for the past year?
Good to hear. We have our MCP Running inside Larkspur, an Oil and Gas Operater in OKC. It's been six months with c-suite use. Everything runs local models, the DBs (all three) Postgres w/ Tiger and Neo4j. The local models are for processing messy energy data. And the oil bros access the mcp currently from Claude.
Spec wise: Ampere 128C, 256gb, 4xa4000,& 7800x3d, 96gb, Blackwell 24gb, 4070s. Nvidia fiber and mirkotik. Working on RDMA (but isn't really needed yet, but we have it)
OS - Tumbleweed ARM headless, CachyOS x86 hyprland. It's been easier staying on the edge of the kernel with less abstractions.
I feel like a broken record, but I still don't get the point of MCP. Is this really just another attempt at undoing the mistake of abandoning actual REST APIs?
Off-topic: But anybody else have a nasty taste in their mouth from seeing a company named after a Middle Earth entity now? It fucking sucks!
[dead]
[dead]
[flagged]
[flagged]
[dead]
[dead]
[flagged]
[dead]
[dead]
[dead]
[dead]
so much MCPs in the FTA yet not a line about what MCP actually is.
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.
API + RPC
If you don't know MCP by now that's between you and google
MCP is the NIH non-standard version of OpenAPI.
Companies frequently make business decisions that go against what they "believe" in order to maximize revenue.
An article pretending to address its title, but just beating around the bush.
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.
REST APIs built with HATEOAS are far superior to MCP. It allows AI to perform incremental, intelligent discovery of your APIs. MCP fills up the context with tons of needless tools upfront. HATEOAS can also communicate state, informing what tools are available, what are disabled and why, in a way that can change dynamically.