MCP 도구 설명이 에이전트 툴 선택 정확도를 좌우하는 방식

MCP 도구 설명의 결함을 코드 스멜에 준하는 문제로 분류한 연구가 arXiv에 공개됐다. 연구는 103개 서버의 856개 도구를 분석했고, 97.1%에서 최소 하나의 설명 스멜을 발견했다. 도구의 목적을 명확히 설명하지 못한 비율도 56%였다.

논문 「Model Context Protocol (MCP) Tool Descriptions Are Smelly! Towards Improving AI Agent Efficiency with Augmented MCP Tool Descriptions」는 문헌에서 도구 설명의 6개 구성 요소를 추출하고, 이를 점수 루브릭과 설명 스멜로 체계화했다. 도구가 수십~수백 개 등록된 환경에서 모델은 설명 텍스트를 근거로 호출 대상을 고른다. 이 때문에 도구 설명은 프롬프트 엔지니어링의 부속 작업이 아니라 별도 설계 대상으로 볼 필요가 있다.

설명문은 모델이 소비하는 인터페이스다

도구 스키마는 도구 이름, 설명, 입력 스키마, 출력 스키마, 오류 규약으로 구성된다. 입력 스키마에는 파라미터별 타입·제약·필수 여부가 포함된다.

이름은 선택 과정의 첫 필터다. 유사한 이름이 다수 존재하면 설명이 좋아도 오선택이 늘어날 수 있다. 서버 또는 도메인 접두 규칙으로 이름 공간을 나누는 일이 기본이 된다.

설명문에는 적어도 다음 맥락이 들어가야 한다.

목적: 무엇을 하는 도구인가
사용 시점: 어떤 상황에서 선택하는가
사용 금지 조건: 어떤 경우에는 다른 도구를 써야 하는가
파라미터 의미와 제약
반환 형태
부작용·비용·멱등성

연구에서 가장 두드러진 결함은 목적의 부재였다. 따라서 첫 문장에서 도구의 목적을 단정적으로 밝히는 규칙이 효과적이다. 특히 비슷한 도구가 함께 노출되는 환경에서는 when not to use에 해당하는 부정 조건이 오선택을 줄이는 기준이 된다.

파라미터의 허용 값 집합, 날짜·ID 패턴 같은 형식, 범위, 단위, 기본값, 상호 배타 관계도 설명에 적어야 한다. 제약이 스키마에만 있고 설명에는 없으면 모델이 값을 추측해 호출 실패를 반복할 수 있고, 재시도가 실행 단계 수를 늘린다.

등록 전 진단과 평가를 연결하는 흐름

기존 설명을 수집한 뒤 루브릭으로 스멜을 진단하고, 누락된 구성 요소를 보강한 뒤 툴 선택 평가셋으로 검증해 등록한다. 다만 증강된 설명은 토큰을 더 사용한다. 수백 개 도구의 설명이 한 컨텍스트에 들어가면 전체 설명량이 컨텍스트 예산을 잠식하므로, 증강 깊이와 노출 도구 수를 함께 조정해야 한다.

⤢✕

평가셋은 질의와 정답 도구, 그리고 허용 가능한 대안의 쌍으로 만든다. 실제 오선택 사례를 계속 축적하는 방식이 가장 효율적이다. 로그에는 질의, 노출된 도구 목록, 선택된 도구, 성공 여부, 재시도 횟수를 남긴다. 오선택이 반복되는 도구 쌍을 찾아 설명을 국소적으로 수정할 수 있다.

카탈로그 자체를 줄이는 전략도 필요하다. 역할별로 도구 집합을 분리하는 정적 선별, 질의 기반 검색 후 상위 소수만 노출하는 동적 선별, 범주 선택 뒤 도구를 고르는 계층화가 가능하다. 도구 수를 줄이는 편이 설명 개선보다 낮은 비용으로 정확도를 높이는 경우도 많다.

운영 기준은 코드 변경처럼 다뤄야 한다

사내 표준은 목적 한 문장 → 사용 시점 → 사용 금지 조건 → 파라미터 제약 → 반환 형태 → 부작용·비용의 순서로 고정할 수 있다. 도구 구현자가 초안을 작성하되, 선택 맥락을 아는 에이전트 운영 담당이 검토하는 역할 분리가 맞는다.

검토 시에는 목적이 첫 문장에 단정문으로 나타나는지, 유사 도구와의 구분 기준이 있는지, 사용하지 말아야 할 경우가 적혀 있는지를 확인한다. 허용 값·형식·단위가 스키마에만 머물지 않는지, 부작용·비용·멱등성이 표기됐는지도 점검 대상이다. 내부 함수명이나 테이블명 같은 구현 세부를 설명에 노출하는 일은 피한다.

