세상에 있는 (거의) 모든 MCP 서버를 발견하고 호출할 수 있는 단 하나의 MCP 서버.
mcp-anything은 메타 MCP 서버입니다. 호스트(Claude Desktop, Claude Code, Cursor, ...)에 수십 개의 MCP 서버를 설정하는 대신, 단 하나만 설정하면 됩니다. 이 서버는 공식 MCP 레지스트리를 로컬에 인덱싱하고, 모델이 서버를 검색하고 살펴본 다음 도구를 즉석에서 호출할 수 있게 해주는 다섯 개의 작은 메타 도구를 노출합니다 — 수천 개의 도구 스키마를 컨텍스트 윈도우에 로드할 일은 전혀 없습니다.
Host / LLM
│ (5 meta-tools, constant context cost)
▼
mcp-anything ──── local BM25 index ◄──┬── official MCP registry (moderated, richest metadata)
│ (cross-source dedupe, ├── PulseMCP (~22k servers, stars & downloads)
│ popularity-boosted ├── npm (~67k packages tagged mcp)
│ ranking) └── Glama (~75k indexed servers)
│
│ security policy: SSRF guard · stdio allowlist · secrets injection · timeouts
▼
downstream MCP servers (streamable-http / sse / stdio via npx·uvx)발견: 수천 개의 MCP 서버가 존재하지만, 호스트는 직접 설정한 서버만 알고 있습니다.
컨텍스트: 많은 서버를 로드하면 컨텍스트 윈도우가 소진됩니다. 메타 도구는 비용을 일정하게 유지합니다 — 모델은 검색 → 검사 → 호출의 두 단계로 기능을 탐색하며, 이는 Anthropic의 Tool Search가 사용하는 것과 같은 패턴입니다.
설정 하나면 충분: MCP 클라이언트 설정에 서버마다 하나씩 추가하는 대신 단일 항목만 추가하면 됩니다.
Related MCP server: Smart MCP Proxy
# Run directly (Node >= 20):
npx mcp-anything sync # first-time index download (~few seconds)
npx mcp-anything serve # start the meta-MCP server on stdioclaude mcp add anything -- npx -y mcp-anything serve{
"mcpServers": {
"anything": {
"command": "npx",
"args": ["-y", "mcp-anything", "serve"]
}
}
}그런 다음 모델에게 "Postgres를 쿼리할 수 있는 MCP 서버를 찾아서 그 도구 목록을 보여줘" 같은 요청을 하면 됩니다 — 모델이 메타 도구를 스스로 사용할 것입니다.
mcp-anything sync # refresh the registry index
mcp-anything search "weather" # search the index from your terminal
mcp-anything serve # stdio MCP server (default command)도구 | 기능 |
| 인덱싱된 레지스트리에 대한 키워드 검색(BM25 + 퍼지). 연결 가능성 판정과 함께 후보를 반환합니다. |
| 전체 레지스트리 메타데이터: 트랜스포트, 패키지, 필수 환경 변수/시크릿, 정책 평가. |
| (정책에 따라) 실시간으로 연결해 서버의 실제 도구와 JSON 스키마를 나열합니다. |
| 다운스트림 서버에서 하나의 도구를 실행합니다. 세션은 풀링되어 재사용됩니다. |
| 인덱스 새로고침을 강제합니다(그렇지 않으면 TTL 만료 시 자동 새로고침됨). |
공개 레지스트리의 임의 서버에 LLM을 연결하는 것은 기본적으로 위험합니다. mcp-anything은 보수적인 기본값을 가지며, 모든 완화 설정을 명시적으로 요구합니다:
원격 서버 (streamable-http / sse): 허용되지만, 비공개/루프백/링크-로컬 주소(169.254.169.254 같은 클라우드 메타데이터 엔드포인트 포함) 및 일반 http:는 차단됩니다 — 레지스트리 항목이 사용자 네트워크를 가리키는 경우를 대비한 SSRF 가드입니다. remote.allowPrivateNetwork로 해제할 수 있습니다(로컬 개발에만 유용).
Stdio 서버 (npx / uvx 프로세스 실행): 기본적으로 비활성화되어 있습니다. 공개 레지스트리의 패키지를 실행하는 것은 사용자 머신에서 임의 코드를 실행하는 것과 같습니다. 명시적인 패키지별 허용 목록으로만 활성화하세요.
시크릿: API 키는 절대 인덱싱되거나 모델에 노출되지 않습니다. 구성 파일에서 서버별로 매핑하며, 연결 시점에 주입됩니다(원격은 헤더, stdio는 환경 변수).
신뢰할 수 없는 출력: 다운스트림 서버의 결과와 도구 설명은 제3자 데이터로 표시되므로 모델이 이를 지침이 아닌 데이터로 취급합니다. 이는 프롬프트 인젝션 위험을 줄여주지만 완전히 없애지는 않습니다 — SECURITY.md 참조.
제한: 연결/호출 타임아웃, 응답 크기 절단, 크기가 제한된 세션 풀.
~/.config/mcp-anything/config.json (또는 --config <path>, 또는 MCP_ANYTHING_CONFIG):
{
"registryUrl": "https://registry.modelcontextprotocol.io",
"sources": ["official"],
"qualityFilter": true,
"cacheTtlHours": 24,
"maxServers": 10000,
"policy": {
"remote": {
"enabled": true,
"allowPrivateNetwork": false,
"headers": {
"io.github.example/github": { "Authorization": "Bearer ghp_..." }
}
},
"stdio": {
"enabled": false,
"allowPackages": ["@modelcontextprotocol/server-filesystem"],
"env": {
"io.github.example/postgres": { "DATABASE_URL": "postgres://..." }
}
},
"limits": {
"callTimeoutMs": 60000,
"connectTimeoutMs": 20000,
"maxSessions": 8,
"maxResultChars": 100000
}
}
}모든 필드는 선택 사항이며, 구성이 전혀 없을 때는 위의 기본값(예제 헤더/env 제외)이 적용됩니다. registryUrl은 공식 REST API를 구현하는 모든 레지스트리를 허용합니다 — 비공개/자체 호스팅 레지스트리도 포함됩니다.
sources는 생태계의 얼마나 많은 부분을 인덱싱할지 제어합니다:
소스 | 규모 | 추가되는 항목 |
| 수천 개 | 가장 풍부한 메타데이터(트랜스포트, 환경 변수, 버전)를 갖춘 검증된 항목 |
| ~22k | 광범위한 카탈로그 + GitHub 스타 수 및 다운로드 수(랭킹에 반영) |
| 태그된 패키지 ~67k | 월간 다운로드 수가 포함된 가장 큰 원시 stdio 서버 풀 |
| ~75k | 가장 넓은 인덱스(최선 노력 어댑터) |
{ "sources": ["official", "pulsemcp", "npm"] }여러 카탈로그에 나타나는 항목은 정규화된 저장소 URL과 패키지 식별자를 기준으로 중복 제거됩니다. 가장 신뢰도가 높은 소스가 정체성을 결정하고, 메타데이터는 나머지 소스에서 백필되며, 스타 수와 다운로드 수는 누적됩니다. 랭킹은 BM25 관련성에 로그 스케일의 인기 가중치(공식 레지스트리 항목에는 보너스)를 결합하므로, search_mcp_servers는 수백 번째로 버려진 복제본 대신 유지 관리되는 구현을 표면화합니다. qualityFilter(기본값 켜짐)는 연결 방법이 없거나 사용 가능한 설명이 없는 항목을 제거합니다 — 넓은 소스에서는 정크가 상위 5개에 들지 않을 때에만 더 많은 것이 더 나은 것입니다. 실패한 소스는 우아하게 처리됩니다: 동기화는 다른 소스가 반환한 결과를 유지하고 실패를 보고합니다.
어휘 검색이지 임베딩이 아닙니다. 완전히 로컬에서 동작하고, API 비용이 0이며, 인덱스 빌드 단계도 없습니다. 그리고 도구 검색에서는 퍼지 매칭을 사용하는 키워드 검색이 실제로 비슷한 성능을 보입니다(Anthropic의 Tool Search도 BM25/정규식으로 같은 선택을 했습니다).
상태 없는 호출이 아닌 세션. MCP는 세션 중심입니다(initialize 핸드셰이크, 기능 협상). 다운스트림 연결은 LRU 축출 방식으로 풀링되어 호출 간에 재사용됩니다.
우아한 성능 저하. 레지스트리에 연결할 수 없어도 마지막으로 동기화된 캐시는 계속 작동합니다.
이 공간은 활발히 발전하고 있습니다: MetaMCP와 같은 게이트웨이는 사용자가 구성한 서버를 집계하고, Composio의 Rube는 자체 선별 카탈로그로 라우팅하며, 호스트들은 네이티브 도구 검색을 확장하고 있습니다. mcp-anything의 틈새는 개방형 조합입니다: 카탈로그로서의 공개 레지스트리, 로컬 우선의 단일 바이너리, 명시적인 보안 정책 — 클라우드 계정이 없고, 특정 큐레이션에 종속되지 않으며, 비공개 레지스트리를 대상으로 자체 호스팅할 수 있습니다.
랭킹에 실시간 상태 확인 및 결과 품질 신호 추가
인기 서버의 tools/list를 인덱싱하여 서버별이 아닌 도구별 검색
이를 요구하는 원격 서버를 위한 OAuth 흐름 패스스루
허용 목록 대안으로 stdio 서버를 위한 컨테이너/Wasm 샌드박싱
페더레이션 및 중복 제거를 지원하는 다중 레지스트리
선택적 streamable-http 서빙 모드(공유/팀 배포용)
npm install
npm test # unit + end-to-end (mock registry + real downstream MCP server)
npm run typecheck
npm run build
node scripts/smoke.mjs # spawns the built CLI as a real stdio MCP serverCONTRIBUTING.md를 참조하세요. MIT 라이선스입니다.
Execute a specific tool on a downstream MCP server with the given arguments. Use list_mcp_tools first to get the exact tool name and input schema.
| Name | Required | Description | Default |
|---|---|---|---|
| tool | Yes | Tool name exactly as returned by list_mcp_tools | |
| server | Yes | Registry server name | |
| arguments | No | Arguments matching the tool's input schema |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It only says 'Execute' and does not disclose that this can trigger arbitrary downstream side effects, that arguments may need to match a remote schema exactly, or what the response/error behavior looks like. This is a meaningful gap for a tool that can invoke any downstream operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler. The primary action is front-loaded, and the second sentence carries the most important usage prerequisite. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description gives the essential prerequisite call and reinforces exact naming, which is helpful. However, because there is no output schema or annotations, and the tool can execute arbitrary downstream tools, it should mention side-effect potential and result/error expectations to be fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already documents all three parameters. The description adds no parameter-specific meaning beyond referencing the tool's input schema and exact tool name, which matches the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Execute' and the resource: a specific tool on a downstream MCP server. It also distinguishes itself from siblings like list_mcp_tools by describing execution rather than discovery.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells the agent to use list_mcp_tools first to obtain the exact tool name and input schema, which is directly relevant usage guidance. It does not enumerate when not to use the tool, but the prerequisite guidance is concrete and useful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show a server's full registry metadata: transports (remote endpoints / installable packages), required environment variables and secrets, and whether the current security policy allows connecting to it.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Registry server name, e.g. 'io.github.owner/weather' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It does well by indicating a read-style inspection ('Show') and clarifying that it checks whether policy allows connecting, rather than actually connecting. It does not explicitly state side effects or error behavior, but for a metadata lookup this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with a colon-enumerated list of output areas. Every clause adds meaningful information, and there is no redundant restatement of the title or schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter tool with no output schema, the description covers the primary result dimensions: transports, environment variables/secrets, and security policy. It could mention what happens for an unknown server name, but that is a minor gap given the simplicity of the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already fully documents the single 'name' parameter with an example. The description adds no parameter-specific detail, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Show' with a clear resource ('a server's full registry metadata') and enumerates the metadata categories. This distinguishes it from sibling tools like search_mcp_servers, which find servers, and call_mcp_tool, which invokes one.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies this is the right tool when you already know a server name and need its registry metadata rather than searching or calling it. It does not explicitly state when not to use it or name alternatives, but the context is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Connect to an MCP server (per security policy) and list its actual tools with their input schemas. Connection is reused for subsequent call_mcp_tool calls.
| Name | Required | Description | Default |
|---|---|---|---|
| server | Yes | Registry server name from search_mcp_servers |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden. It adds useful behavioral context: it connects to a live server, obeys a security policy, fetches actual tools and schemas, and leaves a reusable connection for later calls. It does not explicitly state that the operation is read-only or what happens on connection failure, but the 'list' semantics make that reasonably clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the core purpose and immediately followed by the connection-reuse behavior. Every sentence contributes information; there is no filler or repetition of the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter tool with no output schema, the description adequately covers what the agent needs: the server to connect to, that actual tools and input schemas are returned, and that the connection is reused. No critical operational detail is missing for selecting and invoking this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%: the only parameter, 'server', is already described as 'Registry server name from search_mcp_servers.' The description adds no additional parameter-level detail beyond what the schema provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('list'), a specific resource ('a server's actual tools'), and the key deliverable ('with their input schemas'). The 'live' qualifier in the title and 'actual' in the description distinguish it from cached or metadata-level views, and it clearly differs from siblings like search_mcp_servers, describe_mcpp_server, and call_mcp_tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly positions the tool as a connection-establishing step: 'Connection is reused for subsequent call_mcp_tool calls.' This tells an agent this should be invoked before calling tools on the server. It does not explicitly enumerate when not to use it or compare it with describe_mcp_server, so it falls short of a perfect 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the MCP registry index for servers matching a task description (keyword search over names and descriptions). Returns candidate servers with their connectability. Follow up with describe_mcp_server / list_mcp_tools.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results (default 5) | |
| query | Yes | What you want to do, e.g. 'query postgres database' or 'send slack message' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the behavioral burden. It discloses the keyword-search scope over names and descriptions and states that results include connectability, which is useful beyond the tool name. It omits minor details such as no-results behavior or ordering, but nothing misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. The core action and matching scope are front-loaded, and the follow-up sentence adds genuine routing value without bloating the definition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter search tool with no output schema, the description conveys what is returned (candidate servers with connectability) and the recommended next steps. It is slightly vague about what 'connectability' entails, but the agent has enough information to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the query parameter already carrying an example and the limit parameter documented with bounds. The description adds little parameter-level detail beyond the schema, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('Search'), a concrete resource ('MCP registry index'), and the matching mechanism (keyword search over names and descriptions). It also mentions returning candidate servers, making the tool's role as a discovery entry point unambiguous and distinct from the sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use this tool: when you need to find servers by task description. It also routes the agent to describe_mcp_server / list_mcp_tools as follow-ups. It does not explicitly exclude alternatives like sync_registry, but the workflow cue provides adequate usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Re-download the MCP registry index (otherwise refreshed automatically when the cache TTL expires).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the full behavioral burden, and it discloses the key traits: the operation is an immediate network re-download, and the registry would otherwise refresh on a cache TTL timer. This tells the agent the tool is a forced early refresh rather than an independent or destructive action. It stops short of describing failure behavior or blocking semantics, but for a zero-parameter maintenance operation this is adequate disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence front-loads the action ('Re-download the MCP registry index') and appends only the one piece of context that matters (the auto-refresh behavior). There is no wasted text and the most decision-relevant information is first.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, no-annotations, no-output-schema tool, the description adequately explains what the tool does and why a manual call is needed. It does not describe the return value, but a sync trigger's return is low-information and the description is sufficient for both selecting and invoking the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so the schema trivially covers 100% of parameter documentation and there is no semantic burden for the description to carry. The baseline of 4 for zero-parameter tools applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Re-download') and a specific resource ('the MCP registry index'), making the operation unambiguous. The title reinforces the same concept, and the tool is clearly distinct from siblings that search, describe, list, and call MCP servers/tools rather than maintaining the registry index itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The parenthetical '(otherwise refreshed automatically when the cache TTL expires)' conveys the precise condition under which a manual call is warranted: when fresh data is needed before TTL expiry. It implies that under normal conditions the tool need not be invoked, which is clear usage context, though it names no explicit alternatives or when-not-to-use conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.2.0call_mcp_tooldescribe_mcp_serverlist_mcp_toolssearch_mcp_serverssync_registryScored across 5 tools
Each tool has a clearly distinct role: registry search, metadata inspection, live tool listing, tool execution, and registry refresh. There is no overlap between search, describe, list, call, or sync.
All tool names follow a consistent lowercase snake_case verb_noun pattern: search_mcp_servers, describe_mcp_server, list_mcp_tools, call_mcp_tool, sync_registry. The naming is predictable and readable.
Five tools is well-scoped for a meta-server that handles discovery, inspection, connection, execution, and registry maintenance. Each tool earns its place with no redundancy.
The tool set covers the full workflow: discover servers, inspect metadata, list tools, call tools, and refresh the registry. There are no obvious missing operations for the stated purpose of interacting with the MCP registry.
MCP gateway to A2A discovery and free tool recommendations. Self-service enrollment; no wallet.
Unified gateway exposing 150+ tools across all NexGenData MCP servers via one endpoint.
Find and call the right MCP server for any task - pay per use, no install.
Discover and call 10,000+ production APIs from one MCP server. Pay-per-call billing for AI agents.
