MCP 평가: 2026-07-28 사양을 위해 작성한 7-어설션 하네스

Model Context Protocol 개정판 2026-07-28이 최종 확정되었으며, MCP 평가 스위트에 가장 먼저 영향을 미치는 것은 초기화 메서드의 삭제입니다. 더 이상 initialize 호출이 없습니다. Mcp-Session-Id도 없습니다. 지원하지 않는 프로토콜 버전에 대해 하드코딩한 오류 코드가 -32004에서 -32022로 변경되었습니다. "MCP 평가" 범주에는 두 가지 작업이 있고, 실패하는 이유가 완전히 다릅니다: 서버가 완벽하게 사양을 준수하더라도 서버의 도구 설명을 읽는 모델이 잘못된 도구를 선택할 수 있기 때문입니다. 서버가 이미 운영 중이고 실제 프로덕션 트래픽을 평가하고 싶다면 이는 별개의 작업이며, 여기서 다뤘습니다. 이 글은 배포 전의 오프라인, CI 게이트 부분입니다.

핵심 요약

개정판 2026-07-28에서 initialize 핸드셰이크가 제거되었습니다. 세션 설정으로 시작하는 스위트는 이제 실패합니다.
먼저 결정론적 스키마 준수 검사를 실행하세요. API 비용이 들지 않으며 사양 변경을 즉시 포착합니다.
도구 선택 정확도와 인수 정확도를 분리하여 점수화하세요. 완전히 다른 이유로 실패합니다.
모든 평가 케이스를 5번 실행하고 통과/실패가 아닌 통과율로 게이트를 설정하세요.

MCP 평가는 디버깅이 아닙니다: 실제로 측정하는 것

MCP 평가란 두 가지를 독립적으로 점수화하는 관행입니다: MCP 서버가 프로토콜 사양을 준수하는지 여부, 그리고 해당 서버의 도구 설명이 주어진 모델이 올바른 도구를 올바른 인수로 선택하는지 여부입니다. 첫 번째는 결정론적이고 저렴합니다. 두 번째는 LLM이 필요하며 매번 실행할 때마다 비용이 발생합니다.

이 글은 서버가 이미 실행 중이라고 가정합니다. 그렇지 않다면 MCP 서버 빌드 방법부터 시작하세요. 프로토콜 자체가 새롭다면 MCP 가이드에서 개념을 다루므로 이 글에서는 평가에 집중할 수 있습니다.

Inspector는 디버거입니다

공식 MCP Inspector(10,511개 별, 2026-07-28 푸시)는 하는 일에 훌륭합니다: 도구를 클릭하면 요청을 보고, 응답을 보고, 버그를 찾습니다. 최근에 2.0으로 업데이트되었으므로 이번 여름 이전에 작성된 기사에서 복사한 Inspector 명령어는 아마 잘못되었을 것입니다.

하지만 대화형 UI는 회귀 테스트 스위트가 아닙니다. Inspector는 서버가 응답했다는 것만 알려줄 수 있습니다. 모델이 잘못된 도구를 선택했는지는 알 수 없습니다.

선택 품질 대 실행 품질

이 주제에 대한 가장 유용한 관점은 merge.dev에서 나왔습니다. 이는 도구 선택 품질(모델이 요청에 대해 올바른 도구를 선택했는가?)과 도구 실행 품질(호출이 실제로 성공했는가?)로 구분합니다. 완벽한 실행과 형편한 설명을 가진 서버는 하나는 100%, 다른 하나는 40%를 얻습니다. 공을 드립니다: 그 구분이 나머지 방법을 명확하게 만듭니다.

우리는 가장 저렴한 것부터 시작하여 그 위에 4가지 계층을 쌓습니다:

계층 0, 준수: 결정론적, LLM 불필요, 모든 푸시에서 실행.
계층 1, 동작: 골든 세트 및 모델, 매일 밤 또는 라벨에서 실행.
계층 2, 복원력 및 보안: 폴트 인젝션 및 적대적 페이로드.
계층 3, 텔레메트리: 레이턴시, 토큰, 도구 호출당 비용.

2026-07-28 MCP 평가 도구의 현황

검색이 제시하는 MCP 평가 도구의 절반은 마지막 두 사양 개정 이후로 커밋을 출시하지 않았습니다. 아래의 모든 별 개수와 푸시 날짜는 2026-07-28 GitHub API에서 나왔습니다. 날짜는 우아하게 변하므로 직접 다시 확인할 수 있습니다.

공개 웹에서 가장 널리 공유되는 MCP 테스트 튜토리얼은 lastmile-ai/mcp-eval을 추천합니다. 해당 프로젝트의 마지막 푸시는 2025-11-19였으며, 개정판 2025-11-25가 출시되기 6일 전입니다. 이는 판단이 아니라 하나의 사실입니다. 또한 알아두세요: PyPI의 mcp-eval이라는 패키지는 관련 없는 0.0.1 플레이스홀더이므로 pip install mcp-eval은 그 프로젝트를 가져오지 않습니다. PyPI promptfoo도 얇은 래퍼입니다. 실제 도구는 Node CLI입니다.

