Executive Summary

MCP 서버를 실제로 띄워서 관찰하는 연구는 예외 없이 같은 벽에 부딪힌다. 공개된 서버 대부분이 그냥 실행해서 말을 걸 수 있는 상태가 아니라는 것이다. 논문의 표현을 그대로 옮기면 "모든 행동 관측 MCP 연구는 같은 문제를 풀어야 한다. 공개된 서버 대부분은 그냥 띄워서 대화할 수가 없다."

문헌이 내놓은 해법은 저마다 다르지만 공통점이 하나 있다. 전부 선택을 포함한다. 레퍼런스 집합과 인기 목록은 사람들이 이미 쓰고 있는 서버를 고르게 된다. 손으로 꾸린 프레임은 큐레이터가 작동시킬 수 있었던 서버를 고르게 된다. 가장 큰 규모의 시도인 MCPZoo는 다중 에이전트 프레임워크로 서버를 고쳐 가며 기동시키는 쪽을 택했고, 그렇게 수집한 64,611개를 동적 분석이 가능한 37,288개로 바꿨다. 이 방법들은 각자의 목적에서 전부 합리적인 공학적 선택이고, 논문도 그렇게 인정한다. 다만 넷 다 같은 양을 지운다. 공개된 모집단 가운데 얼마나 많은 부분이 애초에 죽은 채로 등록돼 있는가라는 양이다.

그래서 이 논문은 문제를 풀지 않는 쪽으로 방향을 튼다. 저자의 문장은 짧다. "우리는 그 문제를 풀지 않음으로써 그 양을 잰다." 레지스트리에서 확률 표본을 뽑고, 뽑힌 것마다 수리도 재시도도 자격증명도 없이 딱 한 번씩만 찔러 보고, 400개 전부에 대해 포함되었는지 제외되었는지를 이유와 함께 기록한다. 조용히 빠지는 서버를 하나도 두지 않는 것이 이 설계의 핵심이다.

논문은 자기가 설 자리도 좁게 잡아 둔다. 관련 연구를 정리하는 절에서 저자는 이 측정의 행동 관측 표본이 MCPZoo가 다룬 규모보다 자릿수로 두 자리, 그러니까 백 배가량 작으며 자기는 어떤 보안 주장도 하지 않는다고 먼저 밝힌다. 그러면서 두 연구가 보완 관계를 이루는 지점을 구체적으로 짚는다. MCPZoo의 수리 파이프라인은 기동하지 않는 서버를 기동하는 서버로 바꾸려고 만들어졌고, 이 논문이 측정하는 것은 바로 그 파이프라인이 구조하려는 모집단이다. 레지스트리를 120개 스냅샷으로 추적한 Bharti의 측정을 두고도 같은 방식으로 선을 긋는다. 설명이 낡아 가는 속도를 다루는 일은 저쪽의 몫이고, 이 논문의 센서스는 스냅샷이 둘뿐이라 모집단의 크기를 재고 표집 프레임을 만드는 데만 쓴다고 적는다.

1.1센서스에서 표본까지

측정은 두 층으로 나뉜다. 먼저 수집기가 공식 레지스트리 API를 커서 페이지네이션으로 끝까지 훑어 자기 신고 메타데이터만 기록한다. 배포 모델, 패키지 생태계, 선언된 전송 방식, 생애주기 상태, 고정된 스키마 리비전이 전부다. 이 층은 외부 코드를 하나도 실행하지 않으므로 공개된 모집단 전체로 확장된다. 2026년 8월 22일 스윕에서 서버는 24,135개였다. 여기서 npm으로 배포되고 stdio를 선언했으며 활성 상태인 서버만 남기면 7,258개가 되고, 이것이 표집 프레임이다.

추출은 프레임을 레지스트리 식별자로 정렬한 뒤 시드를 넣은 mulberry32 난수로 부분 피셔예이츠를 돌려 400개를 비복원으로 뽑는 방식이다. 시드는 20260819로 공개돼 있고, 추출 명세에는 프레임 바이트의 SHA-256이 함께 기록된다. 나중에 누군가 다시 뽑았을 때 프레임이 그사이 움직였다면 같은 것으로 간주되는 대신 어긋난 사실이 탐지된다. 뽑힌 패키지는 npx로 stdio 위에 올라가고, 계측기는 MCP 통신 규약을 직접 말하면서 초기화 핸드셰이크를 하고 tools/list로 도구를 열거한 다음 각 도구의 JSON Schema를 사양이 요구하는 제약에 대조한다. 자격증명은 한 번도 제공되지 않고, 부작용을 일으키는 도구는 호출되지 않는다.

재현 장치가 이 측정의 무게를 지탱한다. 계측기 mcp-probe와 수집기, 시드 추출 스크립트, 재개 가능한 프로브 실행기, 집계 스크립트, 자체 검사가 붙은 중복 측정 코드, 타당성 검정 묶음까지 전부 공개돼 있다. 400개 draw의 서버별 결과도 그대로 공개되어, 집계를 믿는 대신 직접 다시 셀 수 있다. 논문에 실린 모든 수치는 커밋된 스크립트와 공개된 시드, 추출 명세에 기록된 프레임 해시에서 다시 만들어진다.

다만 센서스 층만은 이 재현 규칙에서 비켜서 있다. 레지스트리 스윕은 모집단이 계속 움직이기 때문에 사후에 되살릴 수 없고, 그래서 각 스냅샷은 찍힌 그 순간의 집계로 공개된다. 저자가 이 층에 붙인 장치는 재현이 아니라 정직한 실패 쪽이다. 수집기는 훑은 페이지 수와 버전 행 수, 그리고 스윕이 끝까지 돌았는지를 표시하는 플래그를 함께 기록한다. 도중에 잘린 실행은 완결된 값인 척 보고되는 대신 하한으로 표시된다.

출처의 성격은 분명히 해 두는 편이 낫다. 이 측정은 기관 소속 연구팀이 아니라 독립 연구자 한 사람이 2026년 9월 10일 arXiv에 올린 preprint이며, 아직 동료 심사를 거치지 않았다. 라이선스는 CC BY 4.0이고 판본은 v1 하나뿐이다. 심사를 통과한 논문이 아니라는 사실과 재현 장치를 전부 열어 둔 논문이라는 사실은 함께 읽어야 한다.

400번의 추출은 네 갈래로 갈렸다. 초기화 핸드셰이크까지 끝낸 서버가 195개로 48.8%, 아예 기동하지 못한 서버가 150개로 37.5%, 자격증명이 없어 더 나아가지 못한 서버가 53개로 13.3%, 패키지 자체를 받을 수 없던 경우가 2개로 0.5%다. 표에 실린 네 줄이 400개 전부이고, 표 아래 논문이 붙인 한 문장은 그 점을 못박는다. "어떤 서버도 조용히 빠지지 않았다."

