All those teams, including ChatGPT and Claude.ai, have figured out that you will eventually need to give your agent a small sandbox Linux environment to unlock the same level of “intelligence“ those coding harness exhibit. Stitching together the results of a cli command through scripting or coding gives the agent a ton more flexibility in what it can do as it can utilize its text generation capability into executable logic. toolcalls mostly work for actions rather than complex and novel problem solving. You are making the agent represent a programming control flow through toolcalls while carrying the context between them in a lossy, nondeterministic, wasteful, slow and rigid way.

It’s one thing if you want to artificially limit that agent to a very strict set of available APIs that it must use in a specific way while transferring context between them through the LLM and you don’t want to incur the cost of the extra sandbox compute. But coding harnesses have demonstrated that letting the agent write a small shell or python script can let the agents solve problems that you haven’t even really anticipated in your toolcall approach or that tool calls make prohibitively expensive or not even possible.

But also the token cost tends to dwarf the sandbox compute cost, so why not pay the $0.05/hour to have a sandbox where the agent can run free when you are already paying orders of magnitude more for the tokens

All of those use cases you mentioned benefit from the agent having access to a temporary virtual machine with a set of standard CLI tools and the ability to write and execute arbitrary code.

Most already do. ChatGPT has been running Python in the cloud to answer questions before we even had functional coding harnesses.

So why not augment their repertoire of CLI tools instead of a completely new protocol?

This doesn't cover the case when you're talking to an LLM from web, or via Slack or Linear, etc. There, you will want MCP so the LLM can use services on your behalf as you. That's portability.

your messages causing your LLM (harness) to run CLIs on your computer? charming, thrilling, great fun.

other people’s messages causing your LLM to run CLIs on your (cloud) computer? terrifying, awful, sickening, no fun at all

I learnt this with Sun RPC and the whole "The network is the computer".

Somehow this keeps having to be relearnt.

1. a REST-like API

2. with a spec (OpenAPI, introspection, etc.)

3. with harness-level authz (the ability to allow / deny specific methods in the harness)

The only part that's actually new is #3, but it seems like it should be fairly easy to provide similar support for REST APIs. There might already be a Pi extension that allows you to allow / deny particular method / path patterns for particular sites. Regardless, there's always service-level authz with service accounts, at least for the more sophisticated APIs.

So ya, I don't see why we need a whole new set of standards and protocols just to have harness-level fine-grained API permissions. We could have just done it all with REST.

  npx @modelcontextprotocol/inspector --cli \
    https://agentic-mermaid.dev/mcp \
    --method tools/call \
    --tool-name render_svg \
    --tool-args-json '{"source":"graph TD; A-->B","options":{"padding":24}}'

  uvx mcp-explorer call \
    https://agentic-mermaid.dev/mcp render_svg \
    -a source 'graph TD; A-->B' \
    -a options '{"padding":24}'

Then for my list command:

  uvx mcp-explorer list https://agentic-mermaid.dev/mcp

  npx @modelcontextprotocol/inspector --cli \
    https://agentic-mermaid.dev/mcp \
    --method tools/list

As a result, everything compounds. The work I do doesn't need to be re-derived by the work you do. Typed models keep everything repeatable and deterministic. Huge reduction in token spend and huge increase in speed.

1: https://swamp-club.com

I love this question because of the diverse answers given and we learn from each other.

Nowadays, these agents are more capable and I think you can replace MCP (which is a pain on macOS), with simple CLI tools and expose them to agents via system prompt, skills, or other API documentation.

I am guessing keeping them all in every request is cache efficient though.

But you can have both: rund the agent outside the vm/sandbox and orchestrate work on it, either directly via shell calls or kicking off an ephemeral subagent on the box.

This makes the agent and session that runs outside the vm more durable and opens new orchestration pattern.

I’m building the oss version of this here: https://github.com/smartcomputer-ai/lightspeed

