MCP 도구 목록 캐시: 권한 변경 뒤 옛 도구가 보일 때의 검수 기준

MCP 도구 목록 캐시는 현재 실행 권한을 보장하지 않습니다. 2026-10-29 기준, TTL·인가 컨텍스트·변경 신호를 따로 검수해야 합니다.

권한을 줄였는데 AI 화면에는 예전 도구가 남아 있다면 어디부터 확인해야 할까요? 서버가 반환한 목록, 중간 캐시, 모델에 전달된 정의, 실제 호출 결과를 구분해야 원인을 좁힐 수 있습니다. 캐시가 남았다는 사실만으로 실행 권한이 유지되거나 인가가 뚫렸다고 판정하지 않습니다.

새 서버의 전체 구조를 검토한다면 MCP 서버 구축 기준을 먼저 봅니다. 기존 연결에서 목록·권한 변경을 인수하려면 아래 캐시 경계와 실패 표본을 사용하세요. 표본은 가상 설계이며 특정 고객의 장애나 SDK 실측 결과가 아닙니다.

도구 목록에 보이는 것과 실행할 수 있는 것은 어떻게 다른가요?#

tools/list 결과는 클라이언트가 발견할 도구의 정의입니다. 실제 호출의 접근통제와 업무 변경 승인은 별도로 확인합니다. 캐시가 오래됐는지와 그 도구가 지금 허용되는지를 한 상태로 묶으면 원인과 책임을 혼동하기 쉽습니다.

MCP Tools 사양은 요청의 인가에 따라 목록이 달라지거나 비어 있을 수 있다고 설명합니다. Caching의 보안 조건은 캐시 범위와 별도로 각 기능의 접근통제를 요구합니다. 두 문서 모두 고정판 날짜는 2026-07-28, 확인일은 2026-10-29이며 독립 발표일은 표기돼 있지 않습니다.

읽기와 실행의 업무 경계는 온톨로지 MCP의 조회·실행 설계와 함께 정합니다. 이 글에서는 그 경계를 바꾼 뒤 캐시된 목록이 어떤 근거로 쓰이는지 검수합니다.

MCP 캐시는 누구의 어떤 요청에 재사용하나요?#

요청 메서드와 결과에 영향을 주는 인자, 캐시의 공유 범위를 확인합니다. private는 같은 인가 컨텍스트에만 재사용하며 다른 접근 토큰은 다른 캐시가 필요합니다. 사용자 이름이 같다는 사실만으로 같은 컨텍스트라고 판단하지 않습니다.

표의 근거는 공식 Caching의 키·공유 범위·TTL 정의입니다. 보호된 서버에서 왔다는 이유만으로 public 응답이 호출자별로 격리된다고 전제하지 않습니다. 계층별로 어느 응답을 누가 재사용하는지 확인해야 합니다.

인수 설계에서는 서버의 연결 대상과 클라이언트·게이트웨이의 캐시도 구분합니다. 원 토큰이나 비밀번호를 로그 키로 남기지 않고 비식별 컨텍스트 식별자를 쓰는 방식입니다. 식별자와 비교 항목은 아래의 설계 제안이며 MCP가 정한 추가 필수 필드는 아닙니다.

TTL이 남았는데 변경 알림이 오면 어떻게 하나요?#

관련 변경 알림은 아직 신선한 캐시도 즉시 오래된 상태로 만듭니다. TTL은 내용 불변의 보장이 아니며 자동 폴링 주기도 아닙니다. ttlMs가 0이면 즉시 stale로 보는 것이 권고되고, 필요할 때 다시 조회할 수 있습니다.

이 의미는 Caching의 TTL·알림 규칙에 따릅니다. Tools 사양의 listChanged 선언은 알림 지원을 나타내며, 해당 구독 스트림을 열고 toolsListChanged를 요청한 클라이언트가 알림을 받을 조건도 확인해야 합니다. 선언·전달·수신·무효화·새 정의 반영을 각각 관찰합니다.

알림을 못 받은 원인은 기능 미지원, 구독 미개방, 연결 중단, 수신 뒤 처리 누락 등으로 나눠 조사합니다. 사용하는 규격·SDK·호스트 버전을 먼저 고정하세요. 이 고정판의 캐시 규칙을 모든 기존 제품이 구현했다는 설명은 아닙니다.

캐시 변경을 인수하려면 어떤 기록이 필요하나요?#

서버가 준 정의와 캐시에서 꺼낸 정의, 현재 호출의 인가 판정을 이어서 비교할 수 있어야 합니다. 단순히 도구 이름이 같다는 기록만으로는 입력 정의나 허용 범위의 변화를 설명하기 어렵습니다. 아래는 운영 인수를 위한 설계 제안입니다.

정의 식별값은 합의한 정의를 구별하기 위한 내부 검수 항목입니다. 같은 원본 범위와 산출 방법을 쓰는지 확인해야 비교가 가능하며, 그 값 자체가 실행 권한의 증명은 아닙니다. 실제 기록 필드와 보관 범위는 AI 감사 로그의 추적 기준에 맞춰 정합니다.

재조회 오류 때 사양은 stale 응답의 제공을 허용합니다. 요청·private 컨텍스트의 경계를 지킨 안에서만 적용되는 허용입니다. 중요한 업무 변경은 최신 정의와 현재 인가·승인 조건을 확인하기 전 보류한다는 별도 정책을 합의할 수 있습니다. 이 보류 기준은 사양의 일괄 금지 조항이 아닌 설계 제안입니다.

정상 재사용과 변경 실패를 어떤 표본으로 가르나요?#

정상 재사용, 다른 인가 컨텍스트, 정의 변경, 재조회 실패를 같은 검수표에 넣습니다. 목록 화면의 변화와 실제 호출의 허용·거부는 별도 기대값으로 둡니다. 다음 표는 가상 입력이며 실제 캐시 엔진의 실행·성능 측정은 아닙니다.

캐시를 없애는 것만으로 호출 인가가 해결되지는 않습니다. 반대로 목록이 갱신됐어도 이전에 시작한 작업이 취소됐다는 뜻은 아닙니다. 이 검수는 도구 정의의 재사용과 변경 반영에 한정하며, 호출 결과의 구조·설명 차이는 MCP 도구 결과 일치 검수에서 따로 확인합니다.

시스템 연동 발주 때는 무엇을 함께 정하나요?#

버전과 캐시 계층, 인가 변경 경로, 업무 승인·보류 담당을 함께 정합니다. 기능 미지원과 구현 결함, 서버의 정상 거부를 구분할 기대값도 필요합니다. 고정된 TTL 하나로 모든 조직의 운영 조건을 대신할 수는 없습니다.

알파카랩스의 공개 업무 자동화 안내는 API 접근 조건·권한, 사람이 승인할 구간, 예외와 운영 인수 범위를 협의하도록 설명합니다. 이는 회사 자기표기이며 MCP 캐시 전용 제품이나 특정 SDK 기본 지원·고객 성과를 뜻하지 않습니다. 공개 안내는 2026-10-29 확인했고 게시일은 별도 표기돼 있지 않습니다.

비식별 도구 목록, 실제 캐시 경로, 서버·클라이언트 버전, 권한·정의 변경 전후의 기대값을 준비하세요. 검토 산출물은 캐시·인가 경계와 실패 표본을 담은 인수표 초안입니다. 비용과 소요 시간은 자료·권한·지원 버전·연동 범위 확인 후 협의합니다.

MCP 도구 목록 캐시에서 자주 묻는 질문은 무엇인가요?#

TTL이 남았으면 도구를 실행해도 되나요?

목록의 신선도와 현재 호출 인가는 별개입니다. 캐시된 정의를 표시하더라도 실제 호출에서는 현재 접근 조건을 확인해야 합니다. 오래된 목록만으로 중요한 업무 변경을 승인하지 않는 기준을 따로 합의하세요.

같은 직원이 로그인했다면 private 캐시를 재사용해도 되나요?

사용자 이름만으로 판단하지 않습니다. private 재사용의 기준은 같은 인가 컨텍스트이며 다른 접근 토큰은 다른 캐시가 필요합니다. 인수 기록에는 비밀값 대신 비식별 컨텍스트 식별자를 사용합니다.

listChanged를 켜면 목록이 즉시 갱신되나요?

서버의 알림 선언과 실제 구독·수신·캐시 무효화·재조회는 나눠 확인해야 합니다. 사용 중인 클라이언트가 해당 규격과 구독 방식을 지원하는지도 검수합니다. 설정 하나만 보고 모든 화면이 갱신됐다고 판정하지 않습니다.

재조회에 실패하면 오래된 목록을 보여주면 안 되나요?

사양은 재조회 오류 때 stale 응답의 제공을 허용합니다. 이것은 요청과 private 인가 컨텍스트의 재사용 경계를 없애는 예외가 아닙니다. 표시 허용 범위와 중요한 업무 변경의 보류 기준은 별도로 정합니다.

캐시를 모두 끄는 편이 안전한가요?

항상 다시 조회하도록 바꾸기 전에 캐시 계층과 변경 조건을 확인하세요. 정상적인 동일 조건 재사용과 권한·정의 변경 뒤의 처리를 구분하는 표본이 필요합니다. 캐시를 끄는 것만으로 실제 호출의 접근통제가 완성되지는 않습니다.