표 1. 400개 추출 전부의 결과. 출처: arXiv:2609.10962v1 Table 1.

2.1큐레이션이 얹는 값의 크기

같은 계측기를 다른 표본에 돌리면 다른 수가 나온다. 저자는 레퍼런스 서버와 인기 커뮤니티 서버를 손으로 골라 만든 24개짜리 프레임에 같은 프로브를 돌렸고, 24개 중 16개가 포함돼 66.7%가 나왔다. 두 값의 차이 17.9포인트가 큐레이션이 만드는 선택 효과의 크기다. 손으로 고른 목록에서 가동률이 얼마나 올라가는지가 이 비교에서 숫자로 나왔다.

이 비교군의 정체를 오해하지 않는 편이 좋다. 논문에서 이 24개 프레임에는 인용 번호가 붙어 있지 않다. 다른 사람이 먼저 낸 연구가 아니라, 같은 저자가 같은 계측기로 먼저 재 둔 자신의 손 큐레이션 표본이다. 그러니 "기존 연구에서는 66.7%였다"는 식으로 읽으면 틀린다. 그리고 24개라는 크기 자체가 이 비교의 한계이기도 하다. 아래 두 격차가 전부 이 작은 비교군에 걸려 있다.

까다로운 대목은 큐레이션이 한 축만 건드리지 않는다는 점이다. 켜지는 비율은 큐레이션 쪽이 높고, 도구에 안전 주석이 빠져 있는 비율은 큐레이션 쪽이 낮다. 두 번째 축의 수치는 3절에서 자세히 다루지만, 방향만 먼저 보면 그림이 분명해진다. 큐레이션은 모집단의 건강을 한 축에서는 올려 보이고 다른 축에서는 내려 보인다.

방향이 엇갈린다는 사실이 실무에서 곧바로 걸린다. 한 방향으로만 치우친 편향이라면 계수를 곱해 보정하면 된다. 큐레이션된 목록에서 잰 값에 보정을 걸어 모집단을 추정하는 접근이 성립하지 않는 이유가 여기 있다. 어느 쪽으로 보정해야 할지가 지표마다 달라지기 때문이다.

2.2죽어 있는 쪽이 잠겨 있는 쪽보다 많다

실패의 정체는 문헌이 예상하던 것과 달랐다. 공개된 MCP 서버를 찔러 볼 수 없는 이유로 흔히 지목되는 것은 자격증명 게이팅이다. 실제로 그 경우가 400개 중 53개로 잡혔다. 그런데 그냥 시작되지 않는 서버가 150개로, 세 배 가까이 많다. 열쇠가 없어 못 들어가는 문보다 아예 문이 없는 쪽이 훨씬 흔하다는 뜻이다. 논문은 이 관찰을 이렇게 정리한다. 행동 관측 MCP 연구들이 실제로 표본을 뽑는 그 프레임 위에서, 공개된 항목 다섯 중 둘가량이 죽어 있다.

"실제로 불러 봤더니 목록과 달랐다"는 문제의식 자체는 이 블로그에서 다룬 적이 있다. 공공 API로 만든 도구 그래프에서 연결을 실제 호출로 검증한 실제로 불러 본 연결만 남겨 만든 공공 API 학습 데이터가 그것이다. 다만 그 글이 잰 단위는 도구와 도구 사이의 연결이고 이 글이 잰 단위는 서버의 핸드셰이크라, 두 측정의 숫자를 나란히 놓고 비교할 수는 없다. 겹치는 것은 태도다. 목록에 적혀 있다는 사실과 실제로 작동한다는 사실을 따로 세야 한다는 태도다.

켜진 195개 서버는 도구 2,766개를 광고했고, 그중 2,759개가 설명을 달고 있었다. 설명이 없는 일곱 개가 남는데, 뒤에서 중복을 세는 키가 이름과 설명을 이어 붙인 문자열이라 이 일곱 개의 존재는 지우지 않는 편이 정확하다. 서버당 도구 수는 심하게 치우쳐 있다. 최소 1개, 중앙값 8개, 95퍼센타일 46개, 최대 300개다. 도구를 하나도 광고하지 않은 서버도 한 개 있었다.

3.1기계가 막는 층은 빈틈이 없었다

먼저 구조부터 봤다. 도구 2,766개 가운데 치명적인 JSON Schema 위반은 0건이고, 서버 195개 가운데 그런 위반을 가진 서버도 0개다. 스키마가 통째로 빠진 경우도, type이 잘못된 경우도, properties나 required가 망가진 경우도 없었다. 저자는 이 결과를 소표본 우연으로 넘기지 않기 위해 근거를 하나 덧붙인다. 앞서 200개 도구 규모의 큐레이션 프레임에서 나왔던 같은 결과가, 대략 열네 배 규모이면서 고른 것이 아니라 뽑은 표본에서 그대로 재현됐다는 것이다. 그래서 이것은 우연보다 구조적 성질에 가깝다. MCP 도구 스키마가 자주 망가져 있다는 통념은 이 측정으로 지지되지 않는다.

3.2사람이 채워야 하는 층은 절반 넘게 비어 있었다

같은 서버들의 다른 층은 전혀 다른 모습이었다. MCP 사양에는 도구를 호출하기 전에 그 도구가 안전한지 에이전트에게 알려 주는 주석 네 종류가 있다. readOnlyHint는 읽기만 하는지, destructiveHint는 되돌릴 수 없는 변경을 하는지, idempotentHint는 같은 호출을 반복해도 되는지, openWorldHint는 외부 세계와 상호작용하는지를 표시한다. 네 가지 모두 선택 항목이라 아무것도 강제하지 않는다. 필수 항목이 빠진 것이 아니라, 채우지 않아도 되는 칸이 채워지지 않은 것이다. 무작위 표본에서 도구 2,766개 중 1,626개, 즉 58.8%가 주석을 하나도 달고 있지 않았다.

손으로 고른 24개 프레임에서 같은 값은 41.5%였다. 큐레이션이 이 수치도 17.3포인트만큼 좋게 보이도록 만든 셈이고, 이유는 켜지는 비율을 부풀린 이유와 같다. 레퍼런스 서버는 주석을 달고, 큐레이션된 프레임은 레퍼런스 서버로 가득하다. 논문은 그래서 한 줄을 덧붙인다. 낮은 쪽 수치를 생태계 비율로 인용해서는 안 된다는 것이다.

