Hay más de 12.000 servidores MCP en abril de 2026, repartidos en al menos 33 registros, marketplaces y directorios. Nos inscribimos en la mayoría. Dos nos indexaron antes de que preguntáramos. Un maintainer nos mandó a otro sitio. Un marketplace lleva semanas bloqueado por un bug en nuestra propia cuenta. Esta es la forma real que tiene la distribución MCP ahora mismo. Y por qué tratarla como un único mercado es el primer error.
La mayoría de los consejos sobre distribución MCP en 2026 se leen como una checklist de envío. Dar de alta en Glama, dar de alta en Smithery, dar de alta en mcp.so, enviar al Registry oficial, publicar en Reddit, escribir un artículo en dev.to. Marcar las casillas y esperar.
No es así como funciona. Después de listar cuatro productos MCP (Memory, CRM, Crew, GEO) en más de veinte plataformas durante los últimos dos meses, aprendimos una cosa: el descubrimiento MCP no es un mercado. Son cuatro mercados distintos, con reglas distintas, gatekeepers distintos y economía distinta. Los equipos que ganan son los que entienden qué mercado importa para su producto y cuál no.
Este es el mapa.
El problema del descubrimiento MCP, en concreto
Hace un año, la lista completa de servidores MCP era un README en GitHub con unas cuarenta entradas. Hoy Glama indexa más de 21.500 servidores MCP de código abierto. MCP.so tiene más de 20.000. PulseMCP está en 12.650. MCP Market reclama más de 10.000 en 23 categorías. Smithery aloja entre 7.000 y 8.000, según a quién preguntes. Hay más de 300 clientes compatibles con MCP, y los SDK oficiales superan los 97 millones de descargas mensuales.
El ecosistema es real. El problema es que ninguno de esos números se solapa limpiamente. Un servidor listado en Glama suele estar también en MCP.so y PulseMCP. Un servidor en Smithery a veces no está en ningún otro sitio. Un servidor que solo vive en GitHub con un buen README puede ser indexado automáticamente por Glama en una semana y no llegar nunca a Smithery. El Registry oficial MCP, lanzado en preview en septiembre de 2025 y mantenido por un steering group formado por Anthropic, GitHub, PulseMCP y Microsoft, debería haber unificado todo esto. En la práctica se ha convertido en una entrada más de la lista, no en el índice por encima de ella.
Si hoy publicas un servidor MCP, te dirán que lo envíes a todas partes. Mal consejo. Lleva horas, los retornos decrecen rápido y pierde el punto clave: cada directorio existe para un tipo concreto de usuario, y algunos de esos usuarios no tienen nada que ver con tu producto.
Cuatro mercados, no uno
Los directorios se ordenan limpiamente en cuatro grupos en cuanto dejas de mirarlos alfabéticamente.
El primer mercado es el Registry de protocolo: la fuente canónica oficial mantenida por los autores de la especificación. Existe para responder una única pregunta: "¿este servidor sigue el protocolo?". Su público principal son otros registros y herramientas.
El segundo mercado son los directorios comunitarios: Glama, PulseMCP, MCP.so, MCP Market. Sus usuarios son desarrolladores buscando servidores para instalar. Compiten en tamaño, frescura y en cómo de útiles son sus metadatos (badges de seguridad, contadores de visitantes semanales, listados de tools).
El tercer mercado son las awesome-lists: repositorios curados en GitHub como punkpeye/awesome-mcp-servers con 84.000 estrellas, y el más pequeño pero creciente awesome-remote-mcp-servers. Están hechos para quien ojea rápido. Gente que no quiere navegar por un marketplace, sino una lista de cosas conocidas y buenas para copiar a su configuración.
El cuarto mercado son las plataformas de monetización: Smithery, MCPize, AgenticMarket. Son canales de distribución con pagos integrados, hosting y revenue share. Les importa menos que tu servidor sea encontrable en una búsqueda y más que genere transacciones.
Una estrategia de envío que trate a los cuatro como equivalentes no optimiza ninguno. Vamos a ver qué premia cada uno realmente.
El Registry oficial es más útil de lo que parece
El Registry oficial en registry.modelcontextprotocol.io no parece gran cosa. Una lista sobria, una interfaz web minimalista, un repo en GitHub con una CLI llamada mcp-publisher. No promociona, no ranquea, no recomienda.
Ese es precisamente el punto. El Registry está diseñado como fuente de metadatos upstream para que el resto la consuma. Cuando Claude Desktop, Cursor, VS Code Copilot u otro cliente busca servidores MCP verificados, este es el primer sitio al que acude. Cuando Glama, LobeHub o un meta-registry futuro necesita un feed canónico, es de aquí de donde tira.
El envío es algo engorroso. Generas una clave Ed25519, alojas la clave pública en /.well-known/mcp-registry-auth en tu dominio, autenticas la CLI mcp-publisher y publicas un server.json con nombre en DNS invertido (io.tudominio/nombre-servidor). No hace falta una cuenta de npm para servidores hospedados, y el documento CONTRIBUTING prohíbe explícitamente los PRs. Es CLI o nada.
Hay que estar aquí. No porque los usuarios descubran tu servidor navegando por el Registry (no lo harán), sino porque cualquier directorio downstream termina tirando de él. Con nuestros cuatro productos MCP, el listado en el Registry ocurrió una vez. Todo lo demás se indexó más rápido a partir de ahí.
Directorios comunitarios: primero optimizar para auto-indexación
Los directorios comunitarios (Glama, PulseMCP, MCP.so, MCP Market) son donde los usuarios que navegan realmente descubren servidores. Aquí también es donde se detienen la mayoría de consejos sobre distribución: envía a estos, consigue usuarios, hecho.
El truco es que la mayoría auto-indexa si montas las cosas bien. Glama rastrea automáticamente repositorios públicos de GitHub con un manifiesto MCP correcto, actualiza a diario y asigna a cada servidor un badge de puntuación basado en señales como calidad del README, licencia y actividad. PulseMCP hace un indexing similar y añade un dato interesante: contador semanal de visitantes por servidor, que con el tiempo funciona como prueba social. El análisis de Apigene señala los scorecards de seguridad de Glama como el mayor diferenciador individual. Y dado que más de un tercio de los servidores MCP públicos tienen vulnerabilidades SSRF, los usuarios empiezan a filtrar por ahí.
MCP.so y MCP Market indexan más rápido, pero requieren un formulario de envío manual. Ambos llevan unos dos minutos y extraen tu README automáticamente. MCP Market hace además un review manual antes de listar.
El orden práctico: publicar un repo público en GitHub limpio con manifiesto correcto, esperar entre tres y siete días a que Glama auto-indexe, y luego enviar manualmente a MCP.so, MCP Market y FastMCP. PulseMCP indexa solo, pero un email a hello@pulsemcp.com acelera las cosas.
Una advertencia estructural. El análisis de TrueFoundry apunta que estos directorios compiten en parte por tamaño, lo que significa que muchos auto-ingieren todo lo que encuentran. Resultado: un directorio que lista "20.000 servidores" suele incluir cientos de repos muertos, forks abandonados y duplicados de baja calidad. Estar en un directorio de 20.000 servidores tiene menos valor que ser una de las 254 entradas curadas de una lista filtrada con rigor.
La división Hosted vs OSS de la que nadie habla
Esta es la lección que más tiempo nos ha costado. Las awesome-lists curadas no son una categoría, sino dos, y la línea divisoria es invisible hasta que te chocas con ella.
A principios de abril mandamos dos PRs a punkpeye/awesome-mcp-servers. Uno para nuestro servidor Memory, otro para el CRM. Los dos fueron cerrados en días. El motivo fue non-github-url. El maintainer, Frank Fiegel, solo acepta URLs de github.com/* en esa lista. Servicios hospedados como memory.studiomeyer.io se rechazan por principio, independientemente de la calidad, la licencia o la corrección del manifiesto.
No es arbitrario. Fiegel también dirige Glama, y ha creado un destino paralelo, glama.ai/mcp/connectors, específicamente para servicios hospedados. Cuando un PR hospedado se cierra, la respuesta del maintainer te dice literalmente: envíalo allí. La awesome-list es para OSS, el directorio Connectors para hospedado. Separación limpia, un maintainer, dos destinos.
Lo interpretamos mal durante semanas. Dos veces. El movimiento correcto para productos hospedados habría sido saltarse punkpeye/awesome-mcp-servers por completo e ir directamente a awesome-remote-mcp-servers (más pequeño, unas 1.000 estrellas, pero acepta URLs hospedadas) junto con Glama Connectors. Para servidores MCP de código abierto, punkpeye/awesome-mcp-servers sigue siendo el premio gordo. Un README con 84.000 estrellas en la portada de GitHub es difícil de batir para el descubrimiento orgánico.
Si estás lanzando un servicio MCP hospedado, deja de enviar a punkpeye/awesome-mcp-servers. Si estás lanzando OSS, el PR sigue valiendo la pena. La mayoría de equipos están mezclando ambas cosas.
Las plataformas de monetización están inmaduras pero mejorando
El cuarto mercado es donde el dinero realmente cambia de manos. Esta capa es la menos madura de las cuatro y la que más rápido evoluciona.
A Smithery se le describe a menudo como "el Docker Hub de MCP". Su CLI smithery mcp publish es la experiencia de desarrollador más limpia del sector, y ofrece ejecución remota alojada para servidores que no quieren gestionar su propia infraestructura. Cuando funciona, es excelente. Cuando no, está honestamente roto. El bug "Organization context required" lleva semanas bloqueando algunas cuentas, incluida la nuestra, sin una vía clara de escalado.
MCPize es la plataforma con la que más éxito hemos tenido. Gestiona hosting en Cloud Run, devuelve un 85% de revenue share al creador y tiene una integración de billing funcional para servidores MCP que cobran por llamada. El tradeoff es que hay que seguir sus convenciones de buildpack. Cloud Run no tiene egress IPv6, las conexiones Direct de Supabase son solo IPv6, así que la URL de la base de datos tiene que pasar por el pooler Supavisor. Si lo pasas por alto, el contenedor arranca, las sesiones se abren y las llamadas a tools caen silenciosamente en timeout. Quemamos un día entero con esto.
AgenticMarket es el recién llegado, con un programa Founding Creator limitado a 100 plazas y pricing por llamada integrado. Vale la pena mirar si estás lanzando un servidor MCP de pago hoy.
Lectura honesta de esta capa: construir un marketplace de monetización para MCP es el tipo de idea que ahora mismo tiene uno de cada dos desarrolladores indie, y la saturación se nota. Un comentario reciente en Reddit lo resumía bien: "Construir un marketplace para esto es low hanging fruit, totalmente saturado". Nosotros seguimos usando MCPize porque el revenue share y el gateway son genuinamente útiles. No esperamos que la mayoría de estas plataformas sobrevivan los próximos dieciocho meses.
Qué enviaría hoy si empezara de cero
Siete canales, en este orden.
Primero: publicar un repo público de solo documentación en GitHub bajo una organización limpia. El código del servidor puede quedar privado, pero la documentación, el manifiesto y las instrucciones de instalación tienen que vivir en github.com. Es el prerrequisito para todo lo demás.
Segundo: enviar al Registry oficial. Es el upstream del que todos los demás acaban bebiendo.
Tercero: esperar a que Glama auto-indexe. Si al cabo de una semana no ha pasado, enviar manualmente a glama.ai/mcp/connectors si es hospedado, o dejar que el auto-crawler encuentre el repo si es OSS.
Cuarto: enviar a MCP.so, MCP Market y FastMCP por sus formularios web. Tiempo total: diez minutos.
Quinto: decidir una plataforma de monetización. MCPize si quieres un payment rail. Smithery si quieres marca como dev. Ambas solo si tienes billing que exponer.
Sexto: publicar una extensión de VS Code. No un envío a marketplace, sino una extensión Thin Client real que conecta contra tu URL hospedada. Sin cola de approval, en vivo inmediatamente tras vsce publish. Los clientes MCP que corren sobre VS Code Copilot son el segmento de usuarios que crece más rápido.
Séptimo: escribir con honestidad sobre lo que has construido. Un artículo en dev.to desde una cuenta nueva, un post en Reddit r/mcp, un Show HN cuando haya primeros clientes de pago. No los tres en la misma semana.
Eso es todo. Siete canales, una tarde de setup, y llega a más usuarios que cualquier hoja de cálculo de 33 directorios que incluye tres sitios abandonados desde 2025.
Qué significa todo esto
La capa de marketplaces MCP en 2026 no está mal. Solo está fragmentada de una manera que premia la comprensión sobre el esfuerzo. Los equipos que están perdiendo distribución ahora no son los que enviaron a pocos sitios. Son los que enviaron a muchos sin entender qué mercado servía cada envío. El descubrimiento está roto a nivel de índice y sólido a nivel de directorio especializado. El billing aún es temprano. Las listas curadas están divididas en facciones hosted y OSS de las que nadie avisa.
Nosotros construimos servidores MCP como parte de nuestro servicio principal en StudioMeyer, y lo hemos aprendido por las malas. Si estás construyendo uno: el camino más corto es un repo público limpio, el Registry oficial, Glama y dos o tres directorios especializados. Lo demás puede esperar hasta que haya medidas de si trae usuarios reales o no.
Si quieres ver cómo es el stack completo de distribución en la práctica, publicamos nuestros servidores MCP como endpoints hospedados en memory.studiomeyer.io, crm.studiomeyer.io, crew.studiomeyer.io y geo.studiomeyer.io, con los repos de solo documentación en github.com/studiomeyer-io. El plano está abierto, los tradeoffs están documentados y la experiencia de envío sigue en marcha. Se puede copiar libremente. El ecosistema no necesita más marketplaces, necesita distribución más competente.
