You said no MCP
earendil.com
earendil.com
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
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...
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.
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
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.
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
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 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.
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.
Definitely helps that the home assistant api is documented online most likely in the training data.
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!
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
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?
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
This seems like exactly the sort of thing I've done with shell scripts or even makefiles.
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 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.
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.
Why is AI involved for any other reason than building the original test implementation?
Not sure if you got the right context, your question doesn't really make sense to me.
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.
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
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 :-)
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.
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!
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
Is that not how it works out of the box?
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.
Everyone on this forum has an absolute paucity of imagination when it comes to applying LLMs to any use case that doesnt involve coding.
Of course MCP has its use case like if you want auth, or session based actions.
NO IT CANT!!! why dont you understand that not all agents have access to a terminal!
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.
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.
"Might be out of sync" is a unique spelling of "crucified online". :-D
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?
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.
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/
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.
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.
Codex is the only mainstream harness that does not implement this in the client.
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.
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 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.
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.
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.
“When a favor becomes too large to repay, the gratitude turns to resentment.”
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.
It is only going to continue to proliferate in usage and adoption.
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.
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?
We need a dunning-kruger for empathy: people least able to imagine situations not their own trying hardest to influence others.
lmao not sure if you are being sarcastic but that guy is joker and a poster child of ai psychosis .
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.
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.
Then again, I don’t even know if general adoption is what Pi/Earendil is going for.
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.
[0]: https://pi.dev/docs/latest/security#understand-project-trust
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.
Further, pi is now owned by a company which as we all know, tend to explode code with features while chasing product market fit.
Though as time progresses, they are probably going to do the same with sub-agents.
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.
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 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.
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
Same idea with something like OpenCode, there I even configured custom agents for review: https://opencode.ai/docs/agents/
https://github.com/can1357/oh-my-pi
I haven't tried it much though, can't vouch how well it works.
On top of that, somewhat unrelated I’ll agree but still, it has support for vim keybindings
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.
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.
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.
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.
https://modelcontextprotocol.io/specification/2025-11-25/cli...
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.
https://chatgpt.com/share/6abd1842-cd34-83e8-997e-55c8bc23cd...
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.
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
MCP's have all the same advantages that a rest api has over a cli.
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.
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.
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.
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.
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
* 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.
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.
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!
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
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.
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.
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).
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.
That's been a trivially solved problem for decades.
Rootless immutable containers without shell access, or SaaS products from multiple vendors with WebAPIs as the only touch point.
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)
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.
I find this approach is easier to debug and I can also use the tool myself to ensure it's working well.
I will use this to talk to my manager about the project status
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
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.
Just generate CLI tools, with docs, from MCP servers on demand.
Swagger was the new old name for the concept
1: https://swagger.io/docs/specification/v3_0/adding-examples/
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?
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.
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.
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.
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.
MCP makes my boss happy so I’m happy
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",
},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.
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!
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'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.)
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.
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.
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.
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).
The idea of using jev as a cheaper faster subagent for specific use cases is interesting. Will have to experiment with that!
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" ..
MCP is just REST with meta data folks. It's all just HTTP and JSON.
Nowadays they moved to http and stateless.
Even Anthropic moved to auto-approve by default and they are kings of fearmongering.
So, exactly like OpenAPI?
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.
[0]: https://erato.chat/docs/features/mcp_servers#file-support
Codemode isn't replacing MCP; it's fixing MCP's biggest flaw—its lack of composability.
Lol, mammonists truly say the darndest things.
And you didn’t remember that when you said no to MCP?
No, no MCP for now?
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
If we fail to explain it, then we need to do a better job explaining it :)
It doesn't look to be asciinema?
Some bespoke slop :)
If you feel that Pi has been drifting away from its original vision, try hax (https://usehax.dev/) - you might like it.
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.
MCP is 22 months old. Pi is 10 months old :)
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.
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"
> 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.
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.