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

51–60 of 247 posts

Re: Stateless MCP has recaptured my interest

#51

Post by simonw »

drdexebtjl wrote: post #44
firasd wrote: post #29

Earlier quoted context omitted.

Right we can quibble about the wire protocol but the point remains that the arbitrary REPL becomes suboptimal as a solution when there’s not a deterministic endpoint. So ‘scripting’ is not really what we are looking for; we just want the final data output and scripting is fine when it’s a one off

They’re not the same thing under a different wire protocol! An MCP tool call that returns the top N spenders puts the result in the agent’s context window. A CLI tool call on the other hand… The agent can pipe their results into other completely unrelated CLI tools. It can write a loop that calls multiple tools. These things are not possible with MCP but are trivial with CLIs.

Anthropic proposed a way to programmatically chain MCPs together a while back, I'm not sure if it's been implemented much yet: https://www.anthropic.com/engineering/code-execution-with-mc...

Re: Stateless MCP has recaptured my interest

#52

Post by rixed »

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.

why is MCP a pain in Macos?

Re: Stateless MCP has recaptured my interest

#53

Post by lukebuehler »

eddythompson80 wrote: post #20
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 re…

Fully agree that in the end sandboxes are required to get frontier performance out of the models.

But you can have both: rund the agent outside the vm/sandbox and orchestrate work on it, either directly via shell calls or kicking off an ephemeral subagent on the box.

This makes the agent and session that runs outside the vm more durable and opens new orchestration pattern.

I’m building the oss version of this here: https://github.com/smartcomputer-ai/lightspeed

Re: Stateless MCP has recaptured my interest

#54

Post by dymk »

bloppe wrote: post #47
9dev wrote: post #36

Earlier quoted context omitted.

The spec is more than just an OpenAPI scheme; it’s a strict wire format with shared semantics for a huge range of features.

Are you trying to say that REST APIs don't have a strict wire format with shared semantics for a huge range of features?

The wire format certainly isn’t strict

Re: Stateless MCP has recaptured my interest

#55

Post by hahahaa »

ai_critic wrote: post #50

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.

I had to double take and say "I coulda dun that!!"

Re: Stateless MCP has recaptured my interest

#57

Post by 9dev »

bloppe wrote: post #47
9dev wrote: post #36

Earlier quoted context omitted.

The spec is more than just an OpenAPI scheme; it’s a strict wire format with shared semantics for a huge range of features.

Are you trying to say that REST APIs don't have a strict wire format with shared semantics for a huge range of features?

Kind of--I'm saying that RESTful APIs are just an abstract vocabulary to describe state transfer operations, whereas MCP describes a concrete set of such operations. REST sits on top of the HTTP protocol layer, MCP sits on top of REST (if we accept how the meaning of REST has been butchered, but you know what I mean.)

This is easy to see when you think in terms of a client: It is pretty much impossible to build an opinionated UI for any kind of RESTful API, while creating one for an MCP server is fairly self-explanatory: MCP servers offer a mandatory and complete runtime introspection endpoint (you can retrieve a listing of available tools/resources/prompts etc. along with their parameter and return type schemas). So that means clients have a way to exhaustively describe everything an MCP server is able to do with a vocabulary that carries over exactly to other servers - a tool is a tool everywhere.

Re: Stateless MCP has recaptured my interest

#58

Post by panghy »

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

[flagged]

Re: Stateless MCP has recaptured my interest

#59

Post by hahahaa »

cheema33 wrote: post #48

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?

Yes run a side agent to evaluate if they are needed.

I am guessing keeping them all in every request is cache efficient though.

Re: Stateless MCP has recaptured my interest

#60

Post by chmod775 »

simonw wrote: post #51
drdexebtjl wrote: post #44

Earlier quoted context omitted.

They’re not the same thing under a different wire protocol! An MCP tool call that returns the top N spenders puts the result in the agent’s context window. A CLI tool call on the other hand… The agent can pipe their results into other completely unrelated CLI tools. It can write a loop that calls multiple tools. These things are not possible with MCP but are trivial with CLIs.

Anthropic proposed a way to programmatically chain MCPs together a while back, I'm not sure if it's been implemented much yet: https://www.anthropic.com/engineering/code-execution-with-mc...

I don't even need to read that to know they're re-inventing PowerShell now.

Edit: I read it. Yep.

We have text interfaces refined by humans for decades and there's an endless sea of training data for them, but they imagine these amateur-hour homegrown solutions will ever outdo an agent with shell access?

Post reply on HN