Un servidor MCP que puede descubrir y llamar a (casi) cualquier servidor MCP del mundo.
mcp-anything es un servidor MCP meta: en lugar de configurar docenas de servidores MCP en tu host (Claude Desktop, Claude Code, Cursor, ...), configuras exactamente uno. Indexa el registro oficial de MCP localmente y expone cinco meta-herramientas pequeñas que permiten al modelo buscar servidores, inspeccionarlos y llamar a sus herramientas sobre la marcha, sin cargar nunca miles de esquemas de herramientas en la ventana de contexto.
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)Descubrimiento: existen miles de servidores MCP; tu host solo conoce los que configuraste manualmente.
Contexto: cargar muchos servidores consume tu ventana de contexto. Las meta-herramientas mantienen el costo constante: el modelo busca capacidades en dos fases (buscar → inspeccionar → llamar), el mismo patrón que usa la búsqueda de herramientas de Anthropic.
Una configuración: una sola entrada en la configuración de tu cliente MCP en lugar de una por servidor.
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"]
}
}
}Luego solo pídele a tu modelo cosas como "encuentra un servidor MCP que pueda consultar Postgres y lista sus herramientas" — usará las meta-herramientas por sí mismo.
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)Herramienta | Qué hace |
| Búsqueda por palabras clave (BM25 + difusa) sobre el registro indexado. Devuelve candidatos con un veredicto de conectividad. |
| Metadatos completos del registro: transportes, paquetes, variables de entorno / secretos requeridos, veredicto de política. |
| Se conecta en vivo (según la política) y lista las herramientas reales del servidor con esquemas JSON. |
| Ejecuta una herramienta en un servidor downstream. Las sesiones se agrupan y reutilizan. |
| Fuerza una actualización del índice (de lo contrario, se actualiza automáticamente al expirar el TTL). |
Conectar un LLM a servidores arbitrarios de un registro público es peligroso por defecto. mcp-anything viene con valores predeterminados conservadores y hace explícita cada relajación:
Servidores remotos (streamable-http / sse): permitidos, pero las direcciones privadas/loopback/link-local (incluidos los endpoints de metadatos de la nube como 169.254.169.254) y http: simple están bloqueados: una protección SSRF para entradas del registro que apuntan a tu red. Puedes desactivarla con remote.allowPrivateNetwork (útil solo para desarrollo local).
Servidores stdio (que lanzan procesos npx / uvx): deshabilitados por defecto. Ejecutar un paquete de un registro público es ejecución de código arbitrario en tu máquina. Actívalo solo con una lista blanca explícita por paquete.
Secretos: las claves de API nunca se indexan ni se exponen al modelo. Las asignas por servidor en tu configuración; se inyectan al momento de la conexión (cabeceras para remoto, env para stdio).
Salida no confiable: los resultados y las descripciones de herramientas de servidores downstream se etiquetan como datos de terceros para que el modelo los trate como datos, no como instrucciones. Esto reduce el riesgo de inyección de prompts; no lo elimina — consulta SECURITY.md.
Límites: tiempos de espera de conexión/llamada, truncamiento del tamaño de la respuesta, grupo de sesiones acotado.
~/.config/mcp-anything/config.json (o --config <ruta>, o 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
}
}
}Cada campo es opcional; los valores predeterminados anteriores (menos los ejemplos de cabeceras/env) son lo que obtienes sin configuración alguna. registryUrl acepta cualquier registro que implemente la API REST oficial, incluido uno privado/autohospedado.
sources controla cuánto del ecosistema se indexa:
Fuente | Escala | Qué añade |
| miles | Entradas moderadas con los metadatos más ricos (transportes, variables de entorno, versiones) |
| ~22k | Catálogo amplio + estrellas de GitHub y recuentos de descargas (alimentan el ranking) |
| ~67k paquetes etiquetados | El mayor grupo bruto de servidores stdio, con descargas mensuales |
| ~75k | El índice más amplio (adaptador de mejor esfuerzo) |
{ "sources": ["official", "pulsemcp", "npm"] }Las entradas que aparecen en varios catálogos se deduplican por URL de repositorio normalizada e identificador de paquete; la fuente más confiable gana la identidad, los metadatos se completan desde las demás, y las estrellas/descargas se acumulan. El ranking combina entonces la relevancia BM25 con un impulso de popularidad logarítmico (y una bonificación para entradas del registro oficial), de modo que search_mcp_servers muestra la implementación mantenida de una capacidad en lugar del clon abandonado número cien. qualityFilter (activado por defecto) descarta entradas sin forma de conectarse y sin descripción utilizable — con fuentes amplias, más solo es mejor si la basura se mantiene fuera del top-5. Una fuente que falla se degrada con elegancia: la sincronización conserva lo que devolvieron las otras fuentes e informa del fallo.
Búsqueda léxica, no embeddings. Totalmente local, costo de API cero, sin paso de construcción de índice — y para el descubrimiento de herramientas, la búsqueda por palabras clave con coincidencia difusa funciona de manera comparable en la práctica (la búsqueda de herramientas de Anthropic tomó la misma decisión con BM25/regex).
Sesiones, no llamadas sin estado. MCP está orientado a sesiones (handshake de inicialización, negociación de capacidades). Las conexiones downstream se agrupan y reutilizan entre llamadas con evicción LRU.
Degradación elegante. Si el registro no está disponible, la caché de la última sincronización sigue funcionando.
Este espacio está activo: MetaMCP y otras pasarelas agregan servidores que configuras; Rube de Composio enruta a su propio catálogo curado; los hosts están incorporando búsqueda nativa de herramientas. El nicho de mcp-anything es la combinación abierta: el registro público como catálogo, un binario único local-primero y una política de seguridad explícita — sin cuenta en la nube, sin bloqueo de curación, autohospedable contra un registro privado.
Comprobaciones de salud en vivo y señales de calidad de resultados en el ranking
Búsqueda por herramienta (no solo por servidor) indexando tools/list de servidores populares
Paso de flujo OAuth para servidores remotos que lo requieran
Sandboxing de contenedor/Wasm para servidores stdio como alternativa a la lista blanca
Múltiples registros con federación y deduplicación
Modo de servicio streamable-http opcional (para despliegue compartido/equipo)
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 serverConsulta CONTRIBUTING.md. Licencia 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.