빈칸이 무엇을 뜻하는지는 사양이 미리 정해 두었다. 네 주석은 선택 항목이지만, 값이 없을 때 적용되는 기본값이 규격에 적혀 있다. readOnlyHint의 기본값은 거짓, destructiveHint는 참, idempotentHint는 거짓, openWorldHint는 참이다. 주석이 하나도 없는 도구를 규격대로 읽으면 읽기 전용이 아니고, 되돌릴 수 없는 변경을 할 수 있으며, 같은 호출을 반복해도 되는지 보장되지 않고, 외부 세계와 상호작용하는 도구가 된다. 58.8%는 정보가 비어 있는 상태라기보다, 켜진 서버가 광고한 도구의 절반 이상이 규격의 보수적 기본값 아래로 들어간다는 뜻이다.

사양은 반대편에도 선을 그어 둔다. 주석이 달려 있다고 해서 그 값을 믿으라는 말은 아니다. 서버 도구를 규정한 절은 클라이언트가 신뢰할 수 있는 서버에서 온 것이 아닌 한 도구 주석을 신뢰하지 않는 것으로 간주해야 한다고 적는다. 주석은 서버가 자기 도구를 스스로 신고한 값이라, 레지스트리 메타데이터가 자기 신고인 것과 같은 층위에 있다. MCP 공식 블로그도 2026년 3월에 같은 경계를 분명히 했다. 주석은 강제 장치가 아니며, 어떤 도구가 데이터를 빼내지 못하도록 보장해야 한다면 그것은 네트워크 통제나 샌드박스가 할 일이지 불리언 힌트가 할 일이 아니라는 것이다. 같은 글은 클라이언트마다 저 보수적 기본값을 얼마나 엄격히 지키는지가 제각각이라는 사실도 적어 두었다.

분포의 모양이 더 흥미롭다. 도구를 하나라도 광고한 194개 서버 가운데 72개는 모든 도구에 주석을 달았고, 122개는 어느 도구에도 달지 않았다. 일부만 단 서버는 이 표본에서 한 개도 관측되지 않았다. 주석을 다느냐 마느냐가 도구마다의 판단이 아니라 팀의 관행이라는 뜻이다.

이 지점에서 저자가 보인 태도가 측정 자체만큼 중요하다. 194개 전부가 전부 아니면 전무였는데도 논문은 "부분적으로만 주석을 단 서버는 없다"고 쓰지 않았다. 드문 범주를 한 번의 표본에서 하나도 못 봤다는 것은 부재의 증거가 아니라 상한의 근거일 뿐이라는 이유에서다. 194개 중 0개라는 관측에서 나오는 단측 95% 상한은 1.53%이고, 논문은 그 값을 대신 적었다. 더 눈에 띄는 것은 그다음 문장이다. 공개하지 않은 이전 실행에서는 214개를 대상으로 부분 주석 서버가 네 개 나왔는데 이번 실행은 그것을 재현하지 못했고, 저자는 그 불일치를 설명하지 않은 채 그대로 보고했다. 동료 심사를 거치지 않은 preprint라는 약점을 상쇄하는 것은 이런 종류의 기록이다. 저자는 타당성 위협을 정리한 절에서도 같은 종류의 기록을 남겼다. 이전 판에서 생태계 맥락으로 실었던 GitHub 토픽 집계가 두 번째 스윕 때 구할 수 없게 되자, 저자는 그 수치를 어떤 주장에도 쓰지 않는다고 밝혀 두었다.

3.3버전은 뒤처지기만 하는 것이 아니다

195개 서버가 협상한 프로토콜 버전은 네 가지였다. 192개가 2025-06-18이고, 2024-11-05과 2025-03-26과 2025-11-25가 각각 하나씩이다. 마지막 것은 계측기 쪽 클라이언트가 광고하는 기준선보다 오히려 새로운 버전이다. 배포된 모집단의 버전 분포가 낡은 쪽으로만 늘어진 꼬리가 아니라 양쪽으로 퍼져 있다는 뜻이라, 도구를 붙이는 쪽에서는 아래위 양방향의 호환을 함께 생각해야 한다.

사양 쪽도 그사이 더 움직였다. 2026년 9월 현재 현행 판은 2026-07-28이고, 표본의 192개가 협상한 2025-06-18은 그보다 두 판 앞선 것이다. 배포된 모집단의 무게중심은 사양이 두 번 개정되는 동안 같은 자리에 머물러 있었던 셈이다. 논문은 이 대비를 다루지 않는다. 사양 문서에서 이 글이 따로 확인했다.

여기서 논문은 계측기를 바깥으로 돌린다. 독립적으로 만들어져 실제로 배포된 서버들이 광고하는 도구 설명 2,766개를 손에 쥐었으니, 이제 도구 사용 벤치마크가 모델에게 제시하는 도구 설명과 견줘 볼 수 있다. 벤치마크를 겨눈 기존 비판은 주로 채점 쪽을 향했다. Bhat 연구진은 BFCL v4를 포함한 도구 호출 벤치마크 네 계열의 평가자를 감사해, 전문가가 검토한 과제 496개에서 평가자와 사람의 판정이 18.5% 어긋난다고 보고했다. 같은 설정을 반복 실행했을 때 점수가 18.9포인트까지 벌어진 사례도 그 감사에 실려 있다. 이 논문은 채점 기계가 아니라 채점당하는 코퍼스를 본다.

저자가 관련 연구 절에 적어 둔 한 문장이 이 방향의 위치를 알려 준다. 아는 한 이 코퍼스들 안의 중복을 측정하거나 그 도구 분포를 실제로 배포된 도구와 견줘 본 공개 연구는 없다는 것이다. 벤치마크를 의심하는 작업은 이미 여럿 있었지만 의심의 초점이 채점 쪽에 몰려 있었고, 채점당하는 쪽이 무엇으로 이뤄져 있는지는 비교 대상이 없어 묻기 어려웠다. 실제로 배포된 서버에서 도구 설명 2,766개를 손에 쥔 것이 이 논문에 그 비교 대상을 만들어 준 셈이다.

4.1잣대를 하나로 고정하고, 그 잣대를 코드에 박아 두었다

세 코퍼스는 같은 방법으로 잰다. 비교 단위는 도구 이름에 전체 설명을 이어 붙인 문자열이고, 유사도를 계산하기 전에 모든 코퍼스를 그 키로 전역 중복 제거한다. 논문이 이 절차를 규율이 아니라 코드로 강제한 이유는 실패 경험에 있다. 이 작업의 이전 반복에서 파일별로 중복 제거 키를 잡았다가 파일을 가로지르는 반복을 놓쳤고, 그 결과 측정치 하나가 14포인트 부풀려졌다. 자기가 저지른 실수를 방법론 절에 적어 두고 같은 실수를 코드로 봉한 셈이다.

