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).
Stateless MCP has recaptured my interest
31–40 of 247 posts
Re: Stateless MCP has recaptured my interest
#32In 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).
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 particular sites. Regardless, there's always service-level authz with service accounts, at least for the more sophisticated APIs.
So ya, I don't see why we need a whole new set of standards and protocols just to have harness-level fine-grained API permissions. We could have just done it all with REST.
Re: Stateless MCP has recaptured my interest
#33Re: Stateless MCP has recaptured my interest
#34Earlier quoted context omitted.
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…
I guess if the agent is strongly trained to reach for the container then maybe But let’s take my MCP clock for example if you ask ChatGPT what’s the time in Tokyo it’s not even gonna think of booting up the code interpreter. It’s gonna just do web search and give you the wrong time (I just tried it and there may be an OpenAI built in widget it pops up now—but again that’s a specific tool call with an iframe output no…
The point is that even web search should be a CLI tool, and all ChatGPT would know to do other than talk to you is how interact with a shell.
Then if you ask it what’s the time in Tokyo, it would likely reach for the POSIX date command, instead of web search, because both would be equally visible.
Re: Stateless MCP has recaptured my interest
#35In 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).
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.
It’s not true. It’s not totally untrue, but don’t hide your head in the sand.
Re: Stateless MCP has recaptured my interest
#36In 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…
Re: Stateless MCP has recaptured my interest
#37Re: Stateless MCP has recaptured my interest
#38Earlier 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.
Re: Stateless MCP has recaptured my interest
#39I 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
#40I 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.