Streamable HTTP 는 stateful server 도 stateless server 도 다 받아줘. Protocol 이 대신 골라주지 않아 — 설계할 때 네가 정하고, Mcp-Session-Id header 로 그 결정을 알리는 거야.
Stateful server 는 initialize 때 session id 를 발급해서 Mcp-Session-Id 로 돌려줘. 이후 요청은 그 id 를 header 에 실어 보내고, server 는 id 로 session 별 상태를 찾아 — 열려 있는 구독, 페이지를 넘기던 cursor, 아직 돌고 있는 긴 작업 같은 것들. 정리도 명시적이야. Client 가 다 쓰면 session id 를 담아 endpoint 에 HTTP DELETE 를 보내고, server 가 상태를 치워.
Stateless server 는 session id 를 아예 안 줘. 모든 요청이 서로 독립이고, 호출 하나에 필요한 일을 그 자리에서 하고 버려. 그래서 부하 분산기 뒤의 어느 노드가 어느 요청을 받아도 되고, 조율 없이 옆으로 늘릴 수 있어. 대신 구독도, 호출 사이를 잇는 cursor 페이지 넘기기도, '이 client 한테 마지막으로 뭐라고 했더라' 를 기억하는 기능도 못 줘.
선택은 결국 운영 문제야. Stateful 이 짜기는 쉬운데 늘리기가 어려워 (같은 곳으로 붙여주는 라우팅이나 공유 저장소가 필요하거든). Stateless 는 늘리기 쉬운데, 상태를 요청 안으로 밀어 넣어야 해 (cursor 를 불투명한 token 으로 만든다든지). 실제 production 배포는 대체로 stateless 로 가면서 Redis 같은 데 공유 상태를 두는 쪽으로 정착해. Stateless 의 단순한 배관과 stateful 의 표현력을 같이 가져가는 거지.