Stateless MCP has recaptured my interest

(simonwillison.net)

34 points | by tosh 3 days ago

6 comments

  • firasd 37 minutes ago
    I think stateless-type MCP was already possible, eg my MCP Clock:

      > 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...

    • acchow 31 minutes ago
      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.

  • CharlieDigital 56 minutes ago
    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.

    • hchja 37 minutes ago
      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.

  • ameshkov 1 hour ago
    > 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

    • simonw 21 minutes ago
      The documentation for the --cli mode is a bit lacking, but I got there in the end:

        npx @modelcontextprotocol/inspector --cli \
          https://agentic-mermaid.dev/mcp \
          --method tools/call \
          --tool-name render_svg \
          --tool-args-json '{"source":"graph TD; A-->B","options":{"padding":24}}'
      
      Equivalent with my mcp-explorer tool:

        uvx mcp-explorer call \
          https://agentic-mermaid.dev/mcp render_svg \
          -a source 'graph TD; A-->B' \
          -a options '{"padding":24}'
      
      So yeah, they're pretty similar.

      Then for my list command:

        uvx mcp-explorer list https://agentic-mermaid.dev/mcp
      
      With the inspector one you would do:

        npx @modelcontextprotocol/inspector --cli \
          https://agentic-mermaid.dev/mcp \
          --method tools/list
      
      Mine returns a human-readable list (unless you add --json), the inspector one returns a big dump of raw JSON.
  • pianopatrick 1 hour ago
    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.

    • nickstinemates 42 minutes ago
      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

    • Wuzzy 47 minutes ago
      I think this exists: https://github.com/imbue-ai/latchkey (and there are other similar projects, too).
    • parf02 1 hour ago
      A proxy?
      • pianopatrick 58 minutes ago
        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".

  • tosh 1 hour ago
    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

  • brianjking 3 days ago
    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.