Acerca de
Cómo se comprueba este directorio
Cada servicio que figura aquí se comprueba con sus propios archivos públicos: su llms.txt, su manifiesto MCP, su descripción de API publicada o su propio anuncio. Además, se establece una vez conexión con cada servidor MCP remoto, para ver si responde a la negociación inicial (handshake) de MCP y qué herramientas enumera. Cada ficha recoge lo que se encontró, cuándo y dónde.
Comprobación en directo de servidores MCP remotos
En la comprobación (5 de octubre de 2026), 9860 de 16.682 servidores MCP remotos respondieron a la negociación inicial de MCP y listaron en total 154.231 herramientas; 4996 requirieron inicio de sesión (3930 remitían a metadatos de OAuth), 52 endpoints SSE antiguos abrieron su flujo y 1774 no respondieron como servidores MCP. 194 más no se solicitaron: su URL del registro contiene un marcador de posición que hay que completar o no es una dirección https pública.
Qué se comprueba. Para cada endpoint remoto de la entrada de un servidor en el registro, este directorio envía una solicitud initialize de MCP (versión del protocolo 2025-06-18) mediante Streamable HTTP. Si el servidor responde, envía la notificación initialized, pide tools/list (hasta cinco páginas) y registra el nombre y la versión del servidor, la versión del protocolo con la que respondió, el número de herramientas y hasta 50 nombres de herramientas; después cierra la sesión. Los endpoints con el antiguo transporte SSE solo se abren, y se esperan hasta diez segundos al evento que indica su endpoint de mensajes.
Qué no se comprueba. No se llama a ninguna herramienta, no se lee ningún recurso ni prompt y no se inicia sesión en nada: un endpoint que responde HTTP 401 o 403 se registra como que requiere inicio de sesión, con una nota de si remite a metadatos de autorización de OAuth. La comprobación no dice nada sobre qué hacen las herramientas, ni sobre si lo hacen bien o de forma segura, y es una instantánea: un servidor que respondió puede dejar de funcionar más tarde, y uno que falló puede haber estado sin servicio por poco tiempo.
Cómo se hacen las solicitudes. Las solicitudes se identifican como AgentReadyDirectoryCheck/1.0 con un enlace a esta página, no llevan credenciales ni cookies, esperan como máximo 15 segundos, se reintentan solo una vez tras una conexión interrumpida y se envían a un solo host cada vez. No se solicitan URL con marcadores de posición, URL con HTTP sin cifrar, localhost ni direcciones privadas.
Para qué se usan los nombres de las herramientas. Además de mostrarse en la página de cada servidor, los nombres de las herramientas sirven para clasificar un servidor en una categoría cuando su propio nombre y su resumen no coinciden con ninguna: si al menos tres de los nombres de sus herramientas se refieren a un tema (viajes, comida y reparto, inmobiliaria, salud, mapas y transporte, finanzas, compras o medios), el doble de los que se refieren a cualquier otro tema y al menos una cuarta parte de todas sus herramientas, el servidor se incluye en esa categoría y su página indica que la categoría procede de los nombres de sus herramientas. Antes se descartan los conjuntos de herramientas que 20 o más servidores listan igual (herramientas de pasarela y de plantilla) y las palabras genéricas como search, get y list. Cómo se asignan las categorías.
Por qué fallaron las comprobaciones. error HTTP 4xx: 786, no se pudo conectar: 491, error HTTP 5xx: 243, sin respuesta en 15 segundos: 181, respondió, pero no como servidor MCP: 41, límite de solicitudes alcanzado (HTTP 429): 20 y rechazó la negociación inicial: 12.
Quién publicó un servidor. El MCP Registry solo acepta nombres bajo io.github.<account> de quien haya iniciado sesión en él con GitHub como ese usuario o en nombre de esa organización, y nombres bajo un dominio invertido como com.example solo de quien haya demostrado el control de example.com, mediante un registro DNS, que también cubre sus subdominios, o mediante un archivo en /.well-known/mcp-registry-auth (documentación del registro). La página de cada servidor indica de qué forma se verificó su espacio de nombres. Eso muestra quién publicó la entrada, no que el producto que nombra la respalde.
Fuentes y licencias
| Fuente | Uso | Licencia |
|---|---|---|
| MCP Registry oficial | Servidores MCP: nombres, endpoints, paquetes y el resumen del propio editor | Publicado para agregadores; solo datos, resúmenes reescritos |
| La documentación propia de cada servicio | Qué integraciones de IA ofrece un servicio, con un enlace a la página que lo indica | Solo datos; no se copia ningún texto |
| El endpoint de cada servidor MCP remoto | La comprobación en directo: si el endpoint respondió a la negociación inicial de MCP (handshake initialize), el nombre del servidor, su versión y la versión del protocolo, y los nombres y el número de sus herramientas (tools/list); no se llama a ninguna herramienta ni se inicia sesión en nada | Solo datos (estado, nombres y recuentos), registrados con la fecha |
| Documentación del MCP Registry: autenticación | Lo que demuestra un espacio de nombres del registro: el inicio de sesión en GitHub para los nombres io.github.*, una prueba del dominio por DNS o HTTP para los nombres de dominio invertido | Solo datos |
| El sitio web de cada servicio | /llms.txt, /.well-known/mcp.json, /.well-known/ai-plugin.json y /agents.json, solicitados y registrados con su estado y la fecha | Solo datos (estado y presencia de cada archivo) |
Quién gestiona este sitio
Agent-Ready está gestionado por Nexa AI. Ningún servicio, hotel o lugar paga por figurar, ser descrito o aparecer clasificado.
Política editorial: cómo se eligen las entradas, qué significa figurar en el directorio, cómo solicitar una corrección o una retirada y lo actualizados que están los datos.