Live data from Hacker News

Stateless MCP has recaptured my interest

simonwillison.net

61–70 of 247 posts

Re: Stateless MCP has recaptured my interest

#61
In our startup, we build harness that allows people to call endpoints like the ones that MCP supports. we looked it as 2 class of problems. One is sources like databases where the protocol is not http/json/rpc. Here we support MCP based calling. then there are ones where the protocol is just http/json/rpc - say calling shopify or linear or others. Now the harness itself comes with a generic http execution engine. So if you know the endpoint, auth and operation - the harness converts this into a yaml structure for internal purpose and directly calls the endpoint. all info that LLM needs like how the endpoints are, what can be passed and how to check response etc., is all english defined and stored in yaml. Now the harness uses this info to expose these to LLM and when LLM wants to makes a tool call that needs to call the http endpoint the http engine in the harness executes it on behalf of it and gives response back to LLM. this way every server dont have to expose and maintain an MCP server to expose them to LLM. allow us to connect to any endpoint and teams dont have to maintain and scale one more info.

Not sure whats the downside of this approach is but its serving us well so far.

Re: Stateless MCP has recaptured my interest

#62

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 wonder if part of it was the bias of how the chat apps work with the streaming maybe they use SSE

But I wouldn't discount how uphill it was to probably even argue for something like MCP cause the labs still very scientist-driven and focused on solving everything in token space. The idea that tool use could be super transformative probably wasn't obvious from inside before Claude Code

Re: Stateless MCP has recaptured my interest

#64
Hi Simon and HN checkout https://rmcp.dev - it's part of BuiltWith's MCP discovery and lets you sniff around all of the MCP servers (remote at least) that we've discovered - allowing you to connect to them etc. and see what they do. Thought it might be relevant vis your mcp-explorer.

Re: Stateless MCP has recaptured my interest

#65

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.

Well for a non-coding (no CLI tooling) flow it means you don't need a sandbox and it provides a plugin architecture.

Re: Stateless MCP has recaptured my interest

#66
post #61

In our startup, we build harness that allows people to call endpoints like the ones that MCP supports. we looked it as 2 class of problems. One is sources like databases where the protocol is not http/json/rpc. Here we support MCP based calling. then there are ones where the protocol is just http/json/rpc - say calling shopify or linear or others. Now the harness itself comes with a generic http execution engine. So…

can postgREST be helpful for this? Clickhouse also has an http endpoint to send queries

Re: Stateless MCP has recaptured my interest

#67
post #61

In our startup, we build harness that allows people to call endpoints like the ones that MCP supports. we looked it as 2 class of problems. One is sources like databases where the protocol is not http/json/rpc. Here we support MCP based calling. then there are ones where the protocol is just http/json/rpc - say calling shopify or linear or others. Now the harness itself comes with a generic http execution engine. So…

[deleted]

Re: Stateless MCP has recaptured my interest

#68
post #32

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

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 endpoint expose a single URL that the model can take, auth, understand, and use.

I maintain https://endara.ai and you can very quickly introduce a ton of capabilities for Claude/Cursor/ChatGPT by configuring all the stuff you use in a single place (and slicing them with profiles if needed).

Re: Stateless MCP has recaptured my interest

#69
post #57
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…

I think OpenAPI does all you mentioned in your comment too. Maybe MCP is more strict, in the sense that it requires natural-language descriptions, which are optional in OpenAPI, but I don’t see the distinction.

There are multiple products that turn OpenAPI schemas into front-ends nowadays.

Re: Stateless MCP has recaptured my interest

#70
post #61

In our startup, we build harness that allows people to call endpoints like the ones that MCP supports. we looked it as 2 class of problems. One is sources like databases where the protocol is not http/json/rpc. Here we support MCP based calling. then there are ones where the protocol is just http/json/rpc - say calling shopify or linear or others. Now the harness itself comes with a generic http execution engine. So…

we havent done postgres as endppoint. we were worried abt performance but may be we will consider. this also avoid the problem of running curl in shell (no shell access is given) and validations are done before its being sent - like call parameters, check for injections with standard libraries etc., so we dont have to worry abt the quality of existing MCP servers.
Post reply on HN