世界の（ほぼ）あらゆるMCPサーバーを発見・呼び出しできる、たった一つのMCPサーバー。
mcp-anything は メタ MCPサーバーです。ホスト（Claude Desktop、Claude Code、Cursorなど）に数十のMCPサーバーを設定する代わりに、たった一つを設定するだけです。公式の MCPレジストリ をローカルにインデックスし、モデルがサーバーを検索・調査・ツールをその場で呼び出せるようにする5つの小さな メタツール を公開します。数千ものツールスキーマをコンテキストウィンドウに読み込む必要は一切ありません。
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サーバーが存在しますが、ホストが知っているのは手動で設定したものだけです。
コンテキスト: 多くのサーバーを読み込むとコンテキストウィンドウを消費します。メタツールはコストを一定に保ちます。モデルは2段階（検索→調査→呼び出し）で機能を検索します。これはAnthropicのTool Searchと同じパターンです。
設定は一つ: MCPクライアント設定にサーバーごとに1エントリではなく、単一のエントリで済みます。
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スキーマ付きで一覧表示します。 |
| ダウンストリームサーバー上で1つのツールを実行します。セッションはプールされ再利用されます。 |
| インデックスの更新を強制します（それ以外はTTL期限で自動更新）。 |
LLMを公開レジストリの任意のサーバーに接続することは、デフォルトでは危険です。mcp-anything は保守的なデフォルトを備え、すべての緩和を明示的にします。
リモートサーバー（streamable-http / sse）: 許可されますが、プライベート/ループバック/リンクローカルアドレス（クラウドメタデータエンドポイント 169.254.169.254 など）と平文の http: はブロックされます。これはレジストリエントリがネットワーク内を指す場合のSSRFガードです。remote.allowPrivateNetwork で無効化できます（ローカル開発専用）。
Stdioサーバー（npx / uvx プロセスの起動）: デフォルトで無効。 公開レジストリからパッケージを実行することは、マシン上での任意コード実行です。明示的なパッケージごとの許可リストでのみ有効にしてください。
シークレット: APIキーはインデックス化もモデルに公開もされません。設定でサーバーごとにマッピングし、接続時に注入されます（リモートはヘッダー、stdioは環境変数）。
信頼できない出力: ダウンストリームサーバーからの結果やツールの説明はサードパーティデータとしてラベル付けされ、モデルがデータとして扱い、指示として扱わないようにします。これによりプロンプトインジェクションのリスクは 減少 しますが、排除はされません。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 は機能のメンテナンスされた実装を、100番目の放棄されたクローンではなく表面化させます。qualityFilter（デフォルトオン）は、接続手段がなく説明も使えないエントリを除外します。広いソースでは、より多く が良いのは、ジャンクがトップ5に入らない場合のみです。失敗したソースは優雅に劣化します。同期は他のソースが返したものを保持し、失敗を報告します。
語彙検索、埋め込みではない。 完全にローカル、APIコストゼロ、インデックス構築ステップなし。ツール発見には、キーワード検索とファジーマッチングが実際には同等に機能します（AnthropicのTool SearchもBM25/regexで同じ判断をしました）。
ステートレス呼び出しではなくセッション。 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.
