一个能够发现并调用（几乎）世界上任何 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 为环境变量）。
不受信任的输出：来自下游服务器的结果和工具描述被标记为第三方数据，以便模型将其视为数据而非指令。这降低了提示注入风险；但并未消除——参见 SECURITY.md。
限制：连接/调用超时、响应大小截断、有界的会话池。
~/.config/mcp-anything/config.json（或 --config <路径>，或 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
}
}
}每个字段都是可选的；上面的默认值（减去示例请求头/环境变量）就是你在没有任何配置时得到的结果。registryUrl 接受任何实现官方 REST API 的注册表——包括私有/自托管的注册表。
sources 控制生态系统中被索引的范围：
源 | 规模 | 增加的内容 |
| 数千 | 经过审核的条目，元数据最丰富（传输方式、环境变量、版本） |
| ~22k | 广泛的目录 + GitHub 星标和下载量（用于排名） |
| ~67k 个带标签的包 | 最大的原始 stdio 服务器池，包含月度下载量 |
| ~75k | 最广泛的索引（尽力而为的适配器） |
{ "sources": ["official", "pulsemcp", "npm"] }出现在多个目录中的条目会按规范化后的仓库 URL 和包标识符进行去重；最受信任的来源决定身份，元数据从其他来源回填，星标和下载量会累积。排名随后将 BM25 相关性得分与对数缩放的流行度加成（以及官方注册表条目的额外加分）相结合，因此 search_mcp_servers 会呈现某个能力得到维护的实现，而不是第一百个被遗弃的克隆。qualityFilter（默认开启）会丢弃无法连接且没有可用描述的条目——在广泛的来源下，更多只有在垃圾条目不进入前 5 名时才更好。某个来源失败时会优雅降级：同步会保留其他来源返回的内容并报告失败。
词法搜索，而非嵌入。 完全本地化，零 API 成本，无需索引构建步骤——而且对于工具发现，带模糊匹配的关键词搜索在实践中表现相当（Anthropic 的 Tool Search 也采用了同样的 BM25/正则方案）。
会话，而非无状态调用。 MCP 是面向会话的（initialize 握手、能力协商）。下游连接被池化并在调用间复用，采用 LRU 淘汰。
优雅降级。 如果注册表不可达，上次同步的缓存仍可继续工作。
这个领域很活跃：MetaMCP 和其他网关聚合你配置的服务器；Composio 的 Rube 路由到其自有精选目录；宿主正在发展原生工具搜索。mcp-anything 的定位是开放的组合：以公共注册表为目录、本地优先的单一二进制文件、以及明确的安全策略——无需云账户、无精选锁定、可针对私有注册表自托管。
排名中的实时健康检查和结果质量信号
通过索引热门服务器的 tools/list 实现按工具（而不仅仅是按服务器）搜索
为需要 OAuth 的远程服务器提供 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 server参见 CONTRIBUTING.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.