비교 대상은 셋이다. 실제 MCP는 앞에서 켜진 195개 서버가 광고한 도구 2,766개다. BFCL v4는 공개된 모든 행의 함수 목록에 들어 있는 도구 정의 전량으로 8,726개다. 공개된 파일 20개 중 7개는 함수 목록 자체를 노출하지 않는데, 멀티턴 파일 네 개와 메모리 파일이 여기 포함되며 이 파일들은 계수에 기여하지 않는다. UltraTool은 영어 split의 개발 세트와 테스트 세트를 합친 모든 행의 도구 목록 전량으로 14,084개다. 소스 파일은 전부 SHA-256으로 고정해 출처 기록에 남겼다.

먼저 잰 것은 근사 중복이 아니라 완전 중복이다. 이름과 전체 설명이 글자 하나까지 똑같이 반복되는 레코드가 각 배포 파일에 얼마나 들어 있는지를 셌다.

표 2. 배포 파일 원자료의 완전 중복. 출처: arXiv:2609.10962v1 Table 2. 논문이 이 표 바로 아래에 붙인 경고를 떼어 읽으면 안 된다. 이 비율은 어느 파일을 포함하느냐에 민감하고, 한 도구를 여러 행에 재사용하는 벤치마크에서는 구성상 높게 나온다. 중복 제거 이후 수치가 훨씬 안정적이므로 둘을 함께 읽어야 한다(5절).

논문은 이 표로 벤치마크의 품질을 판정하지 않는다. 여기서 나오는 결론은 세는 절차에 관한 것이다. 전역 중복 제거 없이 이 파일들 위에서 계산한 통계는 벤치마크에 도구가 몇 개 있는지를 재지 못하고, 같은 과제가 몇 번 되풀이되는지를 잰다. "지원 도구 8,726개"라고 부르던 수가 실은 같은 도구가 행을 갈아 가며 다시 등장한 횟수였다는 이야기다.

논문이 방법론 절에서 완전 중복률을 따로 언급한 이유도 여기 있다. 저자는 이 값을 근사 중복률과 구별되는, 그리고 더 결과가 큰 양이라고 적었다. 근사 중복은 임계값을 어디에 두느냐에 따라 값이 달라지는 해석의 문제에 가깝지만, 완전 중복은 같은 문자열이 몇 번 실려 있는지를 세는 문제라 해석의 여지가 없다. 배포 파일을 그대로 읽어 무언가를 집계하는 도구나 대시보드는 이 층에서 이미 어긋난다. 임계값을 고르기 전에 이미 수가 부풀어 있는 것이다.

반대편 값도 같은 무게로 읽어야 한다. 실제 MCP 쪽 완전 중복은 2,766개 중 10개, 0.4%다. 서로 모르는 수백 명이 각자 만들어 올린 도구들이라 이름과 설명이 글자까지 똑같아지는 일이 사실상 없다. 벤치마크의 68.8%와 실제 배포 도구의 0.4%는 성실성의 차이로 벌어진 값이 아니다. 파일을 조직한 방식이 그만큼 다르다. 한쪽은 도구 하나를 과제마다 다시 실어 배포하고, 다른 한쪽은 서버마다 자기 도구 목록을 한 번씩만 광고한다. 같은 잣대로 재면 이 구조 차이가 그대로 숫자에 찍힌다.

4.2같은 숫자에서 만난 두 문서

85.6%라는 값이 파일 구조에서 나온다는 설명은 추측으로 남지 않는다. UltraTool을 만든 연구진이 자기 논문에 그 과정을 적어 두었기 때문이다. 원 논문은 질의마다 도구를 따로 만들다 보니 기능이 비슷한 도구가 벤치마크 안에 여러 개 생긴다는 문제를 인정하고, 해결책으로 Tool Merge라는 수작업 단계를 두었다고 밝힌다. 축자로 옮기면 이렇다. "각 도구가 질의마다 따로 만들어지기 때문에 벤치마크 전체에 비슷한 도구가 존재할 수 있다. 이 문제를 해결하기 위해 우리는 기능이 유사한 도구 그룹을 수작업으로 하나의 도구로 병합한다." 그리고 결과를 한 문장으로 적는다. "UltraTool에 남은 도구 집합은 2,032개의 서로 구별되는 도구를 담는다."

2,032라는 수가 이 보고서에서 가장 단단한 교차 확인이다. 이 논문은 UltraTool 원 논문의 병합 절차를 참조하지 않고, 공개된 배포 파일에서 이름과 설명을 키로 전역 중복 제거를 돌렸을 뿐이다. 그렇게 독립적으로 센 UltraTool 영어 split의 중복 제거 후 개수가 정확히 2,032개다. 서로를 모르는 두 문서가 같은 정수에서 만났다.

BFCL 쪽에는 대칭을 이루는 자기 고지가 보이지 않는다. 데이터셋 카드와 저장소 문서를 훑어도 테스트 범주들 사이에서 함수 스키마를 얼마나 공유하고 재사용하는지를 설명한 대목을 찾지 못했다. 이 부재 자체를 결함으로 읽을 일은 아니지만, 다음 절에서 볼 관측과 겹쳐 놓으면 정황상의 무게가 생긴다. UltraTool에는 "이미 병합해 두었다"는 해명이 있고 BFCL에는 그에 해당하는 문서가 없는데, 중복을 걷어낸 뒤의 그림에서 두 코퍼스가 정확히 반대로 갈라진다.

그러므로 68.8%와 85.6%를 단독으로 인용해 "이 벤치마크는 중복투성이다"라고 쓰면 논문이 명시적으로 금지한 독법이 된다. 이 두 수치가 쓰일 자리는 하나다. 전역 중복 제거를 거치지 않은 채 배포 파일 위에서 무언가를 집계하면 도구 수가 아니라 과제 반복을 세게 된다는 방법론적 경고다. 벤더가 제시하는 "지원 도구 N개"를 읽을 때 중복 제거 기준을 되묻게 만드는 것이 이 수치의 용도다.

완전 중복을 걷어내고 나면 세 코퍼스의 크기가 비슷해진다. 실제 MCP가 2,756개, BFCL v4가 2,724개, UltraTool 영어 split이 2,032개다. 앞 절에서 8,726 대 2,766으로 세 배 넘게 벌어져 보이던 규모 차이가 사실상 사라진다. 이제부터의 비교는 비슷한 크기의 코퍼스끼리 이뤄진다.

여기에 근사 중복을 잰다. 벡터화는 단어 유니그램과 바이그램에 대한 TF-IDF이고 항 빈도는 sublinear로 눌렀으며, 어휘는 코퍼스마다 따로 적합해 공유하지 않았다. 유사도는 코사인이다. 임계값에서의 중복률은 중복 제거된 도구 가운데 코사인이 그 임계값 이상인 다른 도구를 적어도 하나 가진 것의 비율로 정의된다. 논문이 굳이 정의를 본문에 적어 둔 이유는 간단하다. 정의를 조금만 바꿔도 다른 수가 나오기 때문이다.

