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

81–90 of 246 posts

Re: Stateless MCP has recaptured my interest

#81

Post by alooPotato »

panghy wrote: post #68
bloppe wrote: post #32

Earlier quoted context omitted.

MCP is basically just: 1. a REST-like API 2. with a spec (OpenAPI, introspection, etc.) 3. with harness-level authz (the ability to allow / deny specific methods in the harness) The only part that's actually new is #3, but it seems like it should be fairly easy to provide similar support for REST APIs. There might already be a Pi extension that allows you to allow / deny particular method / path patterns for particul…

Honestly MCP is geared mainly for the non-technical folks who don't understand a thing about REST or OpenAPI (otherwise, of course folks can just ask models to search/parse/code/parse and get things done -- don't need to ask for an MCP endpoint at all). Models also do a lot better with tool calls than asking them to string together instrospection, web-search, curl, etc. (that's a lot of tokens) rather than having the…

The user experience for a rest api and for mcp can be the same. For MCP, you have to give the mcp server url. For REST, you could provide a url to the openapi spec. The open API spec has everything you'd need - oauth url + all the endpoints and params.

Most chat products will just have a directory of connectors anyways - so for non technical folks they won't even here the term MCP or REST, they'll just "Install the Gmail plugin".

Re: Stateless MCP has recaptured my interest

#82

Post by cheeze »

mmasu wrote: post #39
Foobar8568 wrote: post #37

I still don't get MCP. Most likely because I didn't really check but the first feeling is creating a problem to solve a problem that doesn't exist in the first place.

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_?

Re: Stateless MCP has recaptured my interest

#83

Post by zeafoamrun »

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

I came here to ask why it was ever stateful?

Re: Stateless MCP has recaptured my interest

#84

Post by wongarsu »

shermantanktop wrote: post #35
pjmlp wrote: post #28

Earlier quoted context omitted.

Something that anyone doing distributed systems knows after a few scars, stateless servers are always better, and stateful only if there is no way around it. I learnt this with Sun RPC and the whole "The network is the computer". Somehow this keeps having to be relearnt.

I keep encountering mistakes by people who are convinced that agentic interactions are nothing new, that all the decades of hard-won lessons about service API design are 100% relevant and nothing more is needed, that agents can be relegated to the role of just-another-caller and left to the dismal domain of client developers. It’s not true. It’s not totally untrue, but don’t hide your head in the sand.

If agents are "like humans" (whatever we mean by that), then shouldn't all the lessons we learned over the decades on how to build APIs for direct and indirect human consumption be extremely relevant?

Re: Stateless MCP has recaptured my interest

#85

Post by bloppe »

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

Earlier quoted context omitted.

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

See my point #2. There are already standards to describe APIs.

This is easy to see when you think in terms of a developer. The natural way to adapt an existing REST API into an MCP server while keeping the two synchronized is to simply write a basic translation tool that takes your OpenAPI spec and turns it into an MCP manifest, mapping each HTTP endpoint to an MCP method, and copying over all the request / response type signatures and descriptions for everything. Then, all of the sudden, it hits you: there is no need for this translation layer.

Re: Stateless MCP has recaptured my interest

#86

Post by Eldodi »

drdexebtjl wrote: post #22
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 don’t think the “just use a CLI” crowd really are assuming you’re a developer in a coding harness. All of those use cases you mentioned benefit from the agent having access to a temporary virtual machine with a set of standard CLI tools and the ability to write and execute arbitrary code. Most already do. ChatGPT has been running Python in the cloud to answer questions before we even had functional coding harnesses…

- 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 request for billions of users.

- etc

Re: Stateless MCP has recaptured my interest

#87

Post by Eldodi »

rutierut wrote: post #78

In this thread I’m seeing a couple of the typical skill arguments. Skills don’t pollute the context window and, skills are more flexible and composable. In this specific post the SQL example gets around this by being super low-level, inherently composable, and low context consumption itself. I’m not sure this works for everyone. Looking at the Linear MCP for example, they basically just want to expose an API surface…

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.

Re: Stateless MCP has recaptured my interest

#88

Post by bloppe »

speedgoose wrote: post #73
bloppe wrote: post #47

Earlier quoted context omitted.

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

Isn’t that the case? Aren’t REST people still debating about what makes a true beautiful REST API?

When I say REST, I basically mean HTTP/JSON. I know. Shame on me.

But there's a pretty large body of RFCs that define what makes a good REST API. For instance POST should create things, PUT should re-define them, PATCH should incrementally update them, GET must be side-effect-free, etc. And there's a ton of standard HTTP headers. Pair it with OpenAPI and the whole thing is self-documenting. You can achieve the same effect with gRPC + reflection, or GraphQL + reflection, and there's plenty of mature tooling and interoperability for each system.

By comparison, MCP actually has relatively few conventions. LLMs are very familiar with REST and OpenAPI already. Just use that.

Re: Stateless MCP has recaptured my interest

#89

Post by troupo »

rutierut wrote: post #78

In this thread I’m seeing a couple of the typical skill arguments. Skills don’t pollute the context window and, skills are more flexible and composable. In this specific post the SQL example gets around this by being super low-level, inherently composable, and low context consumption itself. I’m not sure this works for everyone. Looking at the Linear MCP for example, they basically just want to expose an API surface…

> Skills don’t pollute the context window

Of course they do. Do you really think that there's a magical bag of holding for the potentially infinite amount of skills?

Re: Stateless MCP has recaptured my interest

#90

Post by DarkNova6 »

mmasu wrote: post #39
Foobar8568 wrote: post #37

I still don't get MCP. Most likely because I didn't really check but the first feeling is creating a problem to solve a problem that doesn't exist in the first place.

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.

I don't get it. I thought the advantage is that you have a client as a library with integrated auth & other tech stuff handled so you can just focus on using the API? Because otherwise you could just use REST with basic endpoint code.
Post reply on HN