测验：危险工具

run_sql 도구를 지키려고 SQL 문자열이 SELECT 로 시작하는지 검사했다. 이 글이 연결 자체를 읽기 전용으로 여는 쪽을 택한 이유는?

• 문자열 검사는 파이썬에서 느려 초당 처리량이 크게 줄기 때문
• 문자열 검사는 따라가야 할 변형(문장 이어 붙이기·주석·WITH 로 시작하는 문장)이 끝없이 늘고, 놓친 하나가 사고이기 때문
• SELECT 로 시작하는 문장은 SQLite 가 실행을 거부하기 때문
• 읽기 전용 연결은 쓰기 문장을 조용히 무시해 오류 처리가 필요 없기 때문

허용 목록에 없는 도구를 tools/call 로 부르면 서버는 어떻게 답해야 하는가?

• 실행하되 감사 로그에 경고를 남긴다
• result.isError: true 로 '허용되지 않은 도구' 를 알린다
• 목록 밖 이름은 존재하지 않는 도구이므로 -32602 프로토콜 오류로 답한다
• tools/list 를 다시 보내라는 list_changed 알림으로 답한다

허용 목록 파일이 없거나 JSON 이 깨져 있을 때 안전한 기본 동작은?

• 아무 도구도 켜지 않는다
• 읽기 도구만 자동으로 켠다
• 정의된 도구를 전부 켜고 경고를 stderr 에 남긴다
• 서버 시작을 거부하고 종료 코드 1 로 끝낸다

delete_order 가 confirm 없이 불렸을 때 이 코스가 권하는 응답은?

• -32602 로 거절해 모델이 인자를 고치게 한다
• 지우지 않고, 지웠다면 무엇이 사라졌을지 담은 isError: true 텍스트를 돌려준다
• 조용히 지우고 감사 로그에 confirm 누락을 남긴다
• confirm 이 없어도 id 가 맞으면 지운다 — 스키마의 required 가 아니므로

도구 정의의 annotations(예: destructiveHint)에 대해 스펙이 클라이언트에 요구하는 태도는?

• 신뢰할 수 있는 서버가 아니면 믿지 않는다(MUST) — 표시용 힌트이지 안전장치가 아니다
• 힌트가 있는 도구는 확인 없이 실행해도 된다
• destructiveHint: false 인 도구는 감사 로그에서 제외한다
• 서버가 보낸 힌트를 그대로 사용자에게 강제 규칙으로 적용한다

확인 단계를 넣자 '에이전트가 매번 물어봐서 느리다' 는 불만이 나왔다. 이 글이 권하는 방향은?

• 확인을 빼고 대신 감사 로그를 더 자세히 남긴다
• 확인 창을 세션당 한 번만 띄우고 이후에는 자동 승인한다
• 도구를 더 좁혀(예: 테스트 주문의 상태 변경만) 확인이 필요 없을 만큼 안전하게 만든다
• 모델에게 '위험한 작업은 하지 말라' 는 시스템 프롬프트를 추가한다