결정적인 것은 그다음이다. 중복 상대가 같은 저작 단위 안에 있는지 바깥에 있는지로 값을 쪼갠다. 실제 MCP에서 저작 단위는 서버이고, 두 벤치마크에서는 과제 행이다. 한 프로젝트가 자기 안에서 비슷한 도구를 여러 개 만드는 일과, 서로 독립적으로 제시된 항목들이 서로를 닮는 일은 전혀 다른 사건이기 때문이다.

표 3. 전역 중복 제거 이후의 근사 중복률, 코사인 임계값별. 출처: arXiv:2609.10962v1 Table 3.

분해가 결론을 바꾼다. 실제 MCP 도구들 사이의 근사 중복은 전부 한 서버 안에 있었다. 한 프로젝트가 자연스럽게 만들어 내는 list_x, get_x, create_x 계열이 그것이다. 독립적인 저자들 사이에서는 시험한 모든 임계값에서 0.0%였다. BFCL의 중복은 정반대 종류다. 16.7포인트 가운데 16.4포인트가 서로 독립적으로 제시된 과제들 사이에 있고, 세 코퍼스 중 유일하게 코사인 0.90에서도 근사 중복이 살아남는다. 그리고 UltraTool은 0.3%로, 실제로 배포된 도구들보다 깨끗하다.

논문은 이 그림에서 끌어낼 수 있는 주장과 끌어낼 수 없는 주장을 직접 갈라 놓았다. 두 문장이 그 경계다.

5.1저자가 자기 결과를 먼저 흔들어 본 자리

"저자들 사이에서 0.0%"라는 값은 그대로 두면 의심스럽다. 코드 수준에서 보면 MCP 생태계에 클론이 흔하다는 별개의 측정이 이미 나와 있기 때문이다. Kim 연구진은 MCP 저장소 7,508곳에서 도구 87,564개를 추출해 어휘 유사도와 퍼지 구조 유사도로 재고, 표본을 사람이 직접 확인해 고-Jaccard 후보의 60%와 고-ssdeep 후보의 85%가 진짜 클론이라고 보고했다. 그 결과와 이 논문의 0.0%가 어떻게 같이 성립하는가가 문제가 된다.

저자는 이것을 타당성 위협으로 세우고 세 방향에서 직접 검정했다. 첫째, 기동한 서버와 기동하지 못한 서버 모두에 존재하는 npm 패키지 설명을 기준으로 재 보니 두 집단 다 모든 임계값에서 0.0%였다. 다만 이 검정은 코드가 아니라 설명을 읽는 데다 양쪽이 모두 0이라 검정력이 낮다고 저자가 스스로 적었다. 둘째, npm 스코프로 본 저자 가족의 집중도가 두 집단에서 비슷했다. 표본에서 가장 큰 가족인 패키지 7개가 전원 포함됐고, 그다음 8개는 전원 제외됐다. 셋째로 가장 직접적인 검정은, 전부 기동한 서버를 가장 많이 낸 저자가 서버 7개에 도구 125개를 올렸는데 그 서버들 사이의 최대 코사인이 0.623으로 보고된 가장 낮은 임계값에도 못 미쳤다는 것이다. 결론은 필터가 클론을 골라 버린다는 증거를 찾지 못했다는 데까지이고, 논문은 여기에 놓친 경우를 덧붙인다. 구현은 베끼면서 도구 설명은 새로 쓰는 클론이라면 이 방법은 놓치고 저쪽 방법은 잡는다. 만약 실제로 그렇다면, 코드 수준 중복과 인터페이스 수준 중복의 간극 자체가 보고할 만한 결과라고 적어 두었다.

나머지 검정도 결과를 깎는 쪽으로 작동한다. 중복 제거 뒤 BFCL은 과제 행당 평균 1.8개 도구를 갖고 실제 MCP는 서버당 14.2개를 갖는다. 같은 단위 쌍을 빼는 조작이 BFCL에서는 구성상 훨씬 적게 깎아 내므로, BFCL의 과제 간 수치가 전체 수치에 거의 붙어 있는 것은 부분적으로 이 비대칭의 산물이다. 반대로 실제 MCP가 2.8%에서 0.0%로 무너지는 것은 방향이 반대라 이 비대칭으로 설명되지 않는다. 큰 서버가 비율을 끌어올렸을 가능성도 따로 쟀다. 서버당 도구를 10개, 25개, 50개로 상한을 걸면 임계 0.70에서 0.9%, 2.2%, 3.0%가 나와 무제한일 때의 2.8%를 둘러싼다. 도구 300개와 122개를 광고한 두 서버가 만든 값이 아니다. 마지막으로 TF-IDF 코사인은 어휘 겹침을 잴 뿐 의미 동치를 재지 않으므로, 같은 일을 다른 말로 하는 두 도구는 모든 코퍼스에서 따로 세어진다. 세 비율 모두 실제보다 낮게 나오는 방향으로 편향돼 있고, 그 편향이 코퍼스마다 다르게 걸릴 이유는 없지만 그렇지 않다는 것을 보인 것도 아니라고 논문은 적는다.

표집 이야기가 나온 김에 덧붙이면, 이 블로그는 무작위 표본이 영리한 표집을 이긴 데이터 품질 벤치마크를 다룬 적이 있다. 두 글의 결론을 같은 말로 뭉개지 않는 편이 좋다. 그 글은 데이터를 고르는 기법이 기대만큼 작동하지 않은 경우를 다뤘고, 이 글은 애초에 무작위로 뽑아야만 잴 수 있는 양이 따로 있다는 이야기다. 겹치는 것은 표본을 어떻게 잡았는지를 먼저 물어야 한다는 순서뿐이다.

앞의 측정을 둘러싼 배경은 두 번의 완전 스윕이 그린다. 2026년 7월 14일에 16,548개였던 서버가 8월 22일에 24,135개가 됐다. 39일 동안 하루에 약 195개씩 순증한 셈이고, 두 스윕 모두 중단 없이 끝까지 돌았다. 같은 두 시점에서 배포 모델의 구성도 함께 기록됐다.

표 4. 39일 간격 두 번의 완전 스윕에서 본 배포 모델. 출처: arXiv:2609.10962v1 Table 4, §7.

이 창 안에서 원격 전용이 패키지 전용을 앞질렀다. 증가율로는 70.1% 대 26.3%다. 다만 논문은 여기서 한 발 물러선다. 스냅샷 두 개로는 추세를 세울 수 없고 자기들은 추세를 주장하지 않으며, 측정된 두 끝점 사이의 변화를 보고할 뿐이라고 적었다. 그러니 이 표를 "원격으로 옮겨 가는 추세"라고 옮겨 쓰면 원문보다 한 칸 더 나간 말이 된다.

