Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@mcp-anything find an MCP server that can query Postgres and list its tools"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
One MCP server that can discover and call (almost) any MCP server in the world.
mcp-anything is a meta-MCP server: instead of configuring dozens of MCP servers in your host (Claude Desktop, Claude Code, Cursor, ...), you configure exactly one. It indexes the official MCP registry locally and exposes five small meta-tools that let the model search for servers, inspect them, and call their tools on the fly — without ever loading thousands of tool schemas into the context window.
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)Discovery: thousands of MCP servers exist; your host only knows the ones you hand-configured.
Context: loading many servers burns your context window. Meta-tools keep the cost constant — the model searches for capabilities in two phases (search → inspect → call), the same pattern Anthropic's Tool Search uses.
One config: a single entry in your MCP client config instead of one per server.
Related MCP server: InfiniteMCP
# 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"]
}
}
}Then just ask your model things like "find an MCP server that can query Postgres and list its tools" — it will use the meta-tools by itself.
mcp-anything serve --http # streamable HTTP on :8080 (POST /mcp)
mcp-anything serve --http --discovery-only # safe for public hosting: search/describe onlyA public instance with execution enabled would be an open proxy — never host a full instance publicly. The Dockerfile defaults to discovery-only for exactly this reason. A hosted discovery instance lets any MCP client search the ecosystem; actually connecting and calling tools is what the local install is for.
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)Tool | What it does |
| Keyword search (BM25 + fuzzy) over the indexed registry. Returns candidates with a connectability verdict. |
| Full registry metadata: transports, packages, required env vars / secrets, policy verdict. |
| Connects live (per policy) and lists the server's actual tools with JSON schemas. |
| Executes one tool on a downstream server. Sessions are pooled and reused. |
| Forces an index refresh (otherwise auto-refreshed on TTL expiry). |
Connecting an LLM to arbitrary servers from a public registry is dangerous by default. mcp-anything ships with conservative defaults and makes every relaxation explicit:
Remote servers (streamable-http / sse): allowed, but private/loopback/link-local addresses (including cloud metadata endpoints like 169.254.169.254) and plain http: are blocked — an SSRF guard for registry entries that point into your network. Opt out with remote.allowPrivateNetwork (useful for local development only).
Stdio servers (spawning npx / uvx processes): disabled by default. Running a package from a public registry is arbitrary code execution on your machine. Enable it only with an explicit per-package allowlist.
Secrets: API keys are never indexed or exposed to the model. You map them per server in your config; they are injected at connect time (headers for remote, env for stdio).
Untrusted output: results and tool descriptions from downstream servers are labeled as third-party data so the model treats them as data, not instructions. This reduces prompt-injection risk; it does not eliminate it — see SECURITY.md.
Limits: connect/call timeouts, response-size truncation, bounded session pool.
~/.config/mcp-anything/config.json (or --config <path>, or 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
}
}
}Every field is optional; the defaults above (minus the example headers/env) are what you get with no config at all. registryUrl accepts any registry implementing the official REST API — including a private/self-hosted one.
sources controls how much of the ecosystem gets indexed:
Source | Scale | What it adds |
| thousands | Moderated entries with the richest metadata (transports, env vars, versions) |
| ~22k | Broad catalog + GitHub stars & download counts (feeds ranking) |
| ~67k tagged packages | The largest raw pool of stdio servers, with monthly downloads |
| ~75k | The widest index (best-effort adapter) |
{ "sources": ["official", "pulsemcp", "npm"] }Entries appearing in several catalogs are deduplicated by normalized repository URL and package identifier; the most-trusted source wins the identity, metadata is backfilled from the others, and stars/downloads accumulate. Ranking then combines BM25 relevance with a log-scaled popularity boost (and a bonus for official-registry entries), so search_mcp_servers surfaces the maintained implementation of a capability rather than the hundredth abandoned clone. qualityFilter (default on) drops entries with no way to connect and no usable description — with wide sources, more is only better if the junk stays out of the top-5. A failed source degrades gracefully: the sync keeps whatever the other sources returned and reports the failure.
Lexical search, not embeddings. Fully local, zero API cost, no index build step — and for tool discovery, keyword search with fuzzy matching performs comparably in practice (Anthropic's Tool Search made the same call with BM25/regex).
Sessions, not stateless calls. MCP is session-oriented (initialize handshake, capability negotiation). Downstream connections are pooled and reused across calls with LRU eviction.
Graceful degradation. If the registry is unreachable, the last-synced cache keeps working.
This space is active: MetaMCP and other gateways aggregate servers you configure; Composio's Rube routes to its own curated catalog; hosts are growing native tool-search. mcp-anything's niche is the open combination: the public registry as the catalog, a local-first single binary, and an explicit security policy — no cloud account, no curation lock-in, self-hostable against a private registry.
Live health checks and result-quality signals in ranking
Per-tool (not just per-server) search by indexing tools/list of popular servers
OAuth flow passthrough for remote servers that require it
Container/Wasm sandboxing for stdio servers as an alternative to allowlisting
Multiple registries with federation and dedupe
Optional streamable-http serving mode (for shared/team deployment)
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 serverSee CONTRIBUTING.md. Licensed 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.
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.
Search and browse every MCP server in the Model Context Protocol registry.
