Stateless MCP has recaptured my interest
simonwillison.net
Stateless MCP has recaptured my interest
1–10 of 246 posts
Re: Stateless MCP has recaptured my interest
#2Yeah, 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.
Re: Stateless MCP has recaptured my interest
#3> 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.
Re: Stateless MCP has recaptured my interest
#4I'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
Re: Stateless MCP has recaptured my interest
#5Maybe 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.
Re: Stateless MCP has recaptured my interest
#6Maybe 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 agen…
A proxy?
Re: Stateless MCP has recaptured my interest
#7Maybe 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 agen…
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".
Re: Stateless MCP has recaptured my interest
#8Stateless 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.
Re: Stateless MCP has recaptured my interest
#9Maybe 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 agen…
I think this exists: https://github.com/imbue-ai/latchkey (and there are other similar projects, too).
Re: Stateless MCP has recaptured my interest
#10Maybe 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 agen…
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.