방법론 쪽 결과는 이 논문 자신을 겨눈다. 로컬 행동 관측 계측기가 닿을 수 있는 npm·stdio 조각은 절대수로는 5,804개에서 7,414개로 늘었지만, 모집단에서 차지하는 비중은 35.1%에서 30.7%로 떨어졌다. stdio만 다루는 계측기는 줄어드는 소수를 잰다. 논문은 이 제약이 남이 아니라 자기 자신의 행동 관측 층에도 똑같이 걸린다고 밝힌다. 같은 방법을 내년에 다시 쓰면 더 작은 조각만 재게 된다.

계측 조건 자체가 낡아 가는 축도 있다. 이 측정에서 포함과 제외를 가른 기준은 초기화 핸드셰이크의 완료인데, 현행 사양 판인 2026-07-28은 그 핸드셰이크를 없앴다. initialize와 notifications/initialized를 걷어내고 요청마다 프로토콜 버전과 클라이언트 능력을 메타 필드에 실어 보내는 방식으로 바꿨으며, 서버가 지원 버전과 능력과 신원을 알리는 server/discover를 반드시 구현하도록 했다. 옛 판을 쓰는 서버와의 호환 경로가 사양에 함께 적혀 있고 표본의 195개는 전부 옛 판을 협상했으니 이 측정이 흔들리지는 않는다. 다만 48.8%가 무엇의 비율인지는 판본과 함께 읽어야 한다. 이 개정판도 논문에는 없다. 날짜가 두 스윕 사이에 놓인 판이라 이 글이 사양 문서에서 확인했다.

6.1레지스트리는 심사 기관이 아니라 카탈로그다

이 측정이 드러낸 공백을 공식 문서는 이미 예고해 두었다. modelcontextprotocol/registry 저장소의 README는 레지스트리를 MCP 클라이언트에게 서버 목록을 제공하는 앱스토어 같은 것으로 정의한다. 발견을 돕는 카탈로그이지 심사 기관이 아니라는 뜻이다. 문서가 말하는 "검증"도 등록 시점의 스키마 형식 검사까지이고, 서버가 실제로 기동하는지나 도구가 안전한지를 미리 살피는 기능적 심사 절차는 문서에 존재하지 않는다. 레지스트리 운영은 커뮤니티 워킹그룹이 맡고 있으며, API는 2025년 10월 24일부로 v0.1에서 동결된 상태다. 같은 문서는 레지스트리가 2025년 9월 8일 프리뷰로 출범했고 일반 공개 판은 그 뒤에 온다고 적어 두었다. 논문이 두 번 훑은 대상은 아직 프리뷰 단계의 인프라였다. 2025년 12월 9일에 MCP가 리눅스 재단 산하 Agentic AI Foundation으로 넘어간 뒤에도 이 설계는 그대로다. 거버넌스 주체가 바뀌었다고 자기 신고 구조가 바뀐 것은 아니다.

다른 층에서 온 관측도 같은 방향을 가리킨다. Padilla는 인터넷에 노출된 MCP 서버 414개를 동적으로 감사해 신고 가능한 취약점 68건을 찾았고, 확인된 서버의 41.6%가 연속된 측정 회차 사이 사흘 안에 사라졌다고 보고했다. 이 논문이 로컬 층에서 본 37.5%의 기동 실패가 시사하는 이탈을, 원격 층에서 독립적으로 방증하는 값이다. 레지스트리 설명의 노후화를 89일 동안 추적한 Bharti의 측정도 같은 그림에 속한다. 설명을 한 번이라도 고쳐 쓴 서버는 8.6%뿐이었고, 가장 활발한 5%가 전체 변경 이벤트의 61%를 만들어 냈다. 등록 정보는 대개 등록된 그 순간에 멈춰 있다는 뜻이다.

덧붙여 "MCP 서버가 몇 개인가"라는 질문 자체가 집계 주체마다 다른 답을 낸다. 공식 레지스트리 API를 훑은 수, 서드파티 디렉터리가 크롤링한 수, 벤더가 발표한 활성 서버 수가 각기 다른 모집단을 센다. 이 글이 본문 수치로 쓰는 것은 논문 자신이 전수 스윕으로 센 두 값뿐이다.

6.2시장은 이미 게이트웨이로 답하고 있다

"레지스트리를 그대로 믿지 말고 검증 계층을 하나 더 두라"는 결론에 시장은 이미 제품으로 답해 왔다. 2026년 MCP 인프라는 스스로를 세 층으로 나눈다. 호출 통제 없이 발견만 돕는 공개 레지스트리, 조직이 승인한 서버만 내부 카탈로그로 노출하는 엔터프라이즈 레지스트리, 신원과 권한과 정책 집행까지 런타임에서 거는 게이트웨이다. 다만 이 카테고리에서 확률 표집으로 잰 가동률을 공개한 벤더는 하나도 없다. 내세우는 말은 대개 "검증됨" 같은 정성적 표현이다. 그 간극에 이 논문이 서 있다.

국내 사례 둘이 노출 폭 설계의 양 끝을 보여 준다. MCP 데브 서밋 2026 발표를 전한 보도에 따르면, 네이버클라우드는 대외 공개 API와 내부 API를 합쳐 1만 개가 넘는 규모를 운영하면서도 MCP 게이트웨이가 사용자에게 외부로 내보이는 도구는 두 개뿐이다. 나머지는 시맨틱 검색으로 그때그때 요청에 맞는 도구를 골라 붙인다. 반대쪽에는 카카오 PlayMCP가 있다. 2025년 8월 13일 베타를 열어 외부 개발자에게 등록을 개방했고, 2026년 5월 1일 업데이트 기준으로 외부 MCP 서버 약 200개가 올라와 있다. 노출 표면을 극단으로 좁히는 쪽과 열어 두고 키우는 쪽, 두 전략 사이 어딘가에 각자의 답이 놓인다.

페블러스가 DataClinic에서 해 온 일은 "이 데이터셋이 쓸 만한가"를 눈대중이 아니라 계측으로 답하는 것이다. 이 논문은 같은 일을 도구 목록에 했다. 그래서 이 측정이 페블러스와 닿는 지점은 MCP라는 주제보다 자산을 재는 방식 쪽이다.

7.1에이전트 시대의 자산 목록에는 도구가 들어온다

레지스트리에 등록된 24,135개는 카탈로그이지 검증된 자산이 아니다. 확률 표집으로 재 보니 절반이 켜지지도 않았다. AI-Ready Data를 "모델이 바로 쓸 수 있는 상태"로 정의해 왔다면, 에이전트가 일하는 환경에서 그 정의가 덮어야 할 목록에는 데이터셋만이 아니라 도구가 함께 들어온다. 그리고 도구도 데이터셋과 같은 질문을 받아야 한다. 스키마는 맞는가, 의미를 알려 주는 주석은 붙어 있는가, 실제로 호출되는가. 이 논문이 쌓아 올린 세 층의 계측, 곧 기동과 스키마와 주석은 DataClinic이 데이터셋에 적용해 온 진단 계층과 구조가 같다.

