저는 공식 레지스트리에 나열된 모든 원격 MCP 서버 — 10,716개의 엔드포인트(endpoints) — 를 조사했고, 집계된 수치 뒤에 숨겨진 질문을 던졌습니다: 등록된 항목이 작동하지 않게 되었을 때, 그것은 어디에 호스팅되어 있는가?

그 답은 고르게 분포되어 있지 않습니다. 고르게 분포되어 있는 것과는 거리가 아주 멉니다.

호스팅 플랫폼별 실패율

하드 404(hard 404)를 반환하거나, DNS 실패, 타임아웃(timeout), 연결 거부, 또는 5xx 오류를 발생하는 엔드포인트를 실패로 간주하여 계산하면 다음과 같습니다:

Vercel에 있는 MCP 서버는 Cloudflare 퀵 터널(quick tunnel) 뒤에 있는 서버보다 응답할 확률이 대략 11배 더 높으며, Smithery에 있는 서버보다는 약 10배 더 높습니다.

이것은 엔지니어링 품질에 대한 이야기가 아닙니다. 그것은 각각의 서비스가 _무엇인지_에 대한 이야기입니다.

패턴은 품질이 아니라 휘발성입니다

trycloudflare.com URL은 퀵 터널(quick tunnels)에서 생성됩니다. 이는 일시적으로 사용되도록 설계되었으며, 재시작할 때마다 호스트 이름(hostname)이 변경됩니다. ngrok 무료 터널도 같은 개념입니다. Railway와 Render의 무료 티어(free tiers)는 절전 모드로 전환되거나 회수될 수 있습니다. 이들 중 어느 것이라도 URL은 누군가가 영구적인 공개 디렉토리에 붙여넣은 개발 편의용 도구일 뿐입니다.

Vercel과 workers.dev는 다르게 동작합니다. URL이 안정적이고, 무료 티어에서 호스트 이름이 만료되지 않으며, 트래픽을 받지 않는 배포(deployment)라도 여전히 도메인이 해석(resolve)됩니다.

따라서 레지스트리는 버려진 프로젝트로 가득 찬 것이 아니라, 애초에 앞문(front door)이 영구적이지 않았던 프로젝트들로 가득 차 있는 것입니다. 코드는 멀쩡할 수 있습니다. 다만 등록된 정보가 이미 옮겨진 문을 가리키고 있을 뿐입니다.

특정 영역에 집중되어 있습니다

레지스트리의 1,490개 엔드포인트는 가장 강력한 의미에서 작동하지 않습니다 — 광고된 경로에서 하드 404가 발생하거나, 더 이상 DNS가 해석되지 않는 경우입니다. 이들은 단 343개의 도메인에 퍼져 있으며, 상위 10개 도메인이 그중 67%를 차지합니다:

191  smithery.ai
173  railway.app
125  wishpool.app
...

이들 중 상당수는 MCP 엔드포인트 (endpoints)를 대량으로 생성하는 플랫폼들입니다. 이 플랫폼 중 하나가 URL 스킴 (URL scheme)을 변경하거나 티어 (tier)를 만료시키면, 수백 개의 레지스트리 (registry) 항목이 한꺼번에 깨집니다. 이는 URL을 해결 (resolving)하는 대신 단순히 저장만 하는 디렉토리 (directory)에서 발생하는 실패 모드 (failure mode)입니다.

177개의 리스팅은 실제 URL이 아예 없었습니다

실패 사례들을 분류하던 중, URL에 여전히 치환되지 않은 템플릿 변수 (template variables)가 포함된 항목들을 발견했습니다:

...

177개의 리스팅이 플레이스홀더 (placeholder), localhost, 또는 example.com을 포함하고 있습니다. 그중 73개는 명백한 이유로 DNS 오류가 발생합니다.

흥미로운 부분은 나머지 절반입니다. 이 중 14개는 작동 중입니다. https://mcp.cardog.io/mcp?api_key={api_key}와 같은 URL이 작동하는 이유는, 플레이스홀더가 서버가 부재 시 무시하는 쿼리 파라미터 (query parameter)에 있기 때문입니다. 작성자는 이를

registry.modelcontextprotocol.io에 있는 모든 활성 원격 엔트리(remote entry)를 URL 기준으로 중복 제거한 결과 — 10,716개의 엔드포인트(endpoint)가 확인되었습니다. 각 엔드포인트에 대해 익명 JSON-RPC initialize 요청을 한 번씩 보냈으며, 10초의 타임아웃(timeout)을 설정하고 실제 응답에 따라 분류했습니다. 전송 방식(Transport)을 고려하면, 레지스트리(registry)는 9,647개의 streamable-http와 1,068개의 레거시(legacy) sse 원격 엔트리를 선언하고 있습니다. 또한 레거시 전송 방식은 POST가 아닌 GET으로 열리기 때문에, 단일 동사(verb)로 모든 것을 조사하면 405/404 오류 횟수가 부풀려집니다. 저는 이 부분을 구체적으로 확인했습니다. 결과적으로 거의 변한 것은 없었지만, 게시한 후가 아니라 게시하기 전에 확인했습니다.

익명 프로빙(Anonymous probing)은 하한선입니다. 키(key)를 요구하는 서버는 죽은 것이 아니라 '살아있지만 차단된(alive-but-gated)' 상태로 집계되며, 키 너머에서 서버가 정상(healthy)인지 여부는 확인할 수 없습니다.

수치는 특정 시점의 기록일 뿐입니다. 재실행하는 것이 핵심입니다. 움직이는 시스템의 단일 스냅샷(snapshot)은 소수점 아래 숫자가 붙은 일화(anecdote)에 불과합니다.

이전 글: 공식 레지스트리의 모든 MCP 서버를 확인했습니다 — 이 분석의 토대가 된 인구 조사이며, 첫 번째 시도가 레지스트리의 3%만을 다루었음에도 '모든' 서버라고 게시했던 오류를 수정한 내용이 포함되어 있습니다.