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

121–130 of 246 posts

Re: Stateless MCP has recaptured my interest

#121

Post by blitzar »

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.

It was a vibe protocol and with the hindsight glasses on it is obvious.

Someone should have said to the llm coming up with it -- "that sounds like an API with extra steps ... how about we keep these things (tool descriptions) and get rid of all this irrelevant - this will look good in my promotion meeting - overengineering (everything else)"

You are absolutely right is what it would have replied with.

Re: Stateless MCP has recaptured my interest

#123

Post by pjmlp »

ai_critic wrote: post #107
pjmlp wrote: post #97

Earlier quoted context omitted.

They also reinvented CORBA and DCOM, as MCP now supports gRPC as optional protocol. The reason is that these "folks getting paid several hundred thousand dollars a year" are mostly youngsters without any care to learn about computing history, which is why IT is a fashion industry. See HTMX as another example, that is basically ASP.NET Ajax or JSF Ajax.

If only they could ask for history lessons from an LLM! (To your point...having knocked out CORBA and DCOM, perhaps we may next look forward to SOAP.)

I always have to smile that the whole microservices, isn't much different from "The network is the computer", Taligent, CORBA/DCOM, WebServices, SOA,.... with iPaaS products being another go at BPEL.

Maybe Microsoft should bring back Biztalk for agentic workflows.

Re: Stateless MCP has recaptured my interest

#124

Post by progbits »

blitzar wrote: post #121
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.

It was a vibe protocol and with the hindsight glasses on it is obvious. Someone should have said to the llm coming up with it -- "that sounds like an API with extra steps ... how about we keep these things (tool descriptions) and get rid of all this irrelevant - this will look good in my promotion meeting - overengineering (everything else)" You are absolutely right is what it would have replied with.

What hindsight, this was obvious from day one.

Re: Stateless MCP has recaptured my interest

#125

Post by evalstate »

drdexebtjl wrote: post #16

In retrospect, stateful MCP was clearly wrong. This essentially makes MCP just another REST API endpoint, and lets you use the same infrastructure you already have set up for REST APIs (like load balancers, API gateways, progressive rollouts, etc).

There's a nice feature in the new version that lets you copy tool _arguments_ in to the HTTP Headers for custom routing etc.

Re: Stateless MCP has recaptured my interest

#126

Post by PetahNZ »

cheeze wrote: post #82
mmasu wrote: post #39

Earlier quoted context omitted.

In enterprise MCP allows users to access resources that could either be unsafe or impractical to consume via API or CLI. It is a powerful pattern, supported by virtually all clients (Cursor, Claude Code, Codex, whatever) and easily implemented in custom harnesses. If you don’t need it you don’t, but it has many useful applications. Stateless will make it a lot more practical to expand applications.

What is an example of something that is unsafe to consume via API or CLI? Isn't MCP _an API_?

Its more targeted? Sure I can allow an LLM to access CLI, but then it will try to pipe to other command, write scripts etc. MCP is simply request/response. Its not really that technically different, but the way you and LLMs interact with it allows for easier control. IMHO.

Re: Stateless MCP has recaptured my interest

#127

Post by progbits »

cheeze wrote: post #82
mmasu wrote: post #39

Earlier quoted context omitted.

In enterprise MCP allows users to access resources that could either be unsafe or impractical to consume via API or CLI. It is a powerful pattern, supported by virtually all clients (Cursor, Claude Code, Codex, whatever) and easily implemented in custom harnesses. If you don’t need it you don’t, but it has many useful applications. Stateless will make it a lot more practical to expand applications.

What is an example of something that is unsafe to consume via API or CLI? Isn't MCP _an API_?

It is.

MCP serves a single purpose: If you ask some company for API support for some stuff you can do via web UI but not API, they might say no for many reasons. But when you ask for MCP, suddenly you trigger AI FOMO and it will be available right away.

Re: Stateless MCP has recaptured my interest

#128

Post by Eldodi »

cheema33 wrote: post #103
Eldodi wrote: post #87

Earlier quoted context omitted.

MCP context bloat is a solved problem since at least February. Both OpenAI and Anthropic support Client-side MCP tool search, which makes MCP context loading as efficient as the Skills one (progressive discovery). Code mode is great but not needed anymore in 95% of use-cases.

I can turn off auto invocation of a skill. It uses zero tokens when in this mode. I can still invoke it by calling it by name. How can I do that with MCP servers?

you can actually invoke an MCP App by name in both Codex and Claude using the @ handle

Re: Stateless MCP has recaptured my interest

#129

Post by brabel »

sippeangelo wrote: post #115
Eldodi wrote: post #86

Earlier quoted context omitted.

- CLI tools don't have standardized auth, nor do they have granular tool permissions. MCP does - CLI tools need to access your secrets in your .env. With MCP the model never sees the secrets and refresh tokens. - CLI tools don't have auditing and telemetry. MCP provides all this for free. - CLI tools imply full bash access, a nightmare in terms of security and very costly if you have to spin up a machine for every re…

None of this is true. The point of "just CLI" is that LLMs are infinitely more trained on working CLI tools. There doesn't need to be real CLI tools behind the harness, as long as the interface is CLI-like.

Show me then how to convert my MCP, including auth, behind a CLI like interface. I don’t think that’s even possible.

Re: Stateless MCP has recaptured my interest

#130

Post by mhalle »

acchow wrote: post #13
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.

Skills can provide CLI tools for LLMs running on the web. It works great (I use Claude).
Post reply on HN