JSON-RPC 2.0 — The Wire · Protocol Quest

MCP 메시지 밑에 깔린 건 전부 JSON-RPC 2.0 이야. Spec 이 짧아 — 열 쪽도 안 돼 — 한 번 읽어둘 값을 해. MCP 의 framing 에서 별나 보이는 것들이 전부 여기서 나오거든.

JSON-RPC 메시지는 세 종류야. Request 에는 method 와 params, 그리고 고유한 id 가 있고, 받는 쪽은 같은 id 로 result 나 error 를 반드시 돌려줘야 해. Notification 은 모양은 같은데 id 가 없고, 받는 쪽은 답하면 안 돼. Response 에는 result 아니면 error 가 들어가. 둘을 같이 넣는 건 없어.

에러도 어엿한 일급 시민이야. JSON-RPC 에러에는 숫자 code, 짧은 message, 그리고 있어도 되고 없어도 되는 data 가 붙어. 표준 코드는 이래. -32700 Parse error, -32600 Invalid request, -32601 Method not found, -32602 Invalid params, -32603 Internal error, 그리고 -32099 부터 -32000 까지는 각 protocol 이 알아서 쓰라고 열어둔 자리야. MCP 는 그 마지막 구간에 자기 뜻을 얹었어.

MCP server 를 처음 짜는 사람이 잘 걸려 넘어지는 건 batch 와 동시성 이야. JSON-RPC 는 request 를 배열로 묶어 보내는 것도, 같은 연결에서 응답이 순서를 어겨 돌아오는 것도 허용해. MCP transport 마다 batch 를 얼마나 엄격하게 다루는지는 제각각이고. 안전한 규칙은 이거야. 지금 쓰는 transport 가 요청을 한 줄로 세워준다 해도, server 는 요청이 겹쳐 들어오고 응답이 순서를 어겨 나가는 상황을 감당할 수 있게 짜.

Code

JSON-RPC 메시지 모양 셋·json

// Request — id 있음; 받는 쪽 답 MUST
{"jsonrpc":"2.0","id":42,"method":"tools/call","params":{"name":"get_weather","arguments":{"location":"Seoul"}}}

// Notification — id 없음; 받는 쪽 답 MUST NOT
{"jsonrpc":"2.0","method":"notifications/cancelled","params":{"requestId":42}}

// Response (성공)
{"jsonrpc":"2.0","id":42,"result":{"content":[{"type":"text","text":"68°F"}]}}

// Response (에러)
{"jsonrpc":"2.0","id":42,"error":{"code":-32602,"message":"Invalid params","data":{"missing":["location"]}}}

볼 수 있는 표준 JSON-RPC 에러 코드·text

-32700  Parse error           — server 가 malformed JSON 받음
-32600  Invalid request       — 메시지가 JSON-RPC 모양 아님
-32601  Method not found      — server 가 모르는 method 호출
-32602  Invalid params        — params 모양/타입 틀림
-32603  Internal error        — 일반 server 실패
-32099 .. -32000              — protocol-specific (MCP 가 자기 의미 정의)

JSON-RPC 2.0 — The Wire

Code

External links

Exercise

Progress

댓글 0