Not sure whats the downside of this approach is but its serving us well so far.
Stateless MCP has recaptured my interest
61–70 of 247 posts
Re: Stateless MCP has recaptured my interest
#62It 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.
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
#63Re: Stateless MCP has recaptured my interest
#64Re: Stateless MCP has recaptured my interest
#65I 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.
Re: Stateless MCP has recaptured my interest
#66In 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…
Re: Stateless MCP has recaptured my interest
#67In 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…
Re: Stateless MCP has recaptured my interest
#68In 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…
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
#69Earlier 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…
There are multiple products that turn OpenAPI schemas into front-ends nowadays.
Re: Stateless MCP has recaptured my interest
#70In 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…