Del MCP Registry a Glama: así se lista un servidor remoto

Un servidor MCP remoto entra en los directorios a través de un único archivo: publicas un server.json en el MCP Registry (registry.modelcontextprotocol.io) con mcp-publisher, después de demostrar que el espacio de nombres es tuyo. Directorios como Glama o PulseMCP leen el Registry cada cierto tiempo y luego se conectan a tu servidor para probarlo por su cuenta. Revisamos nuestra propia ficha, io.github.xiaoxihexiaoyu/everyinfra, el 21 de octubre de 2026 (entre las 18:45 y las 18:55 UTC) y varias veces el 24 de octubre, hora de Singapur. La última versión del Registry es la 1.1.1, publicada el 24 de octubre a las 05:20 UTC, y la 1.0.0 quedó marcada como deprecated. Glama creó por su cuenta la página del conector. La reclamamos el 24 de octubre con un registro DNS y ahora la página muestra «Ownership verified». El 25 de octubre marcaba estado Healthy, un 99,2 % de disponibilidad en 48 días y una nota A (3,9/5,0) en calidad de definición de herramientas.

EveryInfra es una API de datos que se paga por llamada: una sola clave da acceso a 91 plataformas, 426 capacidades de datos, 17 herramientas de búsqueda y 52 tipos de CAPTCHA, desde 0,56 USD por cada 1.000 llamadas, y lo que falla o vuelve vacío no se cobra. Aquí hablamos solo de publicar y aparecer en directorios; para comprobar que un servidor conectado funciona de verdad, mira servidor MCP remoto: pruebas en Claude, ChatGPT y Cursor.

Cómo viaja una ficha desde server.json hasta los directorios

• El Registry guarda metadatos, no código. Registra cómo se llama un servidor, dónde está y cómo conectarse, y verifica que quien publica es dueño del espacio de nombres. El análisis de seguridad lo dejan a los registros de paquetes, como npm o PyPI, y a los directorios (qué es el Registry). Los servidores remotos van en remotes, tienen que ser accesibles desde internet y conviene que usen Streamable HTTP (servidores remotos).
• El espacio de nombres marca cómo demuestras la propiedad. io.github.usuario/servidor exige iniciar sesión con ese usuario de GitHub; com.example/servidor exige un reto DNS o HTTP sobre example.com (repositorio del Registry). Un pull request al repositorio no publica nada: solo publica mcp-publisher.
• Los directorios leen a su ritmo. La documentación pide a los agregadores leer de forma regular pero poco frecuente, por ejemplo una vez por hora, y guardar los datos en su propia base; el Registry no garantiza disponibilidad ni persistencia (guía para agregadores).
• Una versión publicada no se toca. Cada número de versión tiene que ser único y, una vez publicado, ni él ni el resto de metadatos se pueden cambiar; solo el estado puede pasar a deprecated o deleted (versionado).

La ficha de EveryInfra el 24 de octubre

• Nombre: io.github.xiaoxihexiaoyu/everyinfra, título EveryInfra.
• Versiones: 1.1.1 (24 de octubre, 05:20 UTC, activa y marcada como latest), 1.1.0 (16 de octubre, 01:49 UTC, activa) y 1.0.0 (8 de septiembre; el 24 de octubre la marcamos como deprecated con el mensaje «Superseded by 1.1.1»). En la primera revisión, el 22 de octubre, la última seguía siendo la 1.1.0 y las dos versiones publicadas estaban activas.
• Descripción: 97 caracteres, con las 90 plataformas y los nombres RedNote, Douyin, TikTok y Amazon. El esquema limita description a 100 caracteres (esquema de server.json), así que solo caben unos pocos nombres.
• Conexión: un remoto streamable-http en https://api.everyinfra.com/mcp con la cabecera Authorization: Bearer {api_key}; la variable api_key es obligatoria y secreta.
• Qué cambió en la 1.1.1: solo el enlace web, que ahora apunta a nuestra página del servidor MCP (el archivo de origen es el server.json del repositorio del plugin); la descripción sigue igual, con 97 caracteres. La publicamos con mcp-publisher el 24 de octubre y la leímos de vuelta en el Registry.
• Glama: la página del conector se generó desde el Registry. La reclamamos el 24 de octubre y la página muestra «Ownership verified». Después rellenamos en Glama la descripción, la miniatura y las categorías, y activamos «Use Glama listing details as the source of truth». Por eso la página de Glama muestra ahora nuestra descripción larga (plataformas, herramientas de búsqueda, tipos de CAPTCHA y precio de partida) y no los 97 caracteres del Registry. El perfil de editor indica que EveryInfra opera el servicio directamente (First-party), con enlaces a la web y a la documentación, y un correo de soporte que solo ve el equipo de Glama.