7.2평가 데이터의 구성이 점수의 뜻을 정한다

글의 후반부가 페블러스의 오랜 축과 정확히 겹친다. 도구 사용 벤치마크의 배포 파일을 전역 중복 제거 없이 집계하면, 우리가 도구 목록이라고 부르던 것이 실은 과제 반복이었다. 평가 데이터셋의 구성이 점수의 의미를 정한다는 명제가 에이전트 도구 영역에서 다시 확인된 셈이다.

동시에 이 논문은 그 명제를 과잉 적용하지 말라고도 가르친다. 같은 표 안에서 UltraTool은 실제 배포 도구보다 깨끗했다. 합성은 나쁘고 실제는 좋다는 결론이 아니라, 어느 코퍼스든 같은 잣대로 재 보기 전에는 알 수 없다는 결론이다. 합성데이터를 다루는 쪽에서 지켜야 할 태도에 이쪽이 훨씬 가깝다. 여기에 3절의 대비를 겹치면 한 문장이 남는다. 품질은 검증할 수 있는 층에서만 실제로 지켜진다.

7.3도구를 붙이는 팀이 당장 쓸 수 있는 네 가지

사내 에이전트에 외부 도구를 연결하려는 팀에게 이 측정은 구체적인 절차를 남긴다. 네 항목 모두 이 글에 나온 수치에서 곧바로 따라 나온다.

• 도입 전에 직접 띄워 본다. 레지스트리 목록을 그대로 신뢰하는 대신 자체 프로빙으로 기동과 핸드셰이크를 확인한다. 실측 기대값은 절반이다.
• 주석이 없는 도구는 위험한 쪽으로 가정한다. 이것은 신중한 태도이기 이전에 사양이 정해 둔 기본값이다. 주석이 비어 있으면 규격상 그 도구는 되돌릴 수 없는 변경을 할 수 있고 외부 세계와 상호작용하는 도구로 읽힌다. 주석은 서버 단위로 전부 있거나 전부 없는 경향이라, 서버 하나를 검토할 때 한 번에 확인할 수 있다.
• 레지스트리 메타데이터를 검증 대상으로 본다. 전송 방식과 상태 선언은 자기 신고이고, 잘못 선언한 서버도 선언한 대로 계수된다.
• "지원 도구 N개"에는 중복 제거 기준을 묻는다. 같은 도구가 여러 행에 반복된 수일 수 있다는 것을 4절이 숫자로 보여 준다.

7.4재는 쪽에 서 왔다면 이 자리가 비어 있다

페블러스는 그동안 데이터가 준비됐는지를 재 왔다. 도구 생태계가 39일 만에 7,587개 늘고 두 스냅샷 사이에 원격 전용이 패키지 전용을 앞지른 지금, 도구도 재야 할 자산이라는 자리는 아직 비어 있다. 검증된 카탈로그를 파는 벤더는 여럿이지만 확률 표집으로 가동률을 공개한 곳은 없다는 사실이 그 공백의 크기다.

읽어 주셔서 감사하다.

본문 수치는 네 갈래에서 왔다. 1차 출처인 arXiv:2609.10962v1은 HTML 전문을 내려받아 절과 표 단위로 대조했고, 텍스트 추출에서 떨어지는 수식 노드의 값은 따로 복원해 확인했다. 이 논문이 인용한 인접 연구 다섯 편은 요약을 믿지 않고 각 arXiv 페이지를 2026년 9월 14일에 직접 열어 수치를 다시 확인했다. UltraTool의 "Tool Merge"와 2,032개라는 값은 원 논문 본문에서 문장을 그대로 확인한 것이다. 주석의 기본값과 신뢰 범위, 그리고 사양 개정 이력은 논문이 다루지 않는 대목이라 MCP 사양 문서와 스키마 파일, 공식 블로그를 2026년 9월 14일에 직접 열어 확인했다. 레지스트리 정책과 국내 사례는 공식 문서와 공식 뉴스룸, 발표를 전한 보도를 경로로 밝혀 인용했다.

1차 출처

• 1.Haseeb Mohammed Afsar. "What a Random Draw from the MCP Registry Contains, and What Tool-Use Benchmarks Contain Instead." arXiv:2609.10962v1 [cs.SE], 2026년 9월 10일, CC BY 4.0. 독립 연구자 1인, 동료 심사 전 preprint. 표 1~4, Figure 1~3, §3 방법, §4~6 결과, §8 타당성 위협을 이 문서에서 확인했다. 2026년 9월 14일 확인 시점에 v1이 유일한 판본이다.
• 2.Haseeb Mohammed Afsar. mcp-probe: a conformance and reliability checker for Model Context Protocol servers (software and dataset). Zenodo, 2026. concept DOI 10.5281/zenodo.21347997, 코드 github.com/itguruhaseeb/mcp-probe — 계측기, 수집기, 시드 추출 스크립트, 집계 스크립트, 타당성 검정 묶음.

인접 측정 연구 (각 원문 재확인)

• 3.Pei Chen 외 8인. "Rethinking MCP Security: A Large-Scale Study of Runtime MCP Servers and Security Scanner Reliability." arXiv:2607.11086 (2026) — 저자들이 스스로 MCPZoo라 부르는 수집물. 고유 서버 64,611개 수집, 수리를 거쳐 동적 분석이 가능한 37,288개 이상 확보. 기존 스캐너가 96.89%의 서버를 위험하다고 보고하지만 표본 경보 중 수동 검증을 통과하는 것은 절반 미만이라는 결과도 같은 논문에 있다.
• 4.Gautam Bharti. "Registry Descriptions Go Stale Unevenly: An 89-Day Measurement of Model Context Protocol Drift, and Why Drift-Ranked Re-Auditing Under-Covers It." arXiv:2608.00997 (2026) — 88.6일 동안 120개 스냅샷, 서버 19,099개. 설명을 한 번이라도 고쳐 쓴 서버 8.6%, 가장 활발한 5%가 변경 이벤트의 61% 생성. 제목은 89일, 본문은 88.6일로 적혀 있다.
• 5.Nicolás Padilla. "Exposed by Design: A Dynamic Security Assessment of Internet-Facing MCP Servers at Scale." arXiv:2608.00150 (2026) — 인터넷 노출 서버 414개 동적 감사, 신고 가능한 취약점 68건, 확인된 서버의 41.6%가 연속 측정 회차 사이 사흘 안에 소멸.
• 6.Taein Kim, David Jiang, Yuepeng Hu, Yuqi Jia, Neil Gong. "Evaluating Tool Cloning in Agentic-AI Ecosystems." arXiv:2605.09817 (2026) — MCP 저장소 7,508곳에서 도구 87,564개 추출, 고-Jaccard 후보의 60%와 고-ssdeep 후보의 85%를 사람이 진짜 클론으로 확인. 초록 첫머리의 "원 도구 수는 생태계 다양성을 크게 부풀릴 수 있다"는 문장이 이 글 4절의 문제의식과 맞닿는다.
• 7.Vishvesh Bhat, Jay Vaghasiya, Muhammad Ahmed Mohsin, Asad Aali. "Benchmarking the Benchmarks: A Validity Audit of Tool-Calling Evaluation." arXiv:2607.02577 (2026) — BFCL v4, τ2-Bench, LiveMCPBench, MCP-Atlas 네 계열의 평가자 감사. 전문가 검토 과제 496개에서 평가자와 사람의 불일치 18.5%, LiveMCPBench 반복 실행에서 점수 폭 18.9포인트(57.9%~76.8%).

