Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Stateless MCP has recaptured my interest

simonwillison.net

Post reply on HN
Print view View original

11–20 of 246 posts

Re: Stateless MCP has recaptured my interest

#11

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

Re: Stateless MCP has recaptured my interest

#12

Post by hchja »

CharlieDigital wrote: post #8

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.

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.

Re: Stateless MCP has recaptured my interest

#13

Post by acchow »

firasd wrote: post #11

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":…

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.

Re: Stateless MCP has recaptured my interest

#14

Post by [deleted] »

pianopatrick wrote: post #5

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 agen…

[deleted]

Re: Stateless MCP has recaptured my interest

#15

Post by simonw »

ameshkov wrote: post #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. https://github.com/modelcontextprotocol/inspector

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.

Re: Stateless MCP has recaptured my interest

#17

Post by spike021 »

hchja wrote: post #12
CharlieDigital wrote: post #8

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.

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.

How well does that work in enterprise setups?

Re: Stateless MCP has recaptured my interest

#18

Post by hobofan »

ameshkov wrote: post #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. https://github.com/modelcontextprotocol/inspector

I would generally agree, but a word of caution for anyone trying it out from this thread: Try the latest pre 2.x version. The 2.0.0 that was released last week is highly broken even for some of the most common connection scenarios.

Re: Stateless MCP has recaptured my interest

#19

Post by kristjansson »

firasd wrote: post #11

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":…

Also:

your messages causing your LLM (harness) to run CLIs on your computer? charming, thrilling, great fun.

other people’s messages causing your LLM to run CLIs on your (cloud) computer? terrifying, awful, sickening, no fun at all

Re: Stateless MCP has recaptured my interest

#20

Post by eddythompson80 »

firasd wrote: post #11

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":…

I think part of the “just use a CLI” crowd might also be building similar agents as ChatGPT and Claude.ai web interface. I know at least 4 teams doing that in one company.

All those teams, including ChatGPT and Claude.ai, have figured out that you will eventually need to give your agent a small sandbox Linux environment to unlock the same level of “intelligence“ those coding harness exhibit. Stitching together the results of a cli command through scripting or coding gives the agent a ton more flexibility in what it can do as it can utilize its text generation capability into executable logic. toolcalls mostly work for actions rather than complex and novel problem solving. You are making the agent represent a programming control flow through toolcalls while carrying the context between them in a lossy, nondeterministic, wasteful, slow and rigid way.

It’s one thing if you want to artificially limit that agent to a very strict set of available APIs that it must use in a specific way while transferring context between them through the LLM and you don’t want to incur the cost of the extra sandbox compute. But coding harnesses have demonstrated that letting the agent write a small shell or python script can let the agents solve problems that you haven’t even really anticipated in your toolcall approach or that tool calls make prohibitively expensive or not even possible.

But also the token cost tends to dwarf the sandbox compute cost, so why not pay the $0.05/hour to have a sandbox where the agent can run free when you are already paying orders of magnitude more for the tokens

Post reply on HN