Stateless MCP has recaptured my interest

Something that anyone doing distributed systems knows after a few scars, stateless servers are always better, and stateful only if there is no way around it.

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

Somehow this keeps having to be relearnt.

I think part of the “just use a CLI” crowd might also be building similar agents as ChatGPT and Claude.ai web interface. I know at least 4 teams doing that in one company.

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

I don’t think the “just use a CLI” crowd really are assuming you’re a developer in a coding harness.

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?

The "CLI crowd" is also primarily using LLMs on their own computer. Where they have their CLI tools.

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.

Also:

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

The documentation for the --cli mode is a bit lacking, but I got there in the end:

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

Equivalent with my mcp-explorer tool:

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

So yeah, they're pretty similar.

Then for my list command:

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

With the inspector one you would do:

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

Mine returns a human-readable list (unless you add --json), the inspector one returns a big dump of raw JSON.

I would generally agree, but a word of caution for anyone trying it out from this thread: Try the latest pre 2.x version. The 2.0.0 that was released last week is highly broken even for some of the most common connection scenarios.

MCP was much more important when agents weren’t able to accurately make tool calls.

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.

This is basically what Swamp is[1]. You give an agent a typed interface to extend itself (or use other peoples extensions) into the systems you need to fulfill your request. Think of it like on-demand tool calls. Then it records everything that happens in the swamp. The swamp can be single machine, multi-machine, or centralized with your co-workers.

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 think this exists: https://github.com/imbue-ai/latchkey (and there are other similar projects, too).

A proxy?