Un catálogo MCP público para tu sitio web, sin servidor propio

Un catálogo MCP público es tu sitio expuesto como herramientas de solo lectura: planes, preguntas frecuentes, casos y glosario que un agente consulta como funciones, no como páginas que lee y adivina. Con la especificación 2026-07-28, que eliminó las sesiones del protocolo, alcanza con un Worker sin estado y los mismos JSON que tu sitio ya genera al compilar. Esta es la receta, con lo que probamos en el nuestro y lo que encontramos roto.

¿Qué es un catálogo MCP público y en qué se diferencia de otros MCP?

Un catálogo MCP público es un servidor de solo lectura que expone el contenido que tu sitio ya publica —planes, preguntas frecuentes, casos, glosario— como herramientas que un agente llama con parámetros. No requiere autenticación ni toca datos de clientes. Es distinto de un MCP de integración, como el de Mercado Pago para desarrolladores, que sirve para operar una API. El catálogo sirve para que el agente responda sobre tu negocio con tus palabras y tus cifras vigentes, en lugar de inferirlas desde HTML.

Ya explicamos qué es MCP y cómo se descubre en nuestro artículo sobre MCP para tu negocio; aquí nos concentramos en construirlo y probarlo. El caso es el de bisonagents.com, donde un Worker de Cloudflare publica diez herramientas definidas en el código a partir del contenido del sitio. Lo contamos con sus fallos incluidos, porque son la parte más útil.

¿Qué cambió en la especificación MCP que simplifica esto?

La versión 2026-07-28 convirtió el núcleo del protocolo en uno sin estado: eliminó el intercambio initialize/initialized y el encabezado Mcp-Session-Id, de modo que cada solicitud lleva la versión del protocolo, la identidad del cliente y sus capacidades (blog de MCP, 28 JUL 2026). Para un catálogo de solo lectura significa que no necesitas sesiones, almacenamiento compartido ni balanceo con afinidad: es una función HTTP común.

La especificación añade además los encabezados Mcp-Method y Mcp-Name, para que gateways y firewalls enruten sin leer el cuerpo JSON, y resultados de lista cacheables con ttlMs y cacheScope. Deprecó el transporte HTTP+SSE antiguo. Cloudflare anunció el 6 de agosto de 2026 que los servidores MCP ahora pueden correr en un Worker, sin infraestructura con estado, con su nuevo createMcpHandler.

¿Cómo se construye: del contenido al endpoint?

La regla que usamos es que el catálogo nunca tiene una copia propia del contenido. En el sitio, cada tipo de dato vive en un único módulo (preguntas frecuentes, casos, planes, glosario, tips); el build los compila a archivos JSON públicos, y el Worker los lee por HTTP con caché de una hora. Cuando se edita el contenido y se despliega el sitio, el catálogo se actualiza solo, sin redeploy del Worker.

// Contenido compilado en build: public/faqs.json (fuente única faqs.js)
async function getFaqs() {
  const r = await fetch('https://tudominio.com/faqs.json', {
    cf: { cacheTtl: 3600 },
  });
  return (await r.json()).faqs;
}

Los nombres y las descripciones de las herramientas también tienen una fuente única: un manifest que consumen el Worker y el build del sitio para generar las tarjetas de descubrimiento. La descripción es lo que el modelo lee para decidir cuándo llamar a una herramienta, así que se escribe como instrucción, no como etiqueta. El manifest evita que el card y el servidor diverjan en nombres; como veremos, no evita que diverjan en lo que está desplegado.

¿Cómo descubre un agente tu servidor?

Hay capas, de la más estable a la más experimental. El api-catalog es un estándar publicado: el RFC 9727 (IETF, junio de 2025) define la ruta /.well-known/api-catalog y un documento de enlaces para descubrir las APIs de un sitio. El server card, en cambio, sigue siendo una propuesta: la SEP-1649 plantea publicarlo en /.well-known/mcp/server-card.json, figuraba en borrador y no aparece entre los cambios de la especificación 2026-07-28. Nosotros lo servimos igual y lo anunciamos con un encabezado Link en cada respuesta del sitio.

{
  "name": "Mi sitio MCP",
  "description": "Catálogo público de solo lectura: planes, FAQs y casos.",
  "url": "https://tu-worker.workers.dev/mcp",
  "transport": "streamable-http",
  "tools": [
    { "name": "consultar_planes", "description": "Planes y precios vigentes." }
  ]
}

La capa más experimental es WebMCP, que expone herramientas desde la propia página a agentes del navegador. Es un borrador de informe del Community Group de aprendizaje automático web del W3C, y el documento aclara que no es un estándar del W3C (W3C, 12 FEB 2026). Su API ha cambiado desde que Chrome publicó la vista previa en febrero de 2026, y a nosotros nos tomó por sorpresa.

¿Qué probamos en el nuestro y qué encontramos roto?

El 6 de octubre de 2026 probamos nuestro endpoint en vivo con llamadas curl desde un equipo en Chile. Es una prueba puntual, una llamada por caso y sin pretensión de benchmark. Resultados: tools/list responde sin initialize previo, coherente con un servidor sin estado; una búsqueda en el glosario devolvió la definición correcta con HTTP 200 en cerca de un segundo, con la caché fría; e initialize con la versión 2026-07-28 devolvió esa misma versión, aunque nuestro Worker declara por defecto 2025-06-18 y no implementa las novedades de la nueva especificación, como los encabezados de enrutamiento o los resultados cacheables. Devolver la versión pedida no equivale a ser compatible, y lo corregimos en el código: ahora el Worker solo devuelve las versiones que implementa y, si le piden otra, responde con la suya.

curl -s https://tu-worker.workers.dev/mcp -H 'Content-Type: application/json' -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'

Encontramos además dos desajustes. Primero, el endpoint en vivo exponía 8 herramientas mientras nuestro server card y el código del repositorio listaban 9: faltaba listar_tips. El Worker se despliega aparte del sitio, y el card se regenera con el sitio, así que pueden quedar desfasados. Tras redesplegar el Worker, el 11 de octubre el endpoint y el card coincidían en diez herramientas, con listar_tips y la nueva listar_actualidad. Segundo, nuestro cliente WebMCP usaba navigator.modelContext.provideContext; según los análisis que revisamos (ModelPiper y la documentación del polyfill de MCP-B), provideContext salió del borrador el 5 de marzo de 2026 y el getter pasó a document.modelContext, con el alias deprecado en Chrome 150 y retirado en las compilaciones de desarrollo de Chrome 153. Como nuestro cliente solo actuaba si la API existía, fallaba en silencio. Lo actualizamos para usar document.modelContext y registerTool, con la API vieja solo como respaldo. No lo verificamos contra la documentación de Chrome, solo contra esos análisis.

La lección es práctica: un catálogo MCP es un contrato, y los contratos se prueban contra el servicio real, no contra copias. Como señala ModelPiper al analizar el cambio de WebMCP, una suite verde sobre una capacidad simulada no dice nada de lo que existe en producción. Nuestra prueba mínima es comparar tools/list con el card en cada deploy, y ahora la automatizamos con un script que falla si no coinciden.

¿Y qué pasa en LatAm?

El MCP más visible de la región es el de Mercado Pago: un servidor oficial en mcp.mercadopago.com, con herramientas para buscar documentación, gestionar aplicaciones, configurar webhooks y crear usuarios de prueba, compatible con clientes como Cursor, VS Code, Claude y ChatGPT (documentación para desarrolladores de Mercado Pago). Es un MCP de integración para quien construye, no un catálogo de contenido para quien compra. Sobre el caso de Mercado Libre, ya lo analizamos en otro artículo.

No encontramos un estudio público que mida cuántos sitios de la región publican un catálogo MCP de su propio contenido, y esa ausencia es, en sí, un dato: no sabemos cuántas marcas lo hacen. Lo que sí sabemos es que el costo de entrada es bajo: el plan gratuito de Workers permite 100.000 solicitudes diarias, 10 ms de CPU y 50 subrequests por solicitud (documentación de Cloudflare).

Qué hacer esta semana

1. Elige qué contenido ya es público y estructurado. Planes, preguntas frecuentes, casos, glosario: lo que hoy está en tu sitio y no cambia por usuario. Mantenlo en un solo módulo por tipo de dato.
2. Compila ese contenido a JSON en el build. El Worker lee el JSON, no el HTML; así el catálogo se actualiza con cada deploy del sitio y no tiene copia propia.
3. Define herramientas de solo lectura con descripciones claras. Escribe cada descripción como la instrucción que el modelo leerá para decidir cuándo usarla; pocas herramientas, bien nombradas.
4. Publica el server card y enlázalo. Sírvelo en /.well-known/mcp/server-card.json, anúncialo con un encabezado Link y suma el api-catalog (RFC 9727). Tómalo como una convención en evolución.
5. Prueba el contrato en cada deploy. Compara tools/list del endpoint real contra el card, y no confíes en que el Worker desplegado sea el último. Si usas WebMCP, pruébalo en un Chrome real.

Preguntas frecuentes