Stateless MCP has recaptured my interest
Simon Willison explains why the new stateless MCP specification (2026-07-28) has reignited his enthusiasm for the Model Context Protocol. He highlights how it simplifies client and server implementation, making MCP a safer alternative to giving agents arbitrary shell access. Willison showcases three projects he built this week: mcp-explorer, a CLI for probing MCP servers; datasette-mcp, a Datasette plugin exposing SQL tools; and llm-mcp-client, an alpha plugin for his LLM tool. He argues that MCP's tool-based approach is easier to audit and control, reducing security risks compared to open-ended agent environments.
Something I've come to appreciate about MCP is that it's much easier to reason about agent capabilities and what might go wrong than with arbitrary command execution in an open network environment—the default for most of today's general and coding agent tools.
- rutierut
In this thread I’m seeing a couple of the typical skill arguments. Skills don’t pollute the context window and, skills are more flexible and composable.
In this specific post the SQL example gets around this by being super low-level, inherently composable, and low context consumption itself. I’m not sure this works for everyone.
Looking at the Linear MCP for example, they basically just want to expose an API surface and provide 32 MCP tools as a result of that. My agents do run into composability problems here all the time and fall back to the tool they included which allows you to run arbitrary GraphQL. This takes a couple tries usually. I don’t really know what the sensible alternative to this is.
Cloudflare switched to “code mode” which basically provides 2 MCP tools: search and execute. Both take a TS arrow function, the first allows you to programmatically search a TS api spec, the second to compose and run the methods in that spec.
I think this is a very interesting approach, and certainly better than providing the ~1000 actions as MCP tools but I feel the jury is still out on exactly how well this pans out.
- ai_critic
It is amazing that folks getting paid several hundred thousand dollars a year...reinvented RPC-over-HTTP/JSON. You too, fellow web developers, are smart enough to work at Anthropic.
I would love to see a proper engineering post-mortem for how this happened.
- firasd
I think stateless-type MCP was already possible, eg my MCP Clock [https://github.com/firasd/mcpclock]:
> curl -s -X POST "https://mcpclock.firasd.workers.dev/mcp" -H "Content-Type: application/json" -H "Accept: application/json, text/event-stream" -d '{"jsonrpc":"2.0","id": 1,"method":"tools/call","params":{"name":"clock_get","arguments":{}}}' | grep '^data:' | sed 's/^data: //'| jq
{"result": {"content": [{"type": "text",
"text": "[\n {\n \"timezone\": \"UTC\",\n \"iso\": \"2026-08-05T04:44:41.707Z\",\n \"unixtime\": 1785905081\n },\n {\n \"timezone\": \"Alphadec\",\n \"alphadec\": \"2026_P4A0_466322\"\n }\n]"
}]},"jsonrpc": "2.0", "id": 1}
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...
- drdexebtjl
In retrospect, stateful MCP was clearly wrong.
This essentially makes MCP just another REST API endpoint, and lets you use the same infrastructure you already have set up for REST APIs (like load balancers, API gateways, progressive rollouts, etc).
- mailmrg
In our startup, we build harness that allows people to call endpoints like the ones that MCP supports. we looked it as 2 class of problems. One is sources like databases where the protocol is not http/json/rpc. Here we support MCP based calling. then there are ones where the protocol is just http/json/rpc - say calling shopify or linear or others. Now the harness itself comes with a generic http execution engine. So if you know the endpoint, auth and operation - the harness converts this into a yaml structure for internal purpose and directly calls the endpoint. all info that LLM needs like how the endpoints are, what can be passed and how to check response etc., is all english defined and stored in yaml. Now the harness uses this info to expose these to LLM and when LLM wants to makes a tool call that needs to call the http endpoint the http engine in the harness executes it on behalf of it and gives response back to LLM.
this way every server dont have to expose and maintain an MCP server to expose them to LLM. allow us to connect to any endpoint and teams dont have to maintain and scale one more info.
Not sure whats the downside of this approach is but its serving us well so far.
- cheema33
My main issue with MCP servers has been context bloat. Skills have progressive disclosure, and allow me to turn off auto invocation with something like this in the SKILL.md file:
disable-model-invocation: true
Most MCP servers still bloat up my context even when I am not using them at all. Why can't they be configured to allow me to keep them out unless I really need to use them?
- Satoshi_Bro
As more AI agents rely on MCP, stateless implementations seem like a natural fit for horizontal scaling. The remaining challenge is efficient context management, interested to see how different projects tackle that.
- Foobar8568
I still don't get MCP. Most likely because I didn't really check but the first feeling is creating a problem to solve a problem that doesn't exist in the first place.