Original title: Stateless MCP has recaptured my interest (and inspired mcp-explorer and datasette-mcp)
Article
On July 31, 2026, the author says MCP 2.0 (spec date 2026-07-28) revived interest in Model Context Protocol by replacing session-based, two-step tool calls with a single stateless request flow. The earlier pattern required an initialize call, a returned session ID, and a second tools/call request, while the new pattern uses one POST with MCP-Protocol-Version, Mcp-Method, Mcp-Name, and embedded client metadata. The author credits this simplification with making clients and servers easier to implement and more scalable since servers no longer need sticky session state. To explore the protocol, they built mcp-explorer, a Python CLI run via uvx that lists tools, inspects schemas, and invokes calls against a demo MCP server. They also built datasette-mcp for Datasette, exposing list_databases, get_database_schema, and execute_sql to agents while keeping queries read-only. A third project, llm-mcp-client, integrates MCP into LLM CLI workflows and successfully answered a note-count query through tool reasoning. The post frames MCP as a safer alternative to broad terminal or curl access because MCP boundaries are easier to reason about and audit for sensitive use cases. Overall, the writer argues that this release lowers implementation friction while preserving control over what an agent can do. This framing invites broader use in structured and potentially high-trust environments.
Commenters generally agreed MCP is cleaner in practice but split on whether it is the right abstraction compared with Skills or generic HTTP calling layers. Several praised stateless design and noted it mirrors older patterns where clients could have called tools directly, arguing MCP now resembles a constrained, auditable RPC-over-HTTP path that scales better than sessionful variants. Others criticized MCP for context bloat, saying Skills-style selective invocation can reduce token and prompt overhead, and they questioned whether MCP is too granular compared with composable GraphQL- or code-driven approaches like Cloudflare’s function-style tools. Some participants pointed out that stateless behavior existed in earlier MCP servers already, and one highlighted uncertainty around protocol ownership and naming, while another recommended existing tools such as mcp-inspector for interactive probing. A startup perspective argued that turning API endpoints into YAML-backed tool definitions may avoid maintaining MCP servers for each integration. Practical concerns included discoverability, compatibility with existing REST-style endpoints, and resistance to the complexity of running local shells, especially for non-developer AI users. A few commenters welcomed the new protocol and tasks support but still flagged open questions around response size, filtering, and how well the model truly handles tool orchestration at scale.