4 ms·

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

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

pjmlp 2mo ago
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.
- shermantanktop 2mo ago
  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.
  - tibbe 2mo ago
    You didn't provide any arguments to support your claim. Calling people names isn't going to convince anyone.
    - shermantanktop 2mo ago
      Okay, here’s one I’m working through. When the workload consists of compound elements in multiple domains, agents work best when they see that as a flat surface of detailed resources. Traditional APIs work best when they hide the implementation details behind an ergonomic api. So service API developers want to abstract and hide, over and over, and this means agents have less and less context and do more guessing.
  - wongarsu 2mo ago
    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?
    - sumitkumar 2mo ago
      With human devs, errors become recovery instructions. 400 Bad Request is fine for a client developer who reads it once at design time and fixes the code forever. it's dead weight for an agent that must self-correct from the string alone. "Expected ISO-8601, got 03/04/2025" is now a functional part of the interface. Not all agents are developers who can code their own interface.
  - jappgar 2mo ago
    And agentic enthusiasts apparently believe agents can do anything except REST.
deleted 2mo ago
[deleted]
bloppe 2mo ago
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 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.
- 9dev 2mo ago
  The spec is more than just an OpenAPI scheme; it’s a strict wire format with shared semantics for a huge range of features.
  - bloppe 2mo ago
    Are you trying to say that REST APIs don't have a strict wire format with shared semantics for a huge range of features?
    - dymk 2mo ago
      The wire format certainly isn’t strict
    - 9dev 2mo ago
      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 opinionated UI for any kind of RESTful API, while creating one for an MCP server is fairly self-explanatory: MCP servers offer a mandatory and complete runtime introspection endpoint (you can retrieve a listing of available tools/resources/prompts etc. along with their parameter and return type schemas). So that means clients have a way to exhaustively describe everything an MCP server is able to do with a vocabulary that carries over exactly to other servers - a tool is a tool everywhere.
zeafoamrun 2mo ago
I came here to ask why it was ever stateful?
- robgibbons 2mo ago
  During the initialize step, the client tells the server about its capabilities. Then the server remembers them for the session, so the client doesn't need to keep saying what it can do, and the server won't expose tools the client can't use. It's more overhead for the server, but more efficient over the wire for the rest of the session (that's just my understanding at least -- not saying this couldn't all be stateless).
- tumetab1 2mo ago
  If you connect the dots of the earlier MCP Client/Server docs you understand that your desktop AI tool was also a MCP Server. This MCP Server provided the tools like "search files", "alter files", "open file". It's was simpler to design/implement the AI tool if these interactions had state. When this was generalized to internet interactions this no longer made sense and was gradually cleaned up. I think at the same time, the AI tool "protocol" to interact with the local system moved away from MCP model.
evalstate 2mo ago
There's a nice feature in the new version that lets you copy tool _arguments_ in to the HTTP Headers for custom routing etc.

pjmlp 2mo ago

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.

shermantanktop 2mo ago
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.
- tibbe 2mo ago
  You didn't provide any arguments to support your claim. Calling people names isn't going to convince anyone.
  - shermantanktop 2mo ago
    Okay, here’s one I’m working through. When the workload consists of compound elements in multiple domains, agents work best when they see that as a flat surface of detailed resources. Traditional APIs work best when they hide the implementation details behind an ergonomic api. So service API developers want to abstract and hide, over and over, and this means agents have less and less context and do more guessing.
- wongarsu 2mo ago
  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?
  - sumitkumar 2mo ago
    With human devs, errors become recovery instructions. 400 Bad Request is fine for a client developer who reads it once at design time and fixes the code forever. it's dead weight for an agent that must self-correct from the string alone. "Expected ISO-8601, got 03/04/2025" is now a functional part of the interface. Not all agents are developers who can code their own interface.
- jappgar 2mo ago
  And agentic enthusiasts apparently believe agents can do anything except REST.

deleted 2mo ago

[deleted]

bloppe 2mo ago

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

9dev 2mo ago
The spec is more than just an OpenAPI scheme; it’s a strict wire format with shared semantics for a huge range of features.
- bloppe 2mo ago
  Are you trying to say that REST APIs don't have a strict wire format with shared semantics for a huge range of features?
  - dymk 2mo ago
    The wire format certainly isn’t strict
  - 9dev 2mo ago
    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 opinionated UI for any kind of RESTful API, while creating one for an MCP server is fairly self-explanatory: MCP servers offer a mandatory and complete runtime introspection endpoint (you can retrieve a listing of available tools/resources/prompts etc. along with their parameter and return type schemas). So that means clients have a way to exhaustively describe everything an MCP server is able to do with a vocabulary that carries over exactly to other servers - a tool is a tool everywhere.

zeafoamrun 2mo ago

I came here to ask why it was ever stateful?

robgibbons 2mo ago
During the initialize step, the client tells the server about its capabilities. Then the server remembers them for the session, so the client doesn't need to keep saying what it can do, and the server won't expose tools the client can't use. It's more overhead for the server, but more efficient over the wire for the rest of the session (that's just my understanding at least -- not saying this couldn't all be stateless).
tumetab1 2mo ago
If you connect the dots of the earlier MCP Client/Server docs you understand that your desktop AI tool was also a MCP Server. This MCP Server provided the tools like "search files", "alter files", "open file". It's was simpler to design/implement the AI tool if these interactions had state. When this was generalized to internet interactions this no longer made sense and was gradually cleaned up. I think at the same time, the AI tool "protocol" to interact with the local system moved away from MCP model.

evalstate 2mo ago

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