Streaming 과 Resumability

Streamable HTTP 가 long-running 결과와 notification 을 SSE stream 으로 carry. SSE 는 디자인상 reconnect 에 강해: 각 event 가 optional id 필드, 끊긴 client 가 Last-Event-Id header 로 그 id 이후 모든 거 요청.

MCP 가 위에 명시적 resumability build: 지원하는 server 가 monotonically 증가하는 event id 발급, 최근 event 일정 window 메모리에 보관, reconnect 시 client 의 Last-Event-Id 이후 모든 거 re-emit. Client 시점에선 네트워크 hiccup 이 — 잃은 결과 대신 — 짧은 stall 로 보임.

Resumability 가 — 불안정 네트워크에서 long-running tool 살아남는 방법. 없으면 progress notification stream 하는 10 분 build 가 — client wifi 가 7 분에 끊기면 — 10 분 잃은 connection. 있으면 client 가 7 분 반에 reconnect 해서 missed event + 결국 completion 받음.

비용은 server 가 들고 있어야 하는 buffer. 대부분 production server 가 buffer cap 5,000 event 또는 5 분 정도 — 평범한 reconnect 엔 충분, memory leak 안 일으킴. Buffer eviction policy 와 limit 은 client 가 control 못 하는 server 선택; client 는 — 너무 오래 reconnect 안 했으면 — fresh-start 신호 받을 준비 해야.

Code

Last-Event-Id 로 reconnect·text

GET /mcp HTTP/1.1
Mcp-Session-Id: sess_abc123
Accept: text/event-stream
Last-Event-Id: 0042

HTTP/1.1 200 OK
Content-Type: text/event-stream

id: 0043
data: {"jsonrpc":"2.0","method":"notifications/progress","params":{...}}

id: 0044
data: {"jsonrpc":"2.0","id":7,"result":{...}}

Server 쪽: resumable id emit·python

# Pseudocode — 실제 SDK 가 resumability 켜져 있을 때 자동 처리
event_id = next_event_id()
sse.send(id=event_id, data=json.dumps(message))
buffer.append((event_id, message))
buffer.evict_older_than(now() - 300)  # 5 분 window

Code

External links

Exercise

Progress

댓글 0