MCP-Atlas: A Large-Scale Benchmark for Tool-Use Competency with Real MCP Servers

요약

MCP-Atlas는 실제 운영 중인 MCP 서버 36개와 도구 220개 위에서 1,000개의 자연어 task로 LLM 에이전트의 tool use 능력을 재는 벤치마크다. tool use는 모델이 외부 도구를 호출해 행동 범위를 넓히는 능력을 말한다. Scale AI와 National University of Singapore의 저자들은 task를 자동 생성하지 않고 전문가가 직접 작성하고 검증했으며, 채점 기준을 특정 tool call 경로와의 일치가 아니라 최종 답에 담겨야 할 원자 단위 claim의 충족 여부로 두었다.

이 채점 설계 덕분에 벤치마크는 다른 경로로 같은 사실에 도달한 풀이에도 만점을 주고, 실패한 task에는 11개 유형의 자동 진단을 붙일 수 있다. 20개 프런티어 모델을 같은 조건에서 평가한 결과 최고 성적은 Muse Spark의 82.2%였고, 진단된 실패 약 6,900건 가운데 63.3%가 tool call 계열이 아니라 인지 계열이었다. 즉 현재 에이전트의 병목은 유효한 tool call을 만드는 능력보다 도구에 접근한 뒤 근거를 충분히 모았는지 판단하고 최종 답을 합성하는 단계에 있다.

배경

MCP는 LLM 에이전트가 외부 도구를 발견하고 호출하는 계층의 표준 인터페이스로 자리 잡았다. 서버 발견, 도구 열거, 타입이 있는 파라미터 전달, 결과 소비를 하나의 규약으로 제공하기 때문이다. 그러나 MCP 기반 배포가 빠르게 늘어난 것과 달리 그 위에서 동작하는 에이전트를 신뢰할 수 있게 평가하는 일은 여전히 어려운 과제로 남아 있다.

저자들은 실무 배포가 평가에 요구하는 조건을 세 가지로 본다. 첫째, 분기와 cross-server 조율이 있는 현실적인 multi-step 워크플로를 다룰 것. 둘째, mock 대체물이 아닌 실제 MCP 서버와 API를 폭넓게 쓸 것. 셋째, 에이전트의 장황함이나 문체와 분리된 구조적이고 재현 가능한 claim 수준 채점을 할 것. 기존 MCP 벤치마크는 이 가운데 한두 가지에서 진전을 냈지만 나머지에서 한계를 보였다.

기존 MCP 벤치마크의 절충

