AI 에이전트가 다른 MCP 서버를 발견하고, 평가하고, 설치하는 데 도움을 주는 MCP 서버입니다.
MCPfinder는 공식 MCP 레지스트리(Official MCP Registry)와 Glama 위에 구축된 AI 우선 검색 계층(AI-first discovery layer)입니다. 한 번 설치하면, 사용자의 어시스턴트가 누락된 기능(missing capabilities)을 검색하고, 신뢰 신호(trust signals)를 검사하며, 필요한 비밀 정보(required secrets)를 검토하고, 클라이언트별 MCP 설정 스니펫(config snippets)을 생성할 수 있습니다.
- 표준 전송 방식 (Canonical transport):
stdio
npx -y @mcpfinder/server를 통해 사용합니다.
-
표준 패키지 (Canonical package):
@mcpfinder/server
-
MCP 레지스트리 항목 (MCP Registry entry):
dev.mcpfinder/server
-
공개 HTTP 엔드포인트 (Public HTTP endpoint): 도구 표면(tool surface)이 로컬 서버와 완전히 동일해질 때까지는 의도적으로 표준으로 광고하지 않습니다.
{
"mcpServers": {
"mcpfinder": {
...
{
"mcpServers": {
"mcpfinder": {
...
{
"mcpServers": {
"mcpfinder": {
...
오늘 지원되는 설치 대상:
- Claude Desktop
- Cursor
- Claude Code
- Cline / Roo Code
- Windsurf
사용자의 에이전트가 Agent Skills 형식을 지원한다면 (Claude Code, VS Code의 GitHub Copilot, OpenAI Codex 등), 한 줄 설치만 하면 되며 에이전트가 설정 병합(config merge)을 자체적으로 처리할 수 있습니다.
Claude Code (글로벌):
mkdir -p ~/.claude/skills/install-mcpfinder && \
curl -sSf -o ~/.claude/skills/install-mcpfinder/SKILL.md \
VS Code (프로젝트 범위):
mkdir -p .agents/skills/install-mcpfinder && \
curl -sSf -o .agents/skills/install-mcpfinder/SKILL.md \
그런 다음 에이전트에게 *
• 사용자에게 설정 파일에 붙여넣을 내용을 알려주기 전에 get_install_config를 호출합니다.
• 사용자가 특정 기술이 아닌 도메인만 알고 있는 경우: browse_categories를 호출합니다。
(카테고리를 생략하면 목록 표시; 카테고리를 전달하면 상위 서버용)
선호되는 작업 흐름:
search_mcp_servers(query="postgres")
get_server_details(name="...최적 후보...")
get_install_config(name="...최적 후보...", platform="claude-desktop")
• 사용자에게 선택한 서버, 그 이유, 필요한 또는 선택적인 자격 증명(credentials), 그리고 필요한 재시작/재로드 단계에 대해 알려줍니다.
| 도구 | 목적 | 호출 시점 |
|---|
search_mcp_servers | 키워드, 기술 또는 사용 사례별 검색 | 기능이 누락되었을 때 첫 번째 단계 |
get_server_details | 메타데이터, 신뢰 지표(trust signals), 도구, 경고, 로컬 환경 변수 및 원격 HTTP 헤더 검사 | 추천하거나 설치하기 전에 |
get_install_config | 대상 클라이언트를 위한 JSON 설정 조각 생성 | 서버를 선택한 후 |
browse_categories | 단일 호출 카테고리 브라우저 (카테고리를 생략하면 목록 표시; 상위 서버용으로 카테고리를 전달) | 도메인 기반 발견 |
MCPfinder는 에이전트 사용에 최적화되었습니다.
• 사람이 읽기 쉬운 텍스트 요약
• 후속 호출 체이닝을 위한 구조화된 콘텐츠
• 신뢰 지표: 출처 수, 공식 존재 여부, 최신성 (검증 및 인기 필드는 Smithery가 유일한 출처였으나 사라졌으므로 출력 시 비어 있습니다)
• 경고 플래그: 오래된 프로젝트, 누락된 저장소 URL, 불분명한 설치 경로, 단일 출처 전용
• 설치 메타데이터: 설정 조각, 대상 파일 경로, 로컬 프로세스 변수 또는 원격 HTTP 헤더, 자격 증명 요구 사항, 재시작 지침
로컬 명령 서버의 경우, env가 실행되는 프로세스를 구성합니다. 원격 HTTP 서버의 경우, headers가 선택된 엔드포인트로의 요청을 구성하며, 로컬 프로세스 env
블록은 해당 연결을 인증하지 않습니다. MCPfinder는 생성된 원격 JSON에 명시적으로 요구되는 레지스트리 헤더를 포함하며, 선택적 헤더는 별도로 나열합니다. 따라서 선택적 API 키는 클라이언트가 지원하는 경우 서버의 OAuth 로그인 경로를 차단하지 않습니다. 서버가 게시한 헤더 템플릿이나 지침은 값이 Bearer와 같은 접두사를 필요로 하는지 여부를 결정하며, 생성기는 Authorization만으로는 이를 가정하지 않습니다.
검색 순위는 다음을 사용합니다:
-
텍스트 관련성 (text relevance)
-
이름 일치 부스트(name-match boost) — 호스팅 접두사가 제거된 이름과 비교하여 측정됩니다 (io.github.<owner>/<repo> →<owner>/<repo>, ai.smithery/<slug> →<slug>). 이 선행 세그먼트는 Official registry가 서버의 코드가 호스팅되는 위치를 나타내기 위해 할당한 역방향 DNS 네임스페이스입니다 —io.github.* 서버는 모두 Official에서 오며, 일부 "GitHub" 레지스트리에서 오는 것이 아니며, 서버가 무엇을 하는지에 대해서는 아무것도 말해주지 않습니다. 카탈로그의 19.6%가 io.github.%로 이름 지어졌기 때문에, 이를 점수화하는 과정은 부스트를 상수로 만들고 모든 실제 일치를 매장시켰습니다. 소유자 세그먼트는 유지되므로, 소유자로 검색하는 것은 여전히 작동합니다. 호스팅 네임스페이스로 검색할 방법은 없습니다: registrySource 필터는 항목이 발견된 레지스트리(official/glama)를 필터링하며, 이는 다른 문제입니다.
-
Official registry 존재 여부
-
커뮤니티 사용량 (useCount) 및 검증 신호 — 현재 항상 0입니다: Smithery가 유일한 출처였습니다.
각 결과에는 다음 정보도 주석 처리됩니다:
confidenceScore
recommendationReason
warningFlags
updatedAt
sourceCount
MCPfinder는 다음과 같은 정보를 집계합니다:
Smithery는 2026-10-31에 API, 프록시 및 호스팅 서버 URL이 작동을 멈춘다고 발표할 때까지 세 번째 출처였습니다 (https://smithery.ai/). MCPfinder는 더 이상 이를 동기화하지 않으며, 폐지된 Smithery 호스트(server.smithery.ai, *.run.tools, registry.smithery.ai)의 원격 URL은 Official Registry나 Glama가 여전히 광고하더라도 삭제됩니다 (packages/core/src/remote-url.ts).
카운트는 시간에 따라 달라지며, 원본 업스트림 레코드(raw upstream records)를 계산하는지 아니면 병합/중복 제거된 항목(merged/deduplicated entries)을 계산하는지에 따라 다릅니다. 스냅샷 메타데이터는 현재 게시된 로컬 부트스트랩 데이터셋의 진실 공급원입니다.
첫 실행 시 느린 라이브 동기화(live sync)를 수행하는 대신 미리 구축된 SQLite 스냅샷으로 부트스트랩할 수 있습니다. 따라서 일반적인 시작은 모든 라이브 레지스트리 예산(live registry budgets)을 기다리지 않습니다. 순차적인 Official → Glama 콜드 크롤(cold crawl)은 스냅샷 부트스트랩이 비활성화되거나 실패했을 때만 빈 DB에 대한 대체 수단이며, 결정론적 교차 레지스트리 중복 제거(deterministic cross-registry deduplication)를 유지합니다.
다운로드는 백그라운드에서 실행됩니다: MCP 서버는 initialize에 즉시 응답하며, 카탈로그가 존재하기 전에 도착하는 도구 호출(tool calls)은 — 다운로드 중이든 핸들 전환 중이든 상관없이 — 진행 상황을 포함한 "아직 준비 중" 알림(status: "preparing", 찾을 수 없음 결과와는 다름)을 받고, 검증된 파일은 재시작 없이 스위치됩니다. 새로 설치된 스냅샷은 새로운 동기화(sync)로 간주되므로, 대체하기 위해 의도되었던 라이브 크롤을 즉시 트리거하지 않습니다.
각 스냅샷은 자체 불변 파일인 data-<sha16>.db로 저장되며, data.db.snapshot.json의 포인터에 의해 선택됩니다. 아무것도 제자리에서 대체되지 않기 때문에, 각각 자신의 mcpfinder 프로세스를 실행하여 ~/.mcpfinder를 대상으로 하는 여러 MCP 클라이언트들은 서로의 데이터베이스를 빼앗는 일이 없습니다. 오래된 파일은 MCPFINDER_SNAPSHOT_RETAIN_HOURS(기본값 48) 동안 포인터가 제거되고 건드려지지 않은 후에만 정리되며, 이 정리 작업은 데이터베이스 파일만 언링크하고 — 파일을 여전히 열고 있는 피어(peer)가 이름으로 찾는 -wal 또는 -shm은 절대 언링크하지 않습니다. 이 규칙은 무조건적입니다: 이미 데이터베이스가 사라진 고아 저널(orphaned journal)도 그대로 남겨둡니다. 왜냐하면 그것을 자신의 파일을 능가하여 존재했던 피어의 저널과 구별할 수 있는 것이 없으며, 후자를 삭제하는 것은 손상(corruption)이기 때문입니다. 잔여물을 작게 유지하는 것은 모든 성공적인 동기화가 PRAGMA wal_checkpoint(TRUNCATE)로 끝난다는 점이며, 이는 40MB의 -wal을 의미합니다.
323MB 데이터베이스 옆에서 측정된 이 값은 저널이 전혀 정리되지 않은 단일 트랜잭션 크롤링에서 비롯되었습니다. 남아 있는 것은 SIGKILL로 종료된 프로세스 이후의 유한 누수(bounded leak)입니다.
— MCP 클라이언트가 stdio 서버를 일반적으로 중지시키는 방식입니다. 두 가지 제한 사항이 따릅니다: 열린 파일의 이름을 제거할 수 없는 플랫폼 및 파일 시스템에서는 제거 실패가 허용되며, 이 경우 아무것도 해당 파일을 붙잡고 있지 않아도 오래된 스냅샷(stale snapshots)은 유지됩니다— 그리고 저널이 속했던 데이터베이스보다 더 오래 지속될 수 있습니다. 설치 과정은 매일 재확인됩니다: 변경 사항이 없을 때는 하나의 매니페스트 요청만 필요하며, 매니페스트가 더 새로운 다이제스트(digest)를 광고할 때 DB에 대한 요청이 추가됩니다— 이는 gzip 엔드포인트에서는 조건부(ETag)이며, brotli 엔드포인트에서는 비조건부입니다. 후자는 자체 다이제스트로 콘텐츠 주소 지정 방식이며 ETag가 기록되는 경우가 없습니다.
-
스냅샷 매니페스트:
/api/v1/snapshot/manifest.json
-
스냅샷 데이터베이스 (gzip): manifest.url을 사용하여 콘텐츠 주소 지정 방식으로 기본 엔드포인트로 사용합니다.
(data.sqlite.gz?sha=<sha256>)
-
스냅샷 데이터베이스 (brotli): manifest.brotli.url을 사용하여 콘텐츠 주소 지정 방식으로 기본 엔드포인트로 사용합니다.
(data.sqlite.br?sha=<brotli sha256>)
-
영구적인 현재 대체 경로: 매니페스트가 게시된 후에만 새로 고침됩니다.
/api/v1/snapshot/data.sqlite.gz
-
예약 빌드:
.github/workflows/snapshot.yml
-
오래됨 모니터링(staleness monitor):
.github/workflows/snapshot-staleness.yml
모든 빌드는 동일한 SQLite 파일을 두 번 게시합니다— gzip은 항상, brotli는 파이프라인의 해당 부분이 성공할 때만 합니다 (아래 게시 섹션 참조). Brotli(품질 9, 16MB 창)가 약 21% 더 작습니다: 2026-08-26에 게시된 238MB / 84,647 서버 데이터베이스의 경우 gzip 대비 36.8MB로 측정되었습니다 (gzip은 46.7MB). 두 수치 모두 코퍼스(corpus) 크기에 비례하므로, 매니페스트의 sizeBytes와 brotli.sizeBytes를 참고하십시오.
이것들보다는 실시간 수치로 (처리하는 것이 낫다). 두 번째 아티팩트를 압축하는 데는 90분 작업 시간 내에서 1분도 채 걸리지 않으며, 압축 해제는 찰나의 순간이다. zstd는 추가로 약 2MB를 압축하지만 Node 22.15+/23.8+가 필요하다. 현재 22.x 버전은 이 기준을 충족하지만, Node 23.0-23.7은 그렇지 않으므로, 안전한 이점을 얻기 위해서는 세 번째 아티팩트가 여전히 폴백(fallback)을 가지고 있어야 한다. 하지만 brotli가 이미 작업을 수행하고 있으므로 가치가 없다.
{
"publishedAt": "…", "serverCount": 84647,
...
}
다음 릴리스의 클라이언트는 매니페스트가 brotli를 알리면 이를 선호하고, 어떤 brotli 측 실패(404, 전송 오류, 손상된 스트림, 다이제스트 불일치)에도 gzip으로 폴백한다. 따라서 잘못된 brotli 객체는 대역폭만 소모할 뿐, 작동하는 부트스트랩은 절대 아니다. 두 URL 모두 구성된 스냅샷 베이스를 기준으로 해결되며, 이를 벗어나는 URL은 가져오는 대신 거부된다: 다이제스트(digest)는 URL과 같은 매니페스트에 존재하므로 바이트의 출처를 보증할 수 없다. 압축 해제는 매니페스트의 rawSizeBytes를 기준으로 크기가 제한되는데, 이는 다이제스트가 확인되기 전에 바이트가 디스크에 도달하기 때문이다. 각 아티팩트는 자체 다이제스트와 비교하여 검증되며, data.db.snapshot.json에 기록된 ETag는 항상 실제로 다운로드된 객체를 설명한다 (brotli 설치는 이 필드가 gz 객체의 유효성 검사기이기 때문에 아무것도 저장하지 않는다). gzip을 유지하려면 MCPFINDER_SNAPSHOT_NO_BROTLI=1로 설정하라.
게시된 클라이언트 1.1.0 및 1.2.0은 오직 sha256/sizeBytes/url만 읽으며 추가 필드에 영향을 받지 않는다.
스냅샷 게시(publishing)는 마지막으로 알려진 좋은 상태(last-known-good)를 따른다: 요청된 모든 레지스트리는 ok로 끝나야 한다.
동기화 상태(sync status)와 병합된 총계에 각 소스별 카운트를 더한 값이 현재 게시된 매니페스트보다 5% 이상 낮지 않을 수 있습니다. 게이트 실패 시, 게시된 R2 객체는 변경되지 않습니다. 확인된 누락 매니페스트(HTTP 404, 첫 빌드 포함)만 카운트 비교를 건너뜁니다. 일시적(transient), 잘못된 형식(malformed) 또는 구조적으로 불완전한 베이스라인은 재시도되고 이후 폐쇄 실패(fail closed)하며, 소스 상태는 항상 요구됩니다.
게시(Publication)는 콘텐츠 주소 지정 방식의 핸드오프를 사용합니다. 압축된 데이터베이스가 먼저 업로드되는데, 이는 각각 자체 다이제스트로 키가 지정되는 snapshots/<sha256>.sqlite.gz와 snapshots/<brotli sha256>.sqlite.br입니다. 그 후에야 manifest.json이 data.sqlite.gz?sha=<sha256>과 같은 포인터 URL로 대체됩니다. 따라서 이 포인터는 이미 영구적인(durable) 객체를 아닌 것을 절대 알리지 않습니다. 캐시된 이전 매니페스트는 정확한 불변 데이터베이스로 계속 해석됩니다.
sha가 없는 레거시(legacy) 매니페스트는 기존의 data.sqlite.gz 키를 계속 사용합니다. 매니페스트를 진행하기 전에, CI는 공개 워커 엔드포인트(public Worker endpoint)를 통해 두 개의 새 객체를 다운로드하고 각각의 SHA-256과 워커가 인정한 콘텐츠 주소를 검증합니다.