You said no MCP
585 points - today at 9:55 AM
SourceComments
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...
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.
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/
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 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.
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.
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!
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.
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" ..
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.
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.
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
I will use this to talk to my manager about the project status
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.
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.
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!
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",
},So, exactly like OpenAPI?
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.
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.
The idea of using jev as a cheaper faster subagent for specific use cases is interesting. Will have to experiment with that!
It doesn't look to be asciinema?
Codemode isn't replacing MCP; it's fixing MCP's biggest flaw—its lack of composability.
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
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.
If you feel that Pi has been drifting away from its original vision, try hax (https://usehax.dev/) - you might like it.
I find this approach is easier to debug and I can also use the tool myself to ensure it's working well.
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.
Just generate CLI tools, with docs, from MCP servers on demand.
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.
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"
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?
MCP is just REST with meta data folks. It's all just HTTP and JSON.
And you didn’t remember that when you said no to MCP?
No, no MCP for now?
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).