测验：MCP 规定的内容

MCP 서버가 id 없는 메시지(알림)를 받았을 때 스펙이 요구하는 동작은?

• 응답을 보내지 않는다 — 알림은 답을 기다리지 않는 한 방향 메시지다
• id: null 로 응답을 보내 받았음을 알린다
• -32600 Invalid Request 오류로 답해 잘못된 요청임을 알린다
• 다음 요청이 올 때 그 응답에 알림 처리 결과를 함께 싣는다

클라이언트가 initialize 에 서버가 지원하지 않는 프로토콜 버전을 보냈다. 서버의 올바른 응답은?

• 요청을 무시하고 initialized 알림을 기다린다
• 오류 없이 클라이언트가 보낸 버전을 그대로 돌려준다
• 자기가 지원하는 다른 버전(가능하면 최신)을 응답에 담아 돌려준다
• 연결을 즉시 끊어 클라이언트가 다시 시도하게 한다

tools/call 로 불린 도구가 외부 API 의 요청 한도 초과로 실패했다. 스펙이 권하는 답의 형태는?

• JSON-RPC error 에 -32603 Internal error 를 담는다
• result 안에 isError: true 와 실패 이유 텍스트를 담는다
• 응답을 보내지 않고 연결을 닫아 클라이언트가 재시도하게 한다
• tools/list 에서 그 도구를 빼는 list_changed 알림을 보낸다

stdio 전송에서 서버가 디버그 문장을 print() 로 stdout 에 찍으면 무슨 일이 생기는가?

• 클라이언트가 그 줄을 로그로 분류해 화면에 보여 준다
• 아무 일도 없다 — JSON 이 아닌 줄은 클라이언트가 자동으로 건너뛴다
• 서버가 다음 요청부터 stderr 로 강제 전환된다
• 유효한 MCP 메시지가 아닌 것이 stdout 에 나가 규정 위반이고, 클라이언트 파서가 깨질 수 있다

MCP 가 JSON-RPC 2.0 원문보다 더 엄격하게 정한 id 규칙은?

• id 는 반드시 정수여야 하고 문자열은 허용하지 않는다
• id 는 null 이면 안 되고, 한 세션 안에서 같은 값을 다시 쓰면 안 된다
• id 는 요청마다 1씩 증가하는 순번이어야 한다
• id 는 서버가 발급하고 클라이언트는 그것을 받아 쓴다

로컬에서 Streamable HTTP 로 MCP 서버를 띄울 때 스펙이 특히 요구하는 보안 조치는?

• Origin 헤더를 검증하고 127.0.0.1 에만 바인딩한다 — DNS 리바인딩을 막기 위해
• 모든 요청에 TLS 클라이언트 인증서를 요구한다
• 세션 ID 를 요청 본문에 넣어 URL 에 드러나지 않게 한다
• POST 대신 GET 만 허용해 상태 변경 요청을 원천 차단한다