MCP 특정 계층 위에는 일반 플랫폼 계층이 있습니다: DeepEval(deepeval 4.1.4), Promptfoo, Braintrust, LangSmith, Ragas. 우리는 최고의 LLM 평가 도구 라운드업에서 이들을 따로 순위를 매겼으므로 거기서 플랫폼을 선택하고 이 글을 MCP 형태의 계층으로 취급하여 그 안에서 실행하세요. 임계값을 보정하기 위해 제3자 서버를 원한다면 MCP 서버 라운드업이 적절한 기준 집합입니다.

일부 도구는 MCP 테스팅을 Postman을 참조점으로 하는 고전적 API 테스팅으로 프레임화합니다. 이는 전송 부분에만 작동합니다. Postman은 엔드포인트가 유효한 본문과 함께 200을 반환하는지 확인합니다. 12개의 도구 설명이 주어진 LLM이 올바른 도구를 선택하는지에 대해서는 의견이 없으며, 이것이 프로덕션에 도달하는 실패 모드입니다.

학술 자료는 CI에서 실행하는 것이 아니라 방법론으로서 유용합니다. MCP-RADAR(arXiv 2505.16700)와 MCPSecBench(arXiv 2508.13220)가 가장 관련성 높은 두 가지입니다.

2026-07-28 사양이 기존 MCP 테스트를 어떻게 깨뜨리는지

그렇습니다, 깹니다. 개정판 2026-07-28은 2026년 7월 28일 주요 유지보수자 David Soria Parra와 Den Delimarsky에 의해 최종본으로 출시되었습니다(공지). 가장 심하게 영향을 미치는 3가지 변경: initialize 핸드셰이크가 제거되었고, 3개의 오류 코드가 재번호화되었으며, Roots, Sampling, Logging이 모두 더 이상 사용되지 않습니다. 아래의 모든 세부사항은 공식 변경 로그에서 나옵니다.

MCP 테스트 스위트가 initialize를 호출하여 시작하면 더 이상 존재하지 않는 메서드를 호출하여 시작합니다. 여기 변경의 형태입니다:

계획해야 할 두 가지 결과가 있습니다. 첫째, MRTR(Multi Round-Trip Requests, SEP-2322)은 서버 시작 왕복을 대체합니다: 서버가 sampling/createMessage 요청을 보내는 대신, resultType: "input_required"와 inputRequests 필드가 있는 결과를 반환하고, 클라이언트는 inputResponses가 첨부된 원래 호출로 재시도합니다. 이것은 평가할 완전히 새로운 다단계 표면이며, 적용 범위는 여전히 부족합니다. 둘째, 사양이 이제 공식 기능 수명 주기를 전달합니다: 활성, 더 이상 사용되지 않음, 제거됨, 최소 12개월 사용 중단 기간 및 90일 긴급 예외 포함. 이제 반응하는 대신 스위트의 수명을 계획할 수 있습니다.

상태 비저장의 운영 효율은 대부분의 사람들이 인용할 라인입니다: MCP 서버는 이제 스티키 세션과 공유 세션 저장소가 없는 단순 라운드 로빈 로드 밸런서 뒤에 앉을 수 있습니다.

계층 0: LLM이 필요 없는 7가지 준수 어설션

스키마 준수 테스팅은 모델이 관여하지 않고 프로토콜 사양 자체에 대한 서버 응답을 확인하는 것을 의미합니다. 결정론적이고, API 비용이 들지 않으며, 몇 초 안에 완료되고, LLM 실행에 비용을 들이기 전에 사양 변경을 포착합니다. 이것이 모든 푸시에서 실행되고 나머지는 일정에 따라 실행되는 이유입니다.

2026-07-28 변경 로그에 대해 작성한 7가지 어설션입니다:

server/discover가 응답하고 supportedVersions 배열에 하네스가 지원하는 버전이 포함됩니다.
tools/list는 두 개의 연속 호출 전체에서 동일한 순서를 반환합니다(사양 SHOULD, 클라이언트 및 프롬프트 캐싱용).
모든 list 결과는 ttlMs와 cacheScope를 전달하며, cacheScope는 "public" 또는 "private"로 설정됩니다(SEP-2549).
모든 결과는 resultType을 전달합니다; 없거나 알려지지 않은 것은 "complete"로 처리됩니다. 이는 더 오래된 서버에 대한 하위 호환성 케이스입니다.
모든 도구의 inputSchema와 outputSchema는 JSON Schema 2020-12로 검증되며 모든 $ref가 해석 가능합니다(SEP-2106).
오류 경로는 재번호화된 코드를 반환합니다: -32020, -32021, -32022, 그리고 누락된 리소스에 대해 -32602(SEP-2243).
스트리밍 가능한 HTTP POST는 Mcp-Method를 전달하며, tools/call, resources/read 및 prompts/get에서 Mcp-Name을 전달합니다; 불일치는 -32020을 반환해야 합니다(SEP-2243).

설정은 4단계입니다: httpx, jsonschema 및 pytest를 설치합니다; 하네스를 서버 URL 또는 stdio 명령으로 지정합니다; 계층 0을 실행합니다; 보고서를 읽습니다.

MCP 평가: 2026-07-28 사양을 위해 작성한 7-어설션 하네스