Stateless MCP has recaptured my interest

The strongest reaction was that this lands exactly where many people expected it would: back at plain old RPC over HTTP with some agent-specific conventions layered on top. A lot of readers were openly smug about that. They saw stateful MCP as an unnecessary detour and stateless MCP as an admission that distributed systems still punish avoidable state. The practical defense of MCP was not that it invented something new. It was that it bundles discovery, schemas, auth patterns, permission controls, and agent-facing conventions into a format AI vendors actually support. Several people framed that as the whole value. Standards only matter when the major clients implement them. The more interesting split was not “MCP good” versus “MCP bad”. It was whether agents should primarily use tightly scoped tool calls or a sandbox where they can write code, compose commands, and filter outputs before those outputs hit the model context. The shell advocates argued that agents are already unusually strong at CLI usage, and that forcing multi-step reasoning through tool calls is slower, more brittle, and often more expensive in tokens than just letting the model write a short script. MCP defenders pushed back that shell access creates ugly security and permission problems, especially for web and enterprise deployments, and that MCP gives you cleaner auth, narrower capabilities, and easier auditing. The conversation ended up in a more grounded place than the headline-level snark: stateless MCP looks like a workable transport, but the harder problem is still designing the harness around context management, composability, and trust boundaries.