When you talk to an LLM on the web, the harnesses spin up a fresh environment (I would hope it’s a VM…) so that the LLM can do stuff like run arbitrary Python and Bash scripts to complete the task you asked it for.

There’s no reason why you shouldn’t be able to customize this environment to add whatever CLI tools and credentials you need for the agent to act on your behalf.

The UX would be exactly the same.

I maintain https://endara.ai and you can very quickly introduce a ton of capabilities for Claude/Cursor/ChatGPT by configuring all the stuff you use in a single place (and slicing them with profiles if needed).

But let’s take my MCP clock for example if you ask ChatGPT what’s the time in Tokyo it’s not even gonna think of booting up the code interpreter. It’s gonna just do web search and give you the wrong time (I just tried it and there may be an OpenAI built in widget it pops up now—but again that’s a specific tool call with an iframe output not arbitrary code)

It’s not true. It’s not totally untrue, but don’t hide your head in the sand.

The idea could be that the agent runs as a unix user. That user has execute access to these scripts but not read or write access.

So the agent can only do what those scripts allow, the scripts present an API. You could let agents call the scripts with -h to get instructions, and just put some text into context saying like "to access helper scripts call ./showHelp".

The point is that even web search should be a CLI tool, and all ChatGPT would know to do other than talk to you is how interact with a shell.

Then if you ask it what’s the time in Tokyo, it would likely reach for the POSIX date command, instead of web search, because both would be equally visible.

> I find building CLI tools like this to be a really productive way to get familiar with a specification.

This is easy to see when you think in terms of a client: It is pretty much impossible to build an opinionated UI for any kind of RESTful API, while creating one for an MCP server is fairly self-explanatory: MCP servers offer a mandatory and complete runtime introspection endpoint (you can retrieve a listing of available tools/resources/prompts etc. along with their parameter and return type schemas). So that means clients have a way to exhaustively describe everything an MCP server is able to do with a vocabulary that carries over exactly to other servers - a tool is a tool everywhere.

I think that’s a future plenty of people see or want. But simpler and composable Linux commands are far more flexible than pre-defined Windows or Mac “Settings App”. The barrier to entry for the former was knowledge and familiarity, while the latter optimizes for simpler user experience. Agents don’t have to worry about knowledge or familiarity the way users do.

Optimizing the interface for agents to do a “get_clock | get_calendar_events | filter_by(2_hours_from_now)” or then thinking “we should add a get_calendar_events(filter_by_start=now() + 2h) tool” is too rigid for little benefit. And makes it more likely that you will optimize for scenarios you care about and lose a lot of what makes coding harnesses appear really “intelligent” by solving problems quickly as they go

An MCP tool call that returns the top N spenders puts the result in the agent’s context window.

A CLI tool call on the other hand… The agent can pipe their results into other completely unrelated CLI tools. It can write a loop that calls multiple tools.

These things are not possible with MCP but are trivial with CLIs.

The difference is that we already have Bash :)

There are multiple products that turn OpenAPI schemas into front-ends nowadays.

they do but more importantly model does not give a flying fuck about what you put in there in any consistent way.

ppl have been mislead by ai companies that they've invented some sort of agi that you can 'explain' to using skills. So ppl have come up with also sorts of skills that dont do jack shit.

[1] Recently: Opus 4.7/4.8 and Kimi K3

Code mode is great but not needed anymore in 95% of use-cases.

But I wouldn't discount how uphill it was to probably even argue for something like MCP cause the labs still very scientist-driven and focused on solving everything in token space. The idea that tool use could be super transformative probably wasn't obvious from inside before Claude Code

The actual implementation may have been very janky but the idea itself is sound: If you want to interact with arbitrary services then providing one single protocol (ideally not JSONRPC but hey) with a standard api discovery method and standard starting method call means your super-intelligent machine god can connect to any MCP service with just a URL and figure everything out from there.

