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.

[0] https://reddit.com/r/macapps/comments/1wkv0dy/mcp_in_macos_a...

[1] https://lowtechguys.com/crank

    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? 

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.

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.

[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

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.

  /autocompact 420k

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

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.

MCPs are nice, but where things really start getting fun is when you have an extensible MCP like jilebi or hyper-mcp

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

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?

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

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

I'm wondering why these aren't extensions rather than baked in. Extensions would be consistent with the historical development mantra of pi.

> 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

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?

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",
    },

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

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.

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.

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

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.

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.

MCP is a lot like XML these days, it's not bad and still useful, but no longer trending

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

Best mcp I’ve seen is the chrome devtools one

So Pi is also accruing cruft now :(

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!

Never complain, never explain

This will make it easy to add Pi.dev to a web application and connect it via WebMCP or a backend MCP.

Hmm what is this JavaScript sandbox? container, separate process, same Node process? Also does it have access to the MCP tokens? The harness credentials?

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.

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

Maybe they can start on sandboxing next. Pi doesn't have a good sandboxing extension that offers Claude/Codex style auto approvals

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 is good news, I like Pi with local models, but the MCP needing an external plugin and extra "discovery" proxies was never smooth.

But I want mayors, animals, gas reservoirs and data lakes. Can Pi offer in game purchases?

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?

Anyone found a good file upload solution for MCP? Or is the best practice to use HTTP to upload files outside MCP?

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.

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

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.

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"

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.

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.

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

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.

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?

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

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!

so much MCPs in the FTA yet not a line about what MCP actually is.

[dead]

[flagged]

[dead]

[dead]

[dead]

[dead]

An article pretending to address its title, but just beating around the bush.

Companies frequently make business decisions that go against what they "believe" in order to maximize revenue.

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.