alt Hacker NewsPi.dev: You Said No MCP
Comments
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.
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 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.
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.
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.
> 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 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!
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?
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 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.
> 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'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.
> 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
Hmm what is this JavaScript sandbox? container, separate process, same Node process? Also does it have access to the MCP tokens? The harness credentials?
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!
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.
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
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.
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.
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 ...)
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.
Best mcp I’ve seen is the chrome devtools one
But I want mayors, animals, gas reservoirs and data lakes. Can Pi offer in game purchases?
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.
Anyone found a good file upload solution for MCP? Or is the best practice to use HTTP to upload files outside MCP?
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
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?
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
And you didn’t remember that when you said no to MCP?
No, no MCP for now?
so much MCPs in the FTA yet not a line about what MCP actually is.
[dead]
[dead]
[dead]
An article pretending to address its title, but just beating around the bush.
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.
[0] https://reddit.com/r/macapps/comments/1wkv0dy/mcp_in_macos_a...