Registro de pruebas: Registry, Glama y nuestro servidor

Ninguna de estas comprobaciones cuesta dinero. Salvo las marcadas como repetición del 24 de octubre, se hicieron el 22 de octubre, hora de Singapur.

1. Búsqueda por palabra clave en el Registry («everyinfra»): 14,16 s en una versión de la API y 14,62 s en la otra; devolvió 2 registros de versión.
2. Consulta por nombre con /v0.1/servers/{serverName}/versions/latest: 0,93 s, con el server.json completo de la 1.1.0. Si integras un servidor concreto, búscalo por nombre: fue unas 15 veces más rápido que la búsqueda. El 24 de octubre repetimos la misma consulta tres veces: 0,68, 0,93 y 0,91 s, y ya devuelve el server.json completo de la 1.1.1.
3. Página del conector en Glama. La descripción coincide palabra por palabra con la 1.1.0 del Registry. Disponibilidad del 99,1 % en 44 días; última prueba, 2026-10-21 16:38. Hace 44 días era el 8 de septiembre, el día en que la 1.0.0 entró en el Registry: Glama empezó a probar el mismo día de la publicación. Repetición del 24 de octubre a las 18:30, hora de Singapur: estado Healthy, disponibilidad del 99,2 % en 47 días; última prueba, 2026-10-24 10:17 (la página no indica zona horaria). En la captura del 25 de octubre (abajo): Healthy, disponibilidad del 99,2 % en 48 días; última prueba, 2026-10-25 19:50.
4. Nota de calidad de definición de herramientas (TDQS) de Glama: A, 3,8/5,0 sobre 25 herramientas, calculada el 2026-10-21 a las 12:30. La nota del servidor combina cuatro criterios (desambiguación, coherencia de nombres, número de herramientas y cobertura) y cada herramienta recibe además sus propias notas. Repetición del 24 de octubre: sigue la A; el 2026-10-23 a las 10:55 la nota era 3,6/5,0 y en un nuevo cálculo del 2026-10-24 a las 08:45 subió a 3,7/5,0, y el 2026-10-25 a las 16:15 a 3,9/5,0 (captura de abajo), sobre las mismas 25 herramientas. La nota cambia con el tiempo, así que al citarla conviene poner la fecha.
5. Historial de cambios de herramientas en Glama: 9 entradas entre el 9 y el 21 de octubre, cada una con la herramienta añadida o retirada y el texto de parámetro que cambió. El 24 de octubre a las 18:30 había 11: las 2 nuevas son de ese mismo día, cuando cambiamos los parámetros y el texto de everyinfra_settings_update, y Glama lo registró en pocas horas. Glama compara la lista de herramientas en cada inspección correcta, así que una descripción editada aparece ahí.
6. Nuestro servidor. Tres tools/list sin clave tardaron entre 0,18 y 0,25 s y devolvieron 25 herramientas; una llamada de datos sin clave devolvió unauthorized en 0,18 s. Las FAQ de Glama describen este patrón (listar libre, llamar con clave) como algo habitual.
7. Tamaño de los directorios. El 24 de octubre a las 18:30, los títulos de Glama indicaban 36.433 conectores remotos y 109.495 servidores de código abierto (conectores de Glama); el 22 de octubre eran 35.071 y 108.270. El marketplace de LobeHub mostraba 112.261 servidores MCP el 22 de octubre. Un mismo servidor aparece en varios sitios, así que estas cifras no se suman.

Lista de pasos para publicar

1. Escribe el server.json. name en formato de dominio invertido, con una sola barra; description y title, 100 caracteres como máximo; los servidores remotos, en remotes con type igual a streamable-http. Si las llamadas piden clave, declara en headers el nombre de la cabecera y una variable con isSecret: true y un placeholder con el formato de tu clave.
2. Instala mcp-publisher e inicia sesión. Sigue la guía rápida de publicación, ejecuta mcp-publisher login github y escribe en el navegador el código que muestra la terminal. Con un espacio de nombres de dominio, usa el método DNS o HTTP.
3. Publica con mcp-publisher publish. Un servidor remoto no necesita publicar antes un paquete en npm.
4. Comprueba por nombre. Pide la última versión como en la prueba 2 y compara versión, descripción y cabeceras.
5. Cada cambio, una versión nueva. Los números no se reutilizan; para cambios solo de metadatos la documentación recomienda una versión preliminar, como 1.1.0-1. Si una versión antigua quedó desfasada, márcala como deprecated. Nosotros lo hicimos el 24 de octubre, justo después de publicar la 1.1.1: mcp-publisher status --status deprecated --message "Superseded by 1.1.1" io.github.xiaoxihexiaoyu/everyinfra 1.0.0. Al leer de vuelta el Registry, la 1.0.0 figura como deprecated con el mensaje «Superseded by 1.1.1», la 1.1.0 sigue activa y la 1.1.1 es la última. El comando cambia solo el estado: el número de versión y el resto de metadatos quedan como estaban.
6. Reclama la ficha en cada directorio. Abajo, el caso de Glama.

Reclamar el conector en Glama

Según las FAQ de Glama:

1. Abre la página del conector, elige Claim ownership e inicia sesión.
2. Verifica una vez. Para io.github.usuario/…, vincula el usuario de GitHub con el mismo nombre y pulsa Claim with GitHub; si el espacio es de una organización de GitHub, la organización tiene que instalar la GitHub App de Glama. También puedes verificar un dominio: añade un registro TXT en _glama-claim.<dominio> o publica el token en https://<dominio>/.well-known/glama.json. Nosotros usamos DNS: un registro TXT _glama-claim bajo api.everyinfra.com, el host de la URL del servidor. Tras pulsar Check DNS record, la página mostró «Ownership verified». Glama vuelve a comprobar el registro de vez en cuando, así que no lo borres después de reclamar.
3. Tras reclamarla verás comprobaciones de salud, analítica, miniatura y categorías. Nombre, descripción y URL siguen sincronizados con el Registry y se sobrescriben con cada actualización; para conservar lo que edites en Glama, activa «Use Glama listing details as the source of truth» en Manage connector. Nosotros lo activamos: el Registry limita la descripción a 100 caracteres y en Glama se puede escribir más.
4. Decide si necesitas un perfil de prueba. Hasta que el perfil declare un método, Glama muestra el conector como auth:none; si tu servidor deja listar sin clave, declara el método que piden las llamadas. EveryInfra deja listar las herramientas sin clave, así que no le dimos ninguna a Glama: se conecta, lista 25 herramientas y el 24 de octubre marcaba Healthy. Solo hace falta una clave si quieres que Glama pruebe de forma periódica una llamada de datos real; el coste está más abajo.

Qué lee cada directorio del server.json

• Glama sincroniza por defecto nombre, descripción y URL desde el Registry; tras reclamar la ficha puedes hacer que manden los datos de Glama. La lista de herramientas, la disponibilidad y las notas salen de sus propias conexiones a tu servidor.
• PulseMCP tiene en pausa los envíos nuevos y los cambios desde el 3 de septiembre y recomienda publicar en el Registry; cuando reabra, leerá las fichas desde allí (página de envío de PulseMCP).
• Smithery deja de reenviar peticiones el 31 de octubre y queda como directorio público; un grupo seleccionado de servidores verificados mostrará la URL directa del fabricante (aviso de Smithery).
• Asistentes de instalación de los clientes. La documentación del Registry indica que está pensado para directorios, no para que las aplicaciones cliente lo lean directamente; los clientes deberían leer un subregistro que implemente la misma especificación OpenAPI.

La description y el websiteUrl se copian tal cual en muchos sitios, así que merece la pena cuidarlos. La lista de herramientas y las notas, en cambio, dependen del propio servidor: unas descripciones claras en tools/list pesan más que cualquier texto del directorio. Cómo mantenemos el catálogo anunciado alineado con lo que de verdad corre se explica en documentación de API desactualizada: catálogo en tiempo real.

Cuánto cuesta aparecer

• Publicar en el Registry y reclamar en Glama es gratis.
• Las comprobaciones que solo listan herramientas no tienen coste en EveryInfra.
• Si el perfil de prueba de un directorio llama una vez por hora a la capacidad de datos más barata, como la búsqueda de vídeos en TikTok, son 720 llamadas × 0,000556 USD = 0,40 USD al mes. Dale a cada directorio su propia clave, limitada a la línea de datos y con tope por minuto, para verla aparte en la factura y en la página de precios.

Qué cambió en septiembre y octubre de 2026

• 31 de octubre: Smithery cierra su proxy y sus cuentas y se queda como directorio público operado por Arcade.dev (ver el aviso citado arriba). Directorio y transporte se separan: el directorio ayuda a encontrar el servidor y la conexión va directa al fabricante.
• 19 de octubre: un analista de RedMonk explicó que el MCP Registry verifica quién publica un servidor, pero no qué hace, y que cada directorio (Glama, PulseMCP, Smithery) decide qué revisión añade (RedMonk). Para quien publica, el Registry es el punto de partida; lo que ve el usuario son los resultados de las pruebas de cada directorio.
• 21 de octubre, observación propia: Glama puso nota a las 25 herramientas de EveryInfra y registra cada cambio de herramientas y textos de parámetros (pruebas 4 y 5).
• 12 de septiembre: un censo de todo el Registry contó 21.643 servidores y 72.606 registros de versión en una instantánea de agosto de 2026. De los servidores con varias versiones, el 51,1 % cambió entre versiones las herramientas que anuncia, el 40,6 % sin avisar, y el 4,2 % movió su URL remota a otro host sin cambiar de nombre (arXiv 2609.14119). Por eso las versiones publicadas no se pueden modificar y los directorios llevan historial de herramientas.
• 3 de septiembre: PulseMCP pausó las altas y remitió a los desarrolladores al Registry (ver la página de envío citada arriba).
• Contexto: la hoja de ruta de MCP del 22 de agosto cuenta que el grupo de trabajo de Server Card está definiendo metadatos en .well-known para que un directorio pueda leer la descripción de un servidor sin conectarse (blog de MCP). Los cambios del protocolo están en especificación MCP 2026-07-28: qué comprobar al integrar.

Preguntas frecuentes

¿Hay que abrir un pull request en el repositorio del MCP Registry para publicar? No. El README del repositorio aclara que añadir un server.json, una carpeta o una entrada de datos semilla en un pull request no publica el servidor, aunque se fusione. Se publica con mcp-publisher desde tu propio proyecto.

¿Quién creó mi ficha en Glama? ¿Tengo que enviarla otra vez? Glama lee los servidores del Registry y crea las páginas de conector solo; no hay que reenviar nada. Para gestionar nombre, miniatura o perfil de prueba, reclámala como se explica arriba.

¿Puedo corregir una errata en una versión ya publicada? No. Publica una versión nueva; cuando quede marcada como latest, la mayoría de directorios la mostrará. La anterior se puede marcar como deprecated (el comando exacto que usamos está en el paso 5 de la lista).

Lecturas relacionadas

• Servidor MCP remoto con datos de 91 plataformas
• Errores de API 401, 403, 422 y 429: cómo gestionarlos
• Plataformas y capacidades: API de scraping de TikTok, API de scraping de Xiaohongshu (RedNote), API de búsqueda de Xiaohongshu, API de búsqueda de Amazon
• API de scraping: datos estructurados de 91 plataformas; consigue tu clave en el inicio rápido