I have long observed that tooling+methodology is a very distinct skillset in software developers - those who treat both subjects with appropriate governance, excel - those who ignore one for the other, tend to make a mess of it.

If you don't have the methods, you will re-invent tools to find those methods. If you don't have tools, you will develop methods sufficient to the creation of those tools. Too many times, folks who have no method of finding existing tools, will instead just build a duplicate tool .. which they will use until they learn the tool-discovery method.

I think AI/ML is really turning the tooling+methodology equation into a maelstrom. Apropos proper engineering post-mortem, I would question the impact on AI/ML-derived riches on the drive to turn standard methods into Subscription Services© behind Yet Another Tool™ ..

Someone should have said to the llm coming up with it -- "that sounds like an API with extra steps ... how about we keep these things (tool descriptions) and get rid of all this irrelevant - this will look good in my promotion meeting - overengineering (everything else)"

You are absolutely right is what it would have replied with.

Of course they do. Do you really think that there's a magical bag of holding for the potentially infinite amount of skills?

Only when my AI and its subagents are modelled through a graph of producing agents, consuming agents, and agentic mailboxes, will Claude Code truly shine.

The reason is that these "folks getting paid several hundred thousand dollars a year" are mostly youngsters without any care to learn about computing history, which is why IT is a fashion industry.

See HTMX as another example, that is basically ASP.NET Ajax or JSF Ajax.

Now when I ask ChatGPT for a product, it does a web_search tool call and then gives me a link to a webshop product page. But next step would be automatically using the MCP of that webshop to embed checkout inside chat.

Edit: I read it. Yep.

We have text interfaces refined by humans for decades and there's an endless sea of training data for them, but they imagine these amateur-hour homegrown solutions will ever outdo an agent with shell access?

If I understand correctly, you’re not answering my question, and you’re not talking about MCP either. Have you considered that maybe you’re in the wrong thread?

It's a terrible protocol with zero value beyond bigtech sponsorship. We're all worse off for it.

(To your point...having knocked out CORBA and DCOM, perhaps we may next look forward to SOAP.)

Why not just pre-train the model to interact with JSONRPC endpoints?

LLMs need to say stuff like “your company sells sparkling water, you should not build and maintain another in-house product board and CRM”, and then stand their ground.

Maybe Microsoft should bring back Biztalk for agentic workflows.

But yes, that is the crux of the problem indeed. Agency is nothing if you don't have methods to turn it into tool-use.

I do think a lot of the standard would have been easier if they'd been stateless first, and allowed for GET requests, but it evolved from a starting point that has since evolved.

And then the model will randomly decide to load the .md file that is the "skill" randomly at any point. Again polluting the context.

There's no magic.

There is no magic and people should be more precise when discussing skills.

Even when it is disabled? The point is to have the skill or mcp app to not use ANY tokens until I call it by name. I can do that with a skill. Can I do that with an mcp app?

But yeah. You could have files with skills outside of the auto-discovered skill tree, and invoke them manually.

You can probably throw together a passible auth system on top of it that works with the htaccess format. Which is another cgi script but chowned so it can't be called from the outside. If not that, public key crypto - give your agents certificates that are part of the chain of trust. Mint those out of band and give them an insanely short TTL. Fail2ban or something like that to prevent abuse (agent getting handsy with the server gets blocked, credentials revoked).

The side benefit is that everybody starts writing perl and awk again. Who needs a JS runtime when you have CGI?

Token count is a less important factor in context pollution than idea count. The worst of the rot factors are when models latch onto irrelevant information, or over-index on some vague idea/suggestion as if it was a hard direction, and then go off course.

The names + one-line descriptions of 10 tools can do as much (or more!) to distract the focus and intentionality of an agent than a 30k token exhaustive API documentation of some tool.

Or you may choose another plugin that works differently.

That's the whole point of extensible systems like Pi or Emacs, you don't need to pray that maintainers will have the same vision as you, you just pick one of the many alternatives instead. Or ask pi to write one for you.