변경된 설명은 코드 변경과 같이 취급해야 한다. 설명을 고치면 툴 선택 평가셋을 다시 실행하고, 모델을 교체할 때도 재평가한다. 설명의 효과는 모델 세대에 의존하기 때문이다. 설명은 형상 항목으로 관리하고 변경 이력을 남겨야 오선택의 원인을 추적할 수 있다.

외부 MCP 서버를 채택할 때도 설명 품질을 평가 항목에 포함할 필요가 있다. 97.1%가 스멜을 포함했다는 결과는 외부 서버의 설명을 그대로 신뢰하기 어렵다는 신호다.

정확도 개선에는 비용이 따른다

구분	증강 설명	최소 설명
툴 선택 정확도	높음(성공률 중위 +5.85%p)	낮음
부분 목표 달성	개선(+15.12%)	기준선
실행 단계 수	증가	적음
토큰 비용	설명 길이만큼 증가	낮음
유지 부담	변경 시 갱신 필요	낮음
대규모 카탈로그 적합성	컨텍스트 잠식	유리

설명을 증강하면 성공률과 부분 목표 달성도는 개선되지만, 실행 단계 수와 토큰 비용도 증가한다. 결제나 변경 작업처럼 정확도가 실패 비용을 좌우하는 업무에서는 증강 설명이 유리하다. 반대로 단계 수와 지연이 핵심인 대량 처리에서는 증강 깊이를 제한하는 편이 낫다. 도구 수가 적고 이름만으로 구분이 뚜렷하다면 최소 설명도 가능하다.

모든 도구를 한꺼번에 노출하는 방식은 단순하지만, 유사 도구 간 오선택과 컨텍스트 잠식이 발생한다. 선별 노출은 정확도와 예산 관리에 도움이 되지만 검색 단계가 추가되고 검색 자체도 오류원이 된다. 도구 수가 노출 상한의 두 배를 넘는 시점부터는 선별 노출의 이점이 검색 오버헤드를 상회하는 것이 일반적이다.

반복적으로 혼동되는 특정 도구 쌍이 오선택 로그에 나타난다면, 이는 모델 능력보다 설명 문제일 수 있다. 상위 티어 모델로 교체하면 오선택을 줄일 수 있지만 호출 단가는 배수로 증가하고 설명 결함은 남는다. 설명 개선은 일회성 공수로 모든 모델 세대에 이월되며 단가 증가가 없다.

카탈로그 품질이 조직의 도구 체계를 드러낸다

도구 설명 스멜은 즉시 오류를 내지는 않더라도 실패율과 유지 비용을 계속 높인다는 점에서 코드 스멜과 닮았다. 등록 단계에 루브릭 검증을 품질 게이트로 두는 것이 최소 조치가 된다.

도구 설명은 사람용 문서가 아니라 모델이 소비하는 인터페이스 사양이다. 배경 설명이나 예시를 길게 나열하는 사람용 문서의 관행을 그대로 가져오면 정작 목적 문장이 묻힐 수 있다. 모델은 설명 텍스트를 근거로 값을 구성하므로, 파라미터 제약을 스키마와 설명 양쪽에 적는 것은 불필요한 중복이 아니다.

오선택 로그는 조직의 도구 체계가 어디에서 모호해지는지 보여주는 1차 자료다. 이를 평가셋으로 되돌리는 루프가 없으면 개선은 운영자의 감각에 의존하게 된다. 명명 규칙과 범주 체계가 없는 도구 카탈로그는 규모가 커질수록 사용하기 어려워진다.

도구 설명 설계가 독립 영역이 되는 흐름

도구 설명 작성은 프롬프트 엔지니어링의 하위 항목에서 분리돼, 작성 표준과 린터 도구를 갖춘 설계 영역으로 자리 잡을 전망이다. MCP 서버 배포 과정에서는 설명 품질 점수가 공개 지표로 노출되고 도입 평가 항목에 편입되는 방향도 예상할 수 있다.

도구 수가 늘수록 툴 검색과 계층 선별은 기본 구성에 가까워지고, 카탈로그 설계는 에이전트 아키텍처의 핵심 결정 사항이 된다. 정확도와 실행 단계 수 사이의 상충을 다루기 위한 최적 증강 깊이 탐색도 자동화 대상으로 편입될 전망이다.

103개 서버의 856개 도구 중 97.1%가 설명 스멜을 포함했고, 56%는 목적을 명확히 적지 못했다. 6개 구성 요소를 갖추도록 설명을 증강하면 과제 성공률은 중위 5.85%p, 부분 목표 달성도는 15.12% 개선되지만 실행 단계 수도 늘어난다. 설명 품질, 카탈로그 축소, 선별 노출, 오선택 로그의 평가셋 환류를 하나의 운영 루프로 묶어야 한다.