벤치마크 코퍼스 원출처

• 8.Shijue Huang 외 12인. "Planning, Creation, Usage: Benchmarking LLMs for Comprehensive Tool Utilization in Real-World Complex Scenarios." arXiv:2401.17167 (2024) — UltraTool 원 논문. 데이터 구성 절에 "기능이 유사한 도구 그룹을 수작업으로 하나의 도구로 병합한다"는 Tool Merge 절차와 "UltraTool에 남은 도구 집합은 2,032개의 서로 구별되는 도구를 담는다"는 문장이 있다. 이 글 4.2절의 교차 확인 근거다.
• 9.Berkeley Function Calling Leaderboard v4 평가 데이터. Gorilla 프로젝트 저장소 github.com/ShishirPatil/gorilla (논문 접근일 2026년 8월 22일).
• 10.UltraTool 영어 데이터셋. 저장소 github.com/JoeYing1019/UltraTool (논문 접근일 2026년 8월 22일).

사양·레지스트리·거버넌스

• 11.Model Context Protocol Specification, 개정판 2025-06-18, Server / Tools (확인 2026년 9월 14일) — 표본의 192개 서버가 협상한 바로 그 판본. annotations가 선택 항목이라는 규정과 "클라이언트는 신뢰할 수 있는 서버에서 온 것이 아닌 한 도구 주석을 신뢰하지 않는 것으로 간주해야 한다(MUST)"는 경고가 이 절에 있다. 주석 네 종의 기본값(readOnlyHint false, destructiveHint true, idempotentHint false, openWorldHint true)은 같은 개정판의 schema.ts ToolAnnotations 주석에 명시돼 있다. 본문에 나오는 사양 날짜 2024-11-05, 2025-03-26, 2025-06-18, 2025-11-25도 실재하는 개정판이다.
• 12.Model Context Protocol Specification. Versioning 및 2026-07-28 Key Changes (확인 2026년 9월 14일) — 2026년 9월 현재 현행 판은 2026-07-28이다. SEP-2575로 initialize·notifications/initialized 핸드셰이크를 없애고 요청마다 _meta에 프로토콜 버전과 클라이언트 능력을 싣도록 바꿨으며, 서버가 지원 버전·능력·신원을 알리는 server/discover를 필수로 두었다. 옛 개정판과의 호환 경로도 같은 문서에 있다. 이 논문은 이 개정판을 다루지 않으므로 3.3절과 6절의 해당 서술은 이 글이 사양 문서에서 직접 확인한 것이다.
• 13.Ola Hungerford, Sam Morrow, Luca Chang. "Tool Annotations as Risk Vocabulary: What Hints Can and Can't Do." MCP 공식 블로그, 2026년 3월 16일 — "기본값은 의도적으로 신중하다. 주석이 없는 도구는 읽기 전용이 아니고, 파괴적일 수 있으며, 멱등하지 않고, 열린 세계와 닿는 것으로 간주된다"는 정리와 "주석은 강제 장치가 아니다"라는 한계 선언이 여기 있다. 서버마다 주석 적용이 고르지 않고 클라이언트마다 기본값을 지키는 엄격함이 다르다는 서술도 같은 글이다.
• 14.modelcontextprotocol/registry GitHub README (확인 2026년 9월 14일) — 레지스트리를 "MCP 서버를 위한 앱스토어 같은" 서버 목록 서비스로 정의. 문서상 "validation"은 등록 시 스키마 형식 검증까지이며 기능적 사전 심사 절차는 없다. 2025년 9월 8일 프리뷰 출범, API는 2025년 10월 24일부로 v0.1 동결이며 일반 공개 판은 이후로 예고돼 있다.
• 15.Anthropic. "Donating the Model Context Protocol and Establishing the Agentic AI Foundation." anthropic.com, 2025년 12월 9일 — 리눅스 재단 산하 Agentic AI Foundation 이관. 같은 글에 "활성 공개 MCP 서버 1만 개 이상"과 "월 9,700만 회 이상 SDK 내려받기"가 적혀 있다.

업계·국내 맥락

• 16.CIO.com. MCP 데브 서밋 2026 보도, 2026년 8월 18일. cio.com — 네이버클라우드 게이트웨이 사례("1만 개가 넘는 내외부 API 중 외부 노출 도구는 2개"). 이 글은 발표 자체가 아니라 발표를 전한 보도를 경로로 인용했다.
• 17.카카오 뉴스룸. PlayMCP 베타 오픈(2025년 8월 13일) 및 현황 업데이트(2026년 5월 1일) — 외부 MCP 서버 약 200개.
• 18.NimbleBrain. "State of MCP Security." nimblebrain.ai, 2026년 3월 — 공식 레지스트리 공개 API 전수 조회(레코드 8,074건, 고유 서버 3,012개). "레지스트리는 서버를 나열할 뿐 평가하지 않는다"는 지적.

페블러스 인접 글

• 19.페블러스 블로그. 실제로 불러 본 연결만 남겨 만든 공공 API 학습 데이터 — 같은 문제의식의 다른 층위. 측정 단위가 달라 이 글의 수치와 나란히 놓고 비교할 수 없다.
• 20.페블러스 블로그. 무작위 표본이 영리한 표집을 이긴 데이터 품질 벤치마크 — 표집 설계가 결론을 만든다는 같은 축의 다른 사례.
• 21.페블러스 블로그. 온라인에 공개된 에이전트 스킬의 27%를 걸러 낸 화이트리스트 — 레지스트리 신뢰도의 보안 측면. 공급망 사고의 구체적 경위는 그 글에서 다뤘다.
• 22.페블러스 블로그. 한 재단에 모인 MCP와 구글 A2A, 인가 정책은 표준 밖에 남았다 — MCP 거버넌스 이관의 배경.