기존 MCP 벤치마크에는 지속적인 긴장이 있다. 평가 엄밀함을 최적화한 벤치마크는 규모가 작게 머물고, 규모를 달성한 벤치마크는 객관성이나 현실성에서 타협한다. 논문의 Table 1은 동시대 벤치마크 8종을 서버 수(#S), 도구 수(#T), task 수, 그리고 네 가지 설계 항목으로 비교한다.

네 항목을 모두 갖춘 벤치마크는 MCP-Universe, MCP-Bench, Toolathlon, LiveMCPBench, MCP-Atlas 다섯이다. 그중 task가 1,000개인 것은 MCP-Atlas뿐이고 나머지 넷은 95개에서 231개에 머문다. 반대로 task 수가 많은 MCPEval(676개)과 MCP-RADAR(507개)는 distractor가 없고 cross-server 조율이 부분적이다.

절충의 양상은 벤치마크 계열마다 다르다.

MCP-Universe가 제기한 unknown-tools 문제, 즉 에이전트가 도구를 호출하기 전에 어떤 도구가 관련 있는지 먼저 찾아내야 한다는 문제는 MCP-Atlas의 distractor 설계로 이어졌다.

평가 타당성을 위협하는 세 요소

MCP-Atlas는 기존 연구가 통제하지 않은 평가 타당성 위협 세 가지를 겨냥한다.

이 세 대응은 곧 논문의 세 설계 선택이다. 자동 생성 대신 체계적 수동 검증으로 규모와 품질을 함께 확보하고, 전체론적 judge 대신 claim 기반 부분 점수를 쓰며, 실제 서버만 쓰되 distractor를 체계적으로 심는다.

핵심 개념

claim은 정답이라면 최종 답에 담겨 있어야 하는 원자적 사실 진술이다. MCP-Atlas는 task마다 도구 출력에 근거한 claim 목록을 정의하고, 모델이 어떤 경로로 답에 도달했는지는 보지 않는다. 평균은 task당 4.7개이고 범위는 1개에서 23개다.

coverage는 task의 claim 점수를 평균낸 값이다. judge가 claim 하나를 충족(1.0), 부분 충족(0.5), 미충족(0.0)으로 매기면 coverage는 그 평균이 되고, 주 지표인 pass@0.75는 coverage 0.75 이상을 통과로 센다. coverage가 실수 값이므로 임계값을 바꾸는 것은 채점상의 결정이 아니라 보고상의 결정이다.

distractor는 task에 함께 노출되지만 풀이에는 필요 없는 도구다. 무작위 도구가 아니라 의미상 비슷한 카테고리에서 뽑기 때문에, 알려진 API를 실행하는 능력이 아니라 잡음 속에서 필요한 도구를 발견하는 능력을 잰다.

reference trajectory는 저자가 검증한 최소 정답 경로로, task마다 평균 9.8 step의 tool call 시퀀스다. 풀이 가능성 확인, 도구 의존성 검증, 실패 진단에만 쓰고 통과와 실패 판정에는 절대 쓰지 않는다. 무엇을 달성해야 하는가(claim)와 어떻게 달성하는가(trajectory)를 이렇게 분리한다.

harness는 모델을 감싸 도구, 검증, 상태를 제공하는 실행 환경이다. MCP-Atlas는 컨테이너화된 harness와 claim evaluator를 함께 공개하며, 제공사가 권장하는 네이티브 tool call 전략을 그대로 쓴다.

방법

서버 생태계와 환경 버킷

36개 서버는 전부 운영용 MCP 구현이고 합성 스텁은 없다. task는 실제 endpoint를 상대로 실행되므로 진짜 rate limit, 페이지네이션 경계, 스키마 버전 불일치, 일시적 오류 코드가 그대로 돌아온다. mock 환경이 설계상 제거하는 실패 조건을 의도적으로 남긴 것이다.

서버는 다섯 환경 버킷으로 묶인다. 논문의 Table 2는 비중을 범위로, 부록 B는 정확한 값으로 제시한다.

부록 B의 Table 5는 36개 서버 전체와 각 서버를 필요로 하는 task 수를 싣는다. 여러 task가 서버 여러 개를 요구하므로 이 열의 합은 1,000을 넘는다. 상위 12개와 하위 4개는 다음과 같다.

검색과 filesystem 같은 범용 서버의 비중이 높다. 서버 선정 기준은 네 가지다. 안정적이고 문서화된 MCP 구현이 있을 것, 검색, 분석, 생산성, 금융, 코딩의 기능 카테고리에 걸쳐 다양할 것, distractor 선택이 의미를 갖도록 서버당 관련 도구가 여럿 있을 것, 현실적인 multi-step 워크플로에 적용 가능할 것이다.

컨테이너 격리

각 서버는 Docker 컨테이너로 패키징되어 네 가지 격리 조치를 받는다.

이 구성 덕분에 같은 digest로 다시 실행하면 상류 API의 실제 변화를 제외하고는 동일한 서버 동작을 얻는다. 서버별 도구 카탈로그, 컨테이너 이미지 digest, 버전 고정 정보는 데이터셋과 함께 공개된다.

task 구조와 distractor

프롬프트는 단일 턴 자연어 요청이고 서버, 도구, 파라미터 이름을 하나도 대지 않는다. 따라서 모델은 task의 의미만으로 올바른 도구 사슬을 추론해야 한다. 노출되는 도구 집합과 필요한 도구의 관계는 다음과 같다.

즉 노출된 도구 15개 중 평균 11개는 풀이에 필요 없다. cross-server 조율은 기본값이어서 98.6%가 서버 두 개 이상의 도구를 요구하고, 정확히 두 개가 51.7%, 세 개가 38.2%, 네 개 이상이 8.7%다. 대부분의 task는 뒤쪽 tool call이 앞쪽 출력으로 parameterize되는 multi-hop 의존성을 가진다.

예시 task

부록 D.5의 예시는 이 구조를 보여준다. 프롬프트는 광고 효과 논문을 조사하면서 자사 광고 데이터와 비교하려는 사용자의 요청으로, Jane Castleman의 2024년 논문 초록을 가져오고 2015년에서 2023년 사이에 시작한 캠페인 중 참여율이 가장 높은 캠페인의 날짜와 지역을 알려 달라는 내용이다. 노출된 도구 15개 중 필요한 것은 3개다.

reference trajectory는 세 단계다. arxiv 검색으로 초록을 가져오고, notion 검색으로 광고 데이터베이스를 찾고, database_id를 넣은 데이터베이스 질의로 캠페인 날짜를 조회한다. claim은 다섯 개로 논문 제목(C1), 초록 본문(C2), 참여율 15%로 동률인 캠페인이 세 개라는 사실(C3), 세 캠페인의 시작일 2022-06-24, 2019-09-20, 2017-09-09(C4), 세 캠페인의 지역 National, International, International(C5)이다. 이 예시는 프롬프트가 "arxiv"나 "notion"이라는 이름을 말하지 않아도 모델이 notion의 세 distractor 도구 대신 검색과 데이터베이스 질의를 골라야 함을 보여준다.

claim 기반 채점

evaluator judge는 task당 한 번이 아니라 claim당 한 번 호출된다. claim이 5개면 evaluator 호출도 5회 독립으로 이루어지고 task coverage는 그 5개 점수의 평균이다. 한 호출에서 모든 claim을 같은 응답에 대해 채점하면 컨텍스트 손실이 생기며, claim이 10개를 넘는 4%의 task에서 특히 그렇다.

부록 C의 evaluator 프롬프트는 수치 비교 기준을 명시한다.

judge는 세 범주 라벨과 함께 구조화된 근거와 0.0에서 1.0 사이의 신뢰도 값을 출력한다. 프롬프트는 정밀도가 claim의 의미에 결정적이지 않은 한 정확한 수치 일치보다 같은 정보를 전달하는지에 집중하라고 지시한다.

judge 구성과 신뢰구간

모든 모델은 같은 task 프롬프트, 같은 노출 도구 집합, 같은 tool call 예산(task당 100회), 같은 채점 루브릭, 같은 최종 답 프로토콜에서 평가된다. 제공사 API가 서로 다른 네이티브 tool call 인터페이스를 노출하므로 저수준 어댑터는 제공사별로 다르지만, 모델별 demonstration, 재시도 방침, task 프롬프트, scaffold는 적용하지 않는다. scaffold는 모델 주위에 짜 놓은 보조 실행 구조를 뜻한다. 부록 H는 harness가 모델 평가 중 task당 최대 5회 재시도를 허용하고 도구 오류 요약을 모델 컨텍스트에 되돌려 주며, tool call 한도 100회에 도달하면 부분 응답도 채점한다고 밝힌다.

judge 편향을 모델 성능에서 분리하려고 세 LLM judge가 모든 task를 독립적으로 채점한다.

95% 신뢰구간은 Efron의 비모수 부트스트랩으로 낸다. 모델마다 task별 coverage 점수에서 N=1000 task를 복원추출한 표본을 1만 번 뽑아 매번 pass@0.75를 다시 계산하고 2.5번째와 97.5번째 백분위를 취한다. 구간은 78.2% ± 2.5%처럼 반폭으로 보고한다.

실패 유형 분류

실패한 task는 11개 유형 taxonomy에서 주 실패 유형 하나를 배정받는다. 진단은 coverage가 0.75 미만인 task와 모델 쌍에만 실행되고, 진단 라벨은 사후 실패 분석에만 쓰이며 통과와 실패 채점에는 쓰이지 않는다. 부록 E의 Table 6은 유형마다 정의와 대표 사례를 싣는다.

유형 사이의 경계는 judge 규칙으로 정한다. 응답 오독은 도구 출력에서 잘못된 필드나 행을 읽은 것이고 잘못된 합성은 전부 맞게 읽고 결합을 잘못한 것이다. 논리 오류는 multi-step 추론 사슬 자체가 틀린 것이고, 환각은 어느 도구 출력에도 없는 사실을 말한 것이며, 도구 미사용은 도구가 필요한 사실에 대해 도구를 아예 우회한 것이다. 인자 오류는 첫 번째 잘못된 파라미터 사용이고 오류 복구 실패는 같은 오류를 적응 없이 반복한 것이다. 잘못된 합성은 논리 오류, 응답 오독, 환각으로 더 잘 설명되지 않을 때만 쓴다.

진단 절차

진단 프롬프트는 reference trajectory를 포함한다. 놓친 claim을 채우기에 충분했던 도구 접근 가능 근거가 무엇인지 알아야 사후 귀인이 가능하기 때문이다. trajectory는 검증된 근거 흔적이지 유일한 목표 경로가 아니며, 대안 계획, 다른 도구 순서, 추가 호출, 병렬 호출, 다른 parameterization에 벌점을 주는 데 쓰이지 않는다.

judge는 주 실패 하나와 기여 실패 전부를 같은 11개 어휘로 표시하고, 다른 실패를 유발한 실패에만 근본 원인 표시를 붙인다. 신뢰도는 trajectory와 채점기 근거가 한 유형을 명확히 가리키면 0.9에서 1.0, 두 번째 유형이 근접하면 0.6에서 0.8, 모호하면 0.6 미만으로 보정하며, 어떤 턴이나 문장에서 벗어났는지를 인용한 1~2문장 요약을 쓴다.

품질 관리와 task 작성 지침

task와 평가 harness의 품질은 다섯 층으로 유지된다.

task 작성 지침(부록 D)은 프롬프트에 세 요건을 요구한다. 외부 데이터가 있어야 풀리고 평가 기간 내내 유효한 정보에 의존할 것, 주관적 표현을 피하고 내부 시스템 구조나 의도된 풀이 경로를 드러내지 않는 대화체일 것, 간접 참조를 해소하거나 여러 소스에 걸쳐 데이터를 걸러야 하는 multi-step 요청일 것이다. 도구 환경은 최소 필요 근거를 주는 관련 도구, 선택 논리를 시험하는 그럴듯하지만 무관한 distractor, 그리고 불필요한 모호함 없이 도구 계열 간 근거 결합을 요구하는 multi-source 구성으로 꾸린다.

작성 단계의 검토자는 도구 선택, 도구 입력, 해석의 느슨한 3항목 체크리스트를 썼다. 이 체크리스트는 사후 실패 분석용 11개 유형 자동 진단과 별개다. task 하나당 작성, 검증, 문서화에 전문가 노동 평균 4.6시간이 들었고, 작성자와 검토자는 현지 임금 기준을 충족하거나 초과하는 계약 조건으로 보상받았다. 내부 작성 매뉴얼 전문은 운영 절차와 접근 제어 세부를 담고 있어 공개하지 않는다.

공개 split과 릴리스 구성

task는 재현성과 오염 모니터링을 위해 무작위로 500/500 공개와 비공개 subset으로 나뉜다. 공개 split은 전체 벤치마크의 도메인과 난이도 분포를 보존하며, task마다 task 식별자, 활성 도구 목록, 자연어 프롬프트, 근거 있는 사실 claim, reference trajectory를 담은 한 행으로 제공된다. 비공개 split은 같은 내부 스키마를 쓰지만 공개하지 않고 새 모델이 평가될 때의 리더보드 무결성용으로 보류한다.

저장소에는 vendor 모델 자격 증명 없이 실행되는 로컬 smoke test가 있고, 전체 라이브 재평가에는 제공사 API 키와 일부 상류 MCP 서버의 서비스별 자격 증명이 필요하다. Croissant/RAI 메타데이터도 제출 시점에 함께 제공된다.

형식화

부록 J는 task를 튜플 τ = (G, C, T_expose, π*, C*)로 정의한다. G는 목표 명세, C는 자연어 맥락과 제약, T_expose는 에이전트에 제시되는 허용 도구 집합, π는 진단용 최소 의존 충족 tool call 시퀀스인 reference trajectory, C는 정답이 담아야 할 서로 겹치지 않고 독립적으로 검증 가능한 명제의 집합인 claim 목록이다. π*가 요구하는 도구 T_req가 target이고 T_expose에서 T_req를 뺀 나머지가 distractor다.

단일 턴 프롬프트가 주어지면 에이전트는 T_expose에서 tool call을 내고 환경은 잘 정의된 출력이거나 스키마 위반, rate limit 같은 오류 토큰을 돌려준다. 이 실행 trace를 쌓은 뒤 에이전트는 텍스트 답 Â를 내며, 상호작용은 유한 horizon POMDP를 이룬다. reward는 claim 기반 채점 함수 S(Â, C*)로 사후에 붙고, 통과와 실패는 S로만 결정되며 π*와 독립이다.

결과

전체 성능과 세 층 구조

20개 모델은 Anthropic, Google, OpenAI, Meta 네 독점 제공사와 Kimi, GLM 두 오픈소스 제공사에서 나왔다. 모든 모델이 1,000개 task 전체를 같은 노출 도구, tool call 예산, 프롬프트 템플릿, evaluator judge로 실행했다.

리더보드는 세 층으로 나뉜다.

두 결과가 두드러진다. 첫째, 오픈소스 GLM-5.1은 75.6%로 주 judge 기준 GPT-5.5와 통계적으로 동률이고 다른 GPT-5.x 변형보다 위에 있다. 저자들은 이를 에이전트 과제에서 오래 독점 모델에 유리했던 격차가 좁혀진 것으로 본다. 둘째, 수학과 코딩 벤치마크에서 선도적 추론 모델인 o3 Pro는 44.5%로 하위권에 머문다. 실패한 trajectory의 40.1%에 tool call이 하나도 없어, 외부 근거가 필요한 task와 기본 tool use 방침이 맞지 않는다는 신호다.

상위 세 모델은 78.2%에서 82.2% 사이에 몰려 있고 judge 간 범위가 2.1%p에서 4.6%p이므로, 최상위의 작은 순위 교체는 안정적 능력 격차가 아니라 evaluator 불확실성으로 읽어야 한다. 동시에 최고 모델도 task 다섯 개 중 하나 가까이를 실패하므로 현실적인 multi-server 워크플로에는 여전히 개선 여지가 있다.

실패 유형 분석

20개 모델에서 진단된 약 6,900건의 실패 중 63.3%가 인지 계열이고 36.7%가 tool call 계열이다. 이 분포는 MCP-Atlas가 유효한 tool call을 낼 수 있는지만 재는 벤치마크가 아님을 보여준다. 현재 에이전트의 지배적 실패는 도구에 접근한 뒤에 벌어진다. task를 이해하고, 근거가 충분히 모였는지 판단하고, 도구 출력에서 최종 답을 합성하는 단계다. tool call 실패는 리더보드 하위에서 여전히 중요하지만 남은 오류의 대부분을 설명하지는 않는다.

논문의 Table 3은 모델별로 진단된 전체 실패 가운데 tool call 계열 네 유형이 차지하는 비율을 싣는다. Tool%는 전체 실패 중 tool call 계열의 비중이다.

가장 뚜렷한 tool use 실패는 하위 모델에서 나타난다. o3 Pro는 진단된 실패의 57.6%가 tool call 계열이고 실패 trajectory의 40.1%에 tool call이 전혀 없다. GPT-5.1과 Claude Haiku 4.5도 덜 극단적이지만 비슷한 근거 획득 실패를 보여 tool call 계열 비중이 각각 50.4%와 46.7%이고, 도구 미사용이 각각 22.9%와 25.7%다. 이 모델들은 근거 수집 단계에 들어가기 전에 실패하는 경우가 많다. 저자들은 기본 tool use 방침이 미지의 도구와 현실적 distractor가 있는 MCP 환경에 잘 보정되지 않았다고 해석한다.

Table 4는 같은 방식으로 인지 계열 일곱 유형의 비율을 싣는다. Cog%는 전체 실패 중 인지 계열의 비중이며 모델마다 Tool%와 합쳐 100%가 된다.

전체 평균에서 가장 큰 단일 유형은 조기 종료 18.7%이고 task 오해 15.1%, 잘못된 합성 12.0%가 뒤를 잇는다. 강한 모델에서는 병목이 tool call에서 근거 사슬을 완성하고 활용하는 단계로 옮겨 가고, 최신 프런티어 모델은 이 경계를 더 하류로 밀어낸다. 조기 종료는 한 상위 하위집단의 대표 실패다. Gemini 3.1 Pro Preview, GPT-5.4, Claude Opus 4.6은 진단된 실패의 각각 42.8%, 41.4%, 36.3%에서 조기 종료한다.

반면 더 새로운 GPT-5.5와 Claude Opus 4.7은 조기 종료를 각각 3.6%와 3.8%로 거의 없앴지만, 오류가 더 어려운 retrieval 이후 실패로 다시 나타난다. 잘못된 합성이 GPT-5.5에서 19.8%, Claude Opus 4.7에서 25.0%로 올라가고, GLM-5.1도 조기 종료 3.8%에 잘못된 합성 22.5%로 같은 양상이다. 에이전트가 워크플로를 끝까지 지속하지만 수집한 근거를 잘못 결합하거나 잘못 해석하거나 잘못 보고하는 새로운 프런티어 국면이다. 따라서 저자들은 다음 개선이 claim을 의식한 정지 기준뿐 아니라 최종 답을 수집된 도구 근거에 대조하는 trajectory 기반 verification에서 나올 것으로 본다.

효율 frontier

정확도만이 아니라 그 정확도에 드는 시간도 실무에서는 중요하다. Figure 2는 모델마다 task당 평균 벽시계 trajectory 시간과 pass rate를 함께 그린다.

Pareto frontier 위에는 여섯 모델이 있다.

여러 모델은 더 빠른 대안에 완전히 지배된다.

GPT-5.4 Mini의 사례는 벽시계 시간이 모델 추론이 아니라 tool call 왕복 지연에 지배되는 에이전트 환경에서는 "Mini"라는 이름이 빠른 실행으로 이어지지 않음을 보여준다. GLM-5.1은 강한 pass rate에도 벽시계 비용 탓에 frontier에 들지 못한다.

judge 간 일치도

부록 F의 Table 7은 20개 모델의 pass@0.75를 세 judge별로 싣고 judge 간 범위와 순위를 함께 보여준다.

모델별 점수 범위는 2.1%p에서 4.6%p다. 순위는 judge 사이에서 대체로 보존되고 몇 안 되는 변동은 촘촘한 상위 군집과 15위에서 17위 구간에 집중된다. 가장 큰 변동은 Claude Opus 4.7로, Gemini 3.1 Pro Preview에서 2위, GPT-5.4에서 3위, Claude Opus 4.6에서 5위다. 저자들은 이를 self-preference로 해석하지 않는다. Claude judge는 더 새로운 Anthropic 모델을 우대하지 않으며 오히려 Gemini 3.1 Pro Preview와 GLM-5.1을 그 위에 놓기 때문이다.

더 보수적인 해석은 상위 군집의 여러 모델이 judge 간 범위에 견줄 만한 간격으로 떨어져 있다는 것이다. 따라서 상위권의 작은 순위 교체는 견고한 능력 차이가 아니라 evaluator 불확실성으로 읽어야 하며, 주 리더보드에는 단일 주 judge를 쓰고 judge 간 범위를 보정 정보로 보고하는 방식이 뒷받침된다.

coverage 임계값 민감도

주 본문의 0.75 임계값은 리더보드 관례를 따른 보고상의 결정이다. 부록 G의 Table 8은 평균 coverage와 0.50, 0.75, 0.90 임계값 pass rate를 함께 싣는다.

단일 대표 임계값을 쓰는 근거는 두 가지다. 첫째, 0.50과 0.75 사이의 Spearman 순위 상관이 ρ = 0.965로 높아 순위가 대체로 보존된다. 둘째, 두 pass rate의 절대 차이는 리더보드 상위에서 좁고 하위로 갈수록 넓어진다. Muse Spark는 89.6%에서 82.2%로 7.4%p 하락하지만 Claude Haiku 4.5는 55.8%에서 40.2%로 15.6%p 하락한다. 부분 점수는 엄격한 통과 기준보다 얻기 쉽고 그 격차는 전체 능력이 낮을수록 커지므로, 잘 동작하는 coverage 지표에서 기대되는 양상이다. pass@0.90에서는 상위 모델 사이의 격차가 더 벌어져 Muse Spark 71.2%와 Claude Opus 4.7 63.2%의 차이가 8.0%p다.

공개와 비공개 split 격차

공개 split에는 프롬프트, 도구 집합, claim, reference trajectory가 들어 있으므로 릴리스 이후의 격차는 암기의 직접 증거가 아니라 split 민감도와 노출 모니터링 신호로 해석해야 한다. 대부분의 모델이 공개 task에서 더 높은 점수를 받고 격차는 −0.8%p에서 +9.6%p에 걸치며, 격차는 전체 pass rate를 따라가지 않는다.

격차에는 제공사별 군집이 보인다.

집단 크기가 고르지 않은 작은 모델 수준 비교이므로 저자들은 이 패턴을 오염 증거가 아니라 감사 신호로 다루고, split 격차를 전체 점수와 나란히 감사 통계로 보고한다. Kimi K2.5만 비공개 성적이 공개보다 높고, Muse Spark의 격차 +0.4%p가 가장 작다.

재현 비용

부록 H는 리더보드 재현에 드는 비용을 밝힌다.

관측된 평균 trajectory 시간이 task당 27초에서 194초까지 벌어지므로 모델에 따라 전체 실행 시간도 2시간에서 18시간까지 차이가 난다.

한계

저자가 명시한 한계

부록 A는 결론을 제한하는 요인을 일곱 항목으로 밝힌다.

더 넓은 영향에 대해서도 저자들은 신중하다. 벤치마크는 배포 전에 신뢰성 격차를 드러내지만, 더 나은 평가는 오용, 무단 데이터 접근, 프라이버시 유출, 상류 이용 약관 위반이 가능한 환경에서 더 효과적으로 동작하는 에이전트 개발도 가속할 수 있다. 라이브 MCP 평가는 API drift, 라이선스 변경, 사용자가 harness를 개인 계정에 연결할 때의 민감 출력 노출 같은 상류 위험을 물려받는다. 그래서 MCP-Atlas는 안전 필수, 프라이버시 민감, 고위험 배포에 대한 안전 인증이 아니라 신뢰성과 실패 분석을 위한 진단 벤치마크로 쓰라고 명시한다.

향후 과제로는 단일 pass rate 대신 정확도, 효율, judge 민감도, split 격차, drift, 실패 유형을 묶은 진단 프로파일을 보고하는 관행, 그리고 멀티턴 명확화와 distractor ablation의 추가를 든다.

자료에서 확인할 수 없는 것

다음 항목은 논문에 기술이 없어 이 페이지에서 판단할 수 없다.

• distractor 수나 서버 수에 따른 성능 변화. 저자들이 distractor ablation을 향후 과제로 들었을 뿐 결과는 없다.
• 220개 도구의 개별 목록. 서버별 도구 카탈로그는 데이터셋과 함께 공개된다고만 적혀 있다.
• 11개 실패 유형의 자동 진단이 사람 라벨과 얼마나 일치하는지. 진단 judge의 정확도 검증 결과는 논문에 없다.
• 20개 모델의 평가 시점별 실제 API 버전. Table 9는 model ID와 reasoning 설정만 싣는다.
• 게재 학회. 논문은 arXiv 프리프린트로 제시되며 학회 정보는 raw에 없다.

자료 내적 불일치

컨테이너 재시작 시점의 기술이 두 곳에서 다르다. 3.1절은 재현성을 위해 "평가 실행 사이"에 재시작한다고 적었고, 부록 B는 task 간 상태 누출을 막기 위해 "task 사이"에 재시작한다고 적었다. 이 페이지는 더 구체적인 부록 B의 기술을 따랐다.

3.3절은 모델별 재시도 방침을 적용하지 않는다고 적었고, 부록 H는 harness가 task당 최대 5회 재시도를 허용한다고 적었다. 전자는 모델별 차등을, 후자는 모든 모델에 공통인 harness 동작을 가리키는 것으로 읽히지만 논문이 이 관계를 명시하지는 않는다.

핵심 용어

관련 페이지

• OSWorld: Benchmarking Multimodal Agents for Open-Ended Tasks in Real Computer Environments: 채점 설계가 대비되는 agent 벤치마크. OSWorld는 task마다 실행 기반 채점 스크립트를 붙였고 MCP-Atlas는 claim 목록을 붙였다
• MCP Server Architecture Patterns for LLM-Integrated Applications: 같은 MCP 계층을 서버 쪽에서 다룬 논문. 클라이언트가 tool의 자연어 설명만 읽고 무엇을 호출할지 고른다는 제약을, 이 벤치마크는 distractor 사이의 도구 발견 문제로 측정한다
• The Agent Loop: A Survey of Control Strategies, Skills, and Harnesses for LLM Agents: agent loop의 정지 조건과 harness 일반론. 이 논문의 조기 종료 18.7%와 잘못된 합성 12.0%는 loop의 종료 판단과 verification 설계 문제로 읽을 수 있다
• Why Do Multi-Agent LLM Systems Fail?: MAST의 14개 실패 모드 taxonomy. 실패를 유형화해 집계한 접근이 같고, 이 논문은 단일 에이전트의 tool use 실패를 11개 유형으로 나눈다
• 용어집: Agents (Terminology Glossary): tool use, tool call, claim, coverage, distractor의 canonical 표기