The "just use a CLI" crowd is implicitly assuming:
1) You're a developer 2) On a laptop 3) With a shell open inside an agentic coding harness (Claude Code, Codex CLI, Cursor) 4) Working on a software project
That's maybe 2% of AI usage.
The other 98% is: Someone on the ChatGPT iOS app asking a question on the subway; Someone in Claude.ai web chatting about their calendar; Someone using ChatGPT Desktop to summarize their Notion; A non-developer using AI in a browser at work; Voice mode on a phone; An embedded chat widget on some company's website...
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.
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.
Maybe someone could set up a CLI tool for agents such that you can give them a shell but they use this CLI tool instead of raw curl.
Like a tool where the AI can only call out to certain APIs based on a config file the agent cannot change.
That way you can leverage all the shell knowledge agents already have while still limiting what network calls they can make, and you wouldn't have to set up a server to use an agent.
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.
Maybe. I'm just spitballing but as I've been thinking about this, maybe just like a set of shell scripts.
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".
a few months ago I tried to implement an MCP server from scratch in python (instead of using the existing reference implementation) and I could not get it to work reliably across clients
I think stateless-type MCP was already possible, eg my MCP Clock:
The "just use a CLI" crowd is implicitly assuming:1) You're a developer 2) On a laptop 3) With a shell open inside an agentic coding harness (Claude Code, Codex CLI, Cursor) 4) Working on a software project
That's maybe 2% of AI usage.
The other 98% is: Someone on the ChatGPT iOS app asking a question on the subway; Someone in Claude.ai web chatting about their calendar; Someone using ChatGPT Desktop to summarize their Notion; A non-developer using AI in a browser at work; Voice mode on a phone; An embedded chat widget on some company's website...
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.
Stateless MCP was already possible before this and made sense for whole classes of use cases where it helps to have a remote fleet of servers.
Wrote about this back in March: https://chrlschn.dev/blog/2026/03/mcp-is-dead-long-live-mcp/
MCP is going to be a foundational piece of enterprise agent infra.
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.
> I couldn’t find a great CLI tool for interactively probing an MCP server
What about mcp-inspector? It’s a nice tool, can be used interactively, can be used as a CLI.
https://github.com/modelcontextprotocol/inspector
The documentation for the --cli mode is a bit lacking, but I got there in the end:
Equivalent with my mcp-explorer tool: So yeah, they're pretty similar.Then for my list command:
With the inspector one you would do: Mine returns a human-readable list (unless you add --json), the inspector one returns a big dump of raw JSON.Maybe someone could set up a CLI tool for agents such that you can give them a shell but they use this CLI tool instead of raw curl.
Like a tool where the AI can only call out to certain APIs based on a config file the agent cannot change.
That way you can leverage all the shell knowledge agents already have while still limiting what network calls they can make, and you wouldn't have to set up a server to use an agent.
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?
Maybe. I'm just spitballing but as I've been thinking about this, maybe just like a set of shell scripts.
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".
I'm glad MCP is getting simpler
a few months ago I tried to implement an MCP server from scratch in python (instead of using the existing reference implementation) and I could not get it to work reliably across clients
Yeah, there's a ton of great improvements in 7-28. I'm personally excited about what you posted about, but also with [tasks](https://blog.modelcontextprotocol.io/posts/2026-07-28-releas...) being officially adopted.