MCP 읽기 전용 검수: readOnlyHint와 실제 동작 대조

MCP 읽기 전용 표기는 실제 변경·권한과 대조해야 합니다. 2026-10-30 기준, 힌트가 실행 차단이나 출력 신뢰를 보장하지는 않습니다.

업무 도구에 읽기 전용이라고 적혀 있으면 자동 허용 범위를 넓혀도 될까요? 표기와 구현이 맞는지, 그 결과를 받은 에이전트가 어디까지 이어서 실행하는지부터 확인해야 합니다. 이 글은 도구 정의를 실제 동작 증거와 연결하는 인수표를 제안합니다.

읽기 전용 검수는 어디서 시작하나요?#

검수 단위는 같은 도구 버전·입력·실행 주체·연결 경로입니다. 정의만 읽는 검토와 서버 권한 검사, 실제 호출 전후 비교를 나눠 기록하세요. 읽기와 실행의 구조를 먼저 정하려면 온톨로지 MCP의 조회·실행 경계를 함께 볼 수 있습니다.

도구를 제공하는 팀은 실제 변경 가능한 대상을 적고, 클라이언트 운영 팀은 힌트를 정책에 어떻게 쓰는지 확인합니다. 업무 책임자는 어떤 상태가 바뀌면 안 되는지와 허용된 다음 행동을 정합니다. 서로 다른 호스트·서버 조합을 같은 동작으로 가정하지 않습니다.

아래 예시와 인수표는 자사 설계 제안입니다. 특정 고객의 사고, MCP 제품 인증, 실제 공격·성능 시험 결과를 보고하는 글은 아닙니다.

도구 힌트는 무엇을 뜻하나요?#

힌트는 서버가 설명한 동작 특성입니다. MCP는 이 값이 실제 동작을 충실히 설명한다고 보장하지 않으며, 신뢰하지 않는 서버의 힌트에 근거해 도구 사용을 결정하지 않도록 명시합니다.

MCP ToolAnnotations 공식 스키마의 고정판은 2026-07-28, 확인일은 2026-10-30입니다. 아래 기본값은 필드 생략 때의 값입니다. 실제 파괴나 외부 전송이 발생했다는 관측 결과는 아닙니다.

표의 destructiveHint와 idempotentHint는 readOnlyHint=false일 때 의미가 있습니다. 모든 도구에 같은 판단식을 적용하지 말고 실제 동작에 맞는 필드를 읽으세요. 표는 공식 정의의 요약이며 특정 클라이언트의 자동 승인 규칙을 설명하지 않습니다.

정상 응답만 받으면 읽기 전용 검수가 끝나나요?#

정상 응답은 호출 결과 하나입니다. 원장·업무 상태·대기 작업·외부 발송 등 합의한 대상이 바뀌었는지는 호출 전후의 증거로 비교해야 합니다. 오류가 반환됐어도 도중에 변경이 생기는 경로를 별도로 확인합니다.

가상의 배송상태 조회 도구를 생각해 보겠습니다. 조회 권한만 허용된 주체로 호출하고, 상태 조회 외의 업무 변경과 외부 발송이 없다는 계약을 세웠다고 가정합니다. 다음 표는 그 계약을 확인할 시험 설계이며 실측 결과가 아닙니다.

감사 로그·캐시·요금처럼 부수적으로 보이는 영향도 목록에 남깁니다. 이를 readOnlyHint의 표준 예외라고 임의로 제외하지 않습니다. 표기가 설명하는 환경과 실제 동작이 어긋나면 구현·권한을 바꾸거나 도구 표기를 다시 정한 뒤 검수하세요.

출력 값 자체가 맞는지는 별도입니다. 한 응답 안의 JSON과 설명이 충돌하는 문제는 MCP 도구 결과 일치 검수에서 다룹니다. 여기서는 반환값의 모양보다 그 호출이 실제로 만든 영향을 대조합니다.

신뢰하는 서버의 힌트라면 통제를 줄여도 되나요?#

신뢰 관계가 있어도 힌트가 권한 통제를 실행해 주지는 않습니다. 서버 구현이나 연결 API가 바뀌면 표기와 실제 동작의 대응을 다시 확인해야 합니다. 클라이언트가 힌트를 무시하거나 다른 조건과 함께 사용하는 경우도 지원 제품·버전별로 확인합니다.

MCP 공식 블로그의 Tool Annotations as Risk Vocabulary는 2026-03-16에 발표됐습니다. 이 글은 힌트가 강제 통제나 모델의 프롬프트 인젝션 방어를 제공하지 않으며 도구 조합도 위험에 영향을 준다고 설명합니다. 당시의 제안 상태나 클라이언트 채택 상황을 오늘의 사실로 옮기지는 않습니다.

읽기 도구가 가져온 외부 문서에 후속 실행을 요구하는 문장이 있어도 사용자 승인으로 취급해서는 안 됩니다. 어떤 결과가 다음 호출로 전달됐는지와 그 호출의 대상·권한·허용 목적을 확인하세요. 이 제안은 악성 지시를 모두 탐지한다는 보장이 아닙니다.

MCP Tools 보안 조건은 서버의 입력 검증·접근통제·호출 제한·출력 정제를 의무로 둡니다. 민감 작업의 사용자 확인과 호출 전 입력 표시는 클라이언트 권고입니다. 프로토콜이 모든 도구에 동일한 승인 화면을 강제한다고 확대 해석하지 않습니다.

인수표에는 어떤 증거를 남기나요?#

표기·실제 동작·서버 권한을 같은 행에 연결합니다. 모델이 호출을 선택하지 않았다는 관찰만으로 서버가 변경을 막는다고 판정하지 마세요. 허용되지 않은 입력과 권한을 주었을 때 실행 계층이 어떤 결과를 내는지도 확인합니다.

이 표는 2026-10-30 작성한 자사 인수 제안이며 MCP 표준 시험표가 아닙니다. 격리된 비식별 자료와 가짜 외부 수신처로 범위를 정하고, 실고객 데이터 변경이나 실제 외부 발송을 시험 성공 조건으로 삼지 않습니다. 로그에는 비밀값 대신 비식별 실행 식별자와 필요한 판정 증거만 남깁니다.

오래된 정의가 보이는 문제는 MCP 목록 캐시와 현재 호출 인가를 별도로 확인하세요. 캐시 갱신, 힌트의 의미, 실제 서버 통제는 각각 실패할 수 있어 한 통과 표시로 묶지 않습니다.

알파카랩스와 무엇을 검수 범위로 정하나요?#

알파카랩스는 공개 업무 자동화 서비스에서 API·파일·화면 연동의 허용 범위, 권한·호출 제한·사용 요금, 실패와 재처리·수동 전환의 인수 조건을 협의한다고 설명합니다. 이는 회사의 제공 범위에 대한 자기표기이며 MCP 힌트 인증이나 특정 고객의 보안 성과를 뜻하지 않습니다.

기존 시스템의 허용된 접근 방식과 도구 정의를 함께 놓고 검수 대상을 좁힙니다. 비식별 정상·거부·반복 호출 표본과 실행 주체, 지원 호스트·서버 버전을 준비하면 인수표 초안을 협의할 수 있습니다. 비용·소요 시간과 운영 지원은 자료와 접근 조건을 확인한 뒤 정합니다.

이 글은 2026-07-28 고정판과 2026-10-30 확인한 공개 자료를 바탕으로 작성했습니다. 지원 클라이언트·서버의 동작이나 사양이 바뀌면 표기와 실제 동작의 대응부터 재확인합니다.

MCP 도구 힌트 검수에서 자주 묻는 질문은 무엇인가요?#

readOnlyHint가 true면 도구의 쓰기 권한도 막히나요?

힌트는 도구가 환경을 변경하지 않는다는 설명입니다. 서버 자격증명이나 실행 환경의 권한을 자동으로 줄이는 기능은 아닙니다. 실제 접근 권한과 정상·오류 경로의 변경 여부를 별도로 확인하세요.

destructiveHint가 false면 상태를 바꾸지 않나요?

readOnlyHint가 false인 도구에서 destructiveHint=false는 추가형 갱신을 뜻합니다. 자원을 만들거나 기록을 추가하는 작업도 변경에 해당합니다. 삭제가 없다는 이유로 비용·승인·정리 책임까지 제외하지 않습니다.

idempotentHint가 true면 실패할 때 계속 재시도해도 되나요?

이 힌트는 같은 인자로 반복 호출할 때 환경에 추가 영향이 없다는 뜻이며 readOnlyHint=false일 때 의미가 있습니다. 응답이 매번 같거나 무제한 재시도가 허용된다는 뜻은 아닙니다. 실제 중복 영향과 호출 제한·재시도 정책을 함께 확인하세요.

openWorldHint가 false면 반환 문서를 믿어도 되나요?

이 힌트는 도구가 상호작용하는 영역이 닫혀 있다는 설명입니다. 문서에 악성 지시가 없거나 내용이 정확하다는 인증은 아닙니다. 반환 데이터의 신뢰와 다음 도구 호출의 허용 범위는 별도로 검수합니다.

읽기 전용 도구에서 감사 로그가 생기면 바로 실패인가요?

로그가 있다는 사실만으로 통과나 실패를 정하지 않습니다. 원장·업무 상태와 로그·캐시·외부 요금 등 실제 영향을 빠짐없이 적고, 도구가 설명하는 환경의 범위와 정책을 대조합니다. 부수 동작을 임의의 표준 예외로 면제하지 말고 변경이 드러나면 표기와 권한 설계를 다시 검토하세요.