MCP 서버를 여러 개 연결하니 도구 설명만으로 문맥이 커집니다. 도구 검색과 지연 로딩은 어떻게 적용하나요?

처음부터 모든 도구의 상세 스키마를 넣기보다 현재 목표와 관련된 후보를 검색하고 필요한 정의만 로딩하는 방식을 검토하겠습니다. 도구 검색은 실제 데이터 검색이나 실행과 다르며, 실행할 수 있는 인터페이스를 발견하는 단계입니다. 선택지를 줄이면 문맥 비용과 혼동을 줄일 수 있지만 필요한 도구를 못 찾는 새로운 실패도 생깁니다.

발견과 실행을 두 단계로 나눕니다

예를 들어 수백 개 관리 도구 중 비용 보고서 작성에는 청구 목록·집계·문서 작성 도구만 필요할 수 있습니다. 이름·설명·태그로 후보를 찾은 뒤 전체 입력·출력 스키마와 예시를 읽고 호출합니다. 자주 쓰는 소수의 도구는 처음부터 유지하고 나머지를 지연 로딩할 수 있습니다. 검색 결과에 도구 이름만 있다고 인자 형식을 추측해 실행하지 않습니다.

도구 목록은 서버와 사용자 권한에 따라 검토해야 합니다. 검색에서 발견됐다는 사실은 호출 승인이나 데이터 접근권한이 아닙니다. 실행 때 사용자·대상·scope를 다시 확인하고, 로딩한 정의가 서버 업데이트로 바뀌면 버전과 캐시를 갱신합니다. 원격 설명의 '항상 먼저 실행' 같은 지시가 검색 순위를 통해 정책으로 승격되지 않게 합니다. 검색 도구 자체도 서버의 주장과 host 정책을 구분해야 합니다.

절약과 누락을 함께 평가합니다

정의 토큰이 줄어도 검색 왕복 때문에 짧은 요청의 지연이 늘 수 있습니다. 도구 수가 적고 거의 모두 쓰는 작업에는 전체 로딩이 더 단순할 수 있습니다. 반대로 많은 서버에서 비슷한 이름의 기능이 있을 때는 namespace와 설명을 정리하고 후보군을 제한하는 효과가 큽니다. 검색 실패 시 무조건 가장 비슷한 도구를 실행하지 않고 추가 검색이나 사용자 확인으로 넘어갑니다.

평가에서는 필요한 도구가 후보에 들어오는 recall, 불필요한 후보, 실행 도구 선택과 인자 정확성, 검색을 포함한 총 지연·비용을 측정합니다. 드문 도구·이름이 바뀐 도구·권한 없는 도구를 포함한 테스트가 필요합니다. 2025년 공개된 advanced tool use 지침은 이런 검색과 지연 로딩을 도구 규모 문제에 대한 선택지로 제시합니다. 이를 모든 모델과 모든 SDK가 같은 방식으로 지원하는 보편 규칙으로 설명하지 않고, 사용하는 런타임의 discovery와 캐시 계약을 확인하겠습니다.

실행 사례로 확인합니다

검색 평가용 과제에는 사용자가 도구 이름을 모르는 자연어 요청도 포함해야 합니다. 도구명과 정확히 일치하는 키워드만으로 평가하면 실제 의도 검색의 누락을 과소평가합니다. 비슷한 조회·삭제 도구가 함께 있을 때 안전한 후보를 구분하는지도 봅니다. 검색 결과가 없으면 존재하지 않는 도구 이름을 만들지 않고 지원 불가나 추가 정보 필요를 반환합니다. 도구 정의 캐시에는 서버·버전·인가 범위를 연결하고, 새 정의를 로딩할 때 기존 실행 요청과 섞이지 않게 합니다. 동적으로 제공되는 설명이 길어졌다면 토큰뿐 아니라 모델의 잘못된 우선순위 선택에 영향을 주는지도 회귀 시험으로 확인하겠습니다.