MCP vs WebMCP: cómo exponer tu producto a los agentes (backend y frontend)

MCP vs WebMCP: cómo exponer tu producto a los agentes (backend y frontend)

Hace unos días un tuit de @nekuda_ai se hizo viral (2,4 millones de visualizaciones) con una pregunta incómoda: ¿Puede ChatGPT usar tu sitio web? La respuesta corta hoy es: casi nadie. La respuesta larga es el tema de este post: WebMCP, el estándar que está convirtiendo las webs en herramientas llamables por agentes, y cómo encaja con MCP, el protocolo que ya usamos en Codeia para exponer lecciones, cursos y blogs a los agentes.

El problema: los agentes no deberían adivinar tu interfaz

Durante dos años, la historia del agente navegando ha sido la misma: abre tu web, hace una captura, adivina qué píxeles son un botón, hace clic, vuelve a capturar, vuelve a adivinar. Es lento, frágil (cualquier rediseño lo rompe) y caro en tokens. Los agentes están consumiendo tu HTML pensado para ojos humanos: menús, banners, modales.

WebMCP invierte el control. En vez de que el agente reverse-engineerice tu interfaz, tu página le entrega una lista de exactamente lo que puede hacer y los argumentos tipados que cada acción necesita. "Añadir al carrito" deja de ser un botón que hay que encontrar y se convierte en una tool add-to-cart con su esquema.

Qué es WebMCP (y qué no es)

WebMCP (Web Model Context Protocol) es un estándar incubando en el W3C Web Machine Learning Community Group, co-desarrollado por Google y Microsoft, cuya spec y código viven en el repo webmachinelearning/webmcp. Chrome 146 lo trajo como preview experimental en febrero de 2026, y desde Chrome 149 (junio 2026) está en origin trial público, es decir, puedes registrarlo en producción para usuarios reales.

El nombre engaña: WebMCP no prescribe el formato de transporte. El estándar define el contrato página-navegador: cómo las webs registran tools, qué metadatos deben aportar y cómo el navegador media el acceso del agente. La implementación puede exponerlas vía MCP, vía function calling propietario o como quiera.

No es un sustituto de MCP. Son las dos mitades del mismo problema:

• MCP vive en el servidor/backend: expone datos, APIs y herramientas persistentes, disponibles siempre, con credenciales server-side. Es la fundación: tu lógica de negocio accesible desde cualquier agente, en cualquier momento.
• WebMCP vive en la pestaña del navegador: efímero, ligado a la página abierta, con la sesión autenticada del usuario y el DOM real delante. Es la capa contextual: haz esto aquí, ahora, en mi sesión.

Un producto agentic serio necesita ambos. De hecho, en Codeia llevamos esa filosofía desde el principio: nuestro monorepo codeia-nextjs incluye un MCP server (en apps/mcp-server) que expone el contenido —lecciones, blogs, cursos, progreso de usuarios— a cualquier agente; y estamos mirando WebMCP para la capa in-page.

Cómo se implementa: imperativo y declarativo

Hay dos formas de exponer una tool, y la elección depende de si tu acción es un formulario o una función.

API imperativa: document.modelContext.registerTool()

Le das a la tool un name estable, una description en lenguaje natural (lo que lee el modelo), un inputSchema en JSON Schema y una función execute asíncrona que hace el trabajo y devuelve el resultado. La función execute llama a tu lógica de aplicación existente; no reescribes nada.

Los compañeros de método: getTools() para listar lo registrado, executeTool() para ejecutar, y addEventListener('toolchange', ...) para notificar al agente cuando el conjunto de tools cambia (por ejemplo, una tool que solo existe si el usuario está logueado).

API declarativa: forms HTML

Añade unos atributos a un <form> estándar y el navegador sintetiza la tool automáticamente, sin una línea de JavaScript:

<form toolname="bookSlot" tooldescription="Reserva una consulta de 30 min" toolautosubmit>
  <input type="date" name="date" toolparamdescription="Fecha de la reserva" required>
  <input type="time" name="time" toolparamdescription="Hora de inicio (24h)" required>
</form>

Ideal para sitios estáticos, CMS o captación de leads.

Seguridad: el navegador como árbitro

Este es el punto que más preguntas genera, y la respuesta es elegante: los tools heredan la sesión del usuario. Si el usuario está logueado en tu plataforma en esa pestaña, un agente que llame a una tool WebMCP usa esa sesión — sin OAuth adicional, sin credenciales duplicadas. El navegador media cada llamada y puede forzar diálogos de confirmación para acciones sensibles.

Es una feature, no un bug: reduce la gestión de credenciales y preserva el control del usuario. Para iframes cross-origin se delega con Permissions Policy: allow="tools".

¿Y ahora qué? La ventana competitiva

El estándar sigue en movimiento: navigator.modelContext quedó deprecado en Chrome 150 en favor de document.modelContext. La recomendación del sector en 2026 es clara:

• Feature-detect: if ('modelContext' in document) y progressive enhancement: la web funciona igual sin WebMCP.
• Registra 3-5 tools core (búsqueda, presupuesto, reserva) — las de solo lectura primero.
• Gate de confirmación para toda tool que cambie estado; no apuestes checkout ni pagos hasta que la spec estabilice.
• Complementa con MCP Server Cards (/.well-known/mcp/server-card.json) para que los agentes descubran tus servidores MCP antes de conectar, y con JSON-LD para que te citen.

Los operadores que trataron WebMCP como un experimento de Chrome descubrirán que el experimento era la infraestructura. Los que ya registran tools están capturando el tráfico agentic antes que los que esperan. Nosotros, en Codeia, ya estamos en esa ola: agentes que aprenden de nuestro contenido, cursos y lecciones — y muy pronto, webs que los agentes pueden usar directamente.

Referencias y repositorios

• WebMCP (spec + código oficial): github.com/webmachinelearning/webmcp — repo del W3C Web Machine Learning Community Group, co-desarrollado por Google y Microsoft.
• WebMCP Directory (el proyecto de @nekuda_ai del tuit): webmcp.com — escanea sitios y lista cuáles exponen tools para agentes.
• Nuestro monorepo codeia-nextjs: github.com/yosnap/codeia-nextjs — el repo donde viven nuestro MCP server (apps/mcp-server), la web y el bot.

¿Quieres ver cómo se expone un producto real a los agentes? En Codeia hemos abierto nuestro MCP server y nuestro código: pruébalo, haz un fork, y cuéntanos si tus agentes consiguen aprender de nuestras lecciones.