クイズ：監査・タイムアウト・スキーマ

count_orders 가 {"status": 5} 로 불렸다(스키마는 string). 이 글이 권하는 서버의 답은?

• 도구를 실행하고 0건이라고 답한다 — 숫자 상태는 없으니 결과가 0 이다
• result.isError: true 로 '상태는 문자열이어야 한다' 고 알린다
• 실행하지 않고 -32602 Invalid params 프로토콜 오류로 답한다
• 5 를 문자열 "5" 로 바꿔 실행한다

파이썬에서 integer 타입 검사를 isinstance(v, int) 만으로 하면 놓치는 값은?

• 1.0 같은 실수 — float 이 int 로 승격되어 통과한다
• "1" 같은 숫자 문자열 — 파싱 가능하면 int 로 취급된다
• None — 비어 있는 값은 어떤 타입 검사도 통과한다
• True·False — bool 이 int 의 하위 타입이라 통과한다

서버가 도구 실행 시간에 스스로 상한을 거는 가장 직접적인 이유는?

• 멈춘 도구 하나가 단일 스레드 서버 전체를 잡아 둔다
• 클라이언트가 타임아웃을 거는 것이 스펙에서 금지돼 있다
• 감사 로그의 duration_ms 를 항상 정수로 만들기 위해서다
• SIGALRM 이 없으면 파이썬 프로세스가 종료되지 않는다

notifications/message 로 보내는 로그 알림에 대한 설명으로 맞는 것은?

• 응답과 같은 id 를 붙여 어느 호출의 로그인지 짝을 맞춘다
• level 은 RFC 5424 의 여덟 수준 중 하나이고, 알림이라 id 가 없다
• stderr 로그를 대체하므로 stderr 에는 아무것도 쓰면 안 된다
• 서버가 logging 능력을 선언하지 않아도 보낼 수 있다

프로토콜 오류로 거절된 tools/call(예: 잘못된 인자)도 감사 로그에 남기라는 이유는?

• 감사 로그의 줄 수가 응답 수와 같아야 검사기가 통과하기 때문
• 잘못된 인자를 반복해 보내는 클라이언트 자체가 신호이기 때문
• 프로토콜 오류는 실행된 것으로 간주되어 과금 대상이기 때문
• JSON-RPC 스펙이 오류 응답의 기록을 요구하기 때문

도구별 타임아웃 값을 정하는 순서로 이 글이 권하는 것은?

• 처음부터 도구마다 예상 시간을 추측해 다른 값을 넣는다
• 타임아웃을 두지 않고 감사 로그만 보다가 문제가 생기면 넣는다
• 하나의 값으로 시작하고, 감사 로그의 duration_ms 분포를 보고 도구별로 나눈다
• 클라이언트의 타임아웃 값을 조회해 그것과 같게 맞춘다