WebMCP en octubre de 2026: cómo hacer que un sitio web sea utilizable por agentes de IA y qué significa de verdad el origin trial

WebMCP permite que una página web entregue a un agente de IA una lista corta de cosas que puede hacer, cada una con un nombre, una descripción y un esquema de entrada, en lugar de dejar que el agente deduzca la página a partir de capturas de pantalla y del DOM. Un agente que encuentra una herramienta check_order_status puede llamarla con un número de pedido. Sin ella, el agente tiene que localizar el campo correcto y pulsar el botón correcto.

Esa es la promesa. El estado de la cuestión a 22 de octubre de 2026 es más limitado de lo que sugieren casi todos los análisis. WebMCP es una propuesta de un Community Group del W3C, no un estándar. Chrome lo ofrece como origin trial, sin que se haya decidido todavía lanzarlo. Solo un agente de consumo llama a las herramientas (el navegador integrado en la app de escritorio de ChatGPT), y ese agente ignora la versión declarativa con formularios, que se eliminó de la especificación el 8 de octubre. El equipo del motor de Safari se opone a la propuesta; Mozilla es neutral.

Este artículo es para desarrolladores y responsables de producto que están decidiendo si añadir WebMCP ahora. Explica qué es la API, quién la llama, cómo activarla para visitantes reales, cómo escribir herramientas que no pongan un arma cargada en manos de un agente y qué arreglar primero si lo que quieres es que los agentes usen tu sitio.

Qué es WebMCP

La especificación define una API de JavaScript en document.modelContext mediante la cual una página registra herramientas: «La API de WebMCP permite que las aplicaciones web ofrezcan a los agentes de IA herramientas basadas en JavaScript». Una herramienta tiene un name, una description y una función de retorno execute, y de forma opcional un title, un inputSchema (JSON Schema) y annotations. Cuando el agente llama a la herramienta, se ejecuta el propio código de la página, con la sesión del usuario.

Hay tres cosas que es fácil entender mal:

• No es un estándar. El documento es un Draft Community Group Report del Web Machine Learning Community Group, y lo dice así: «No es un estándar del W3C ni está en la vía de estándares del W3C». La propia documentación de Chrome lo llama «un estándar web propuesto». La fecha del informe ha ido cambiando cada pocos días en octubre; sus editores son de Microsoft y de Google.
• No hay MCP en él. La especificación dice que las páginas que lo usan «pueden considerarse servidores del Model Context Protocol que implementan herramientas en scripts del lado del cliente», y después que «no prescribe el formato en que se exponen las herramientas al agente del navegador». La revisión de Mozilla lo dijo sin rodeos: «El nombre induce a error ... Aquí no hay MCP». Una herramienta de WebMCP no se conecta a tu servidor MCP de backend, ni lo sustituye.
• No hace que te descubran. La documentación de Chrome enumera por sí misma la limitación: «Los clientes y los navegadores tienen que visitar un sitio directamente para saber si tiene herramientas invocables». WebMCP ayuda a un agente que ya está en tu página. No hace nada para que te encuentren.

La API se limita a contextos seguros y está controlada por una Permissions Policy llamada tools, cuya lista de permitidos por defecto es 'self', de modo que un iframe de otro origen no puede registrar herramientas salvo que la página que lo incrusta lo permita.

Dónde está a 22 de octubre de 2026

Chrome 156, la última versión de la ventana original del trial, llegó al canal estable el 20 de octubre de 2026. Chrome 162, el final de la ampliación solicitada, está previsto para el canal estable el 2 de febrero de 2027. No se pudo confirmar desde la consola del trial si la ampliación está en marcha, así que conviene planificar como si fuera probable, pero no segura.

La solicitud de ampliación explica por qué Chrome quiere más tiempo: «Los comentarios del OT han sugerido mejoras en la API, que estamos implementando». En el mismo hilo, Dominic Farolino, de Google, escribió que el equipo espera «pasar a I2S dentro de la ventana de ampliación», es decir, pedir el lanzamiento, y que «La API imperativa es mucho más popular que la declarativa, así que estamos invirtiendo más en ella para responder a las necesidades de los usuarios». También mencionó que se están prototipando una API de continuación, una API de estabilidad de herramientas y límites al tamaño de las herramientas. La API con la que programes hoy va a cambiar.

Quién llama de verdad a las herramientas

Registrar herramientas no requiere nada. Usarlas requiere un agente, y la lista de agentes es corta.

Las extensiones de prueba de Chrome. La documentación de Chrome ofrece dos extensiones, entre ellas Model Context Tool Inspector, para probar herramientas en demos y en tus propias páginas. Necesitan tu propia clave de API de un modelo, y Chrome señala: «Estas extensiones son independientes de Gemini en Chrome». Son herramientas para desarrolladores, no clientes.

El navegador integrado de ChatGPT. Un mensaje de un empleado de OpenAI en su foro de desarrolladores decía el 25 de agosto de 2026 que «Site tools es la implementación que hace ChatGPT del estándar propuesto WebMCP». Su documentación impone condiciones: modelos concretos, la última versión de la app de escritorio, que un administrador lo permita en los espacios de trabajo Enterprise, ningún espacio de trabajo Edu y «La disponibilidad también depende del despliegue». También enumera lo que no admite: «API declarativa: las herramientas definidas mediante atributos de formularios HTML no están disponibles como site tools», y las herramientas registradas dentro de iframes, incluidos los del mismo origen. La instrucción de OpenAI es clara: «Usa JavaScript para registrar las herramientas en la página de nivel superior». La documentación no dice si una página necesita un token del origin trial de Chrome para que ChatGPT vea sus herramientas.

Gemini en Chrome. Google dijo en mayo que «pronto admitirá las API de WebMCP». No hemos encontrado ninguna fuente primaria posterior que diga que ya lo hace. Todavía no construyas un plan sobre ello.

Todos los demás recurren a lo de siempre. Todos los agentes de todos los navegadores siguen leyendo las páginas como antes. Chrome lo dice en su propia evaluación de riesgos: «Los agentes de navegador de Chrome pueden seguir accionando los sitios como antes, simulando comportamientos del usuario». OpenAI: «Si no hay ninguna herramienta adecuada, el agente aún puede usar sus capacidades normales de navegación». Un sitio sin WebMCP no es invisible para los agentes. Un sitio con botones rotos y campos sin etiqueta es difícil para todos ellos.

La API imperativa

Es la versión que define la especificación, la que admite ChatGPT y la que, según Chrome, prefieren los desarrolladores. Una herramienta envuelve lógica que la página ya tiene. Este es un acceso de solo lectura para un cliente con sesión iniciada, siguiendo el esquema de la documentación de Chrome y la detección de funciones de OpenAI:

if (typeof document.modelContext?.registerTool === 'function') {
  const tools = new AbortController();

  await document.modelContext.registerTool({
    name: 'check_order_status',
    description: 'Look up the status and tracking link of one of the signed-in customer\'s orders by its order number.',
    inputSchema: {
      type: 'object',
      properties: {
        orderNumber: { type: 'string', description: 'Order number as printed in the confirmation email' },
      },
      required: ['orderNumber'],
    },
    annotations: { readOnlyHint: true },
    execute: async ({ orderNumber }, { signal }) => {
      const res = await fetch(`/api/orders/${encodeURIComponent(orderNumber)}`, { signal });
      if (!res.ok) return `No order ${orderNumber} was found on this account.`;
      const order = await res.json();
      return `Order ${orderNumber}: ${order.status}. Tracking: ${order.trackingUrl ?? 'not available yet'}.`;
    },
  }, { signal: tools.signal });

  // When the page state no longer fits the tool:
  // tools.abort();
}

Lo que importa de este código:

• El nombre, la descripción y el esquema son lo que lee el modelo. Chrome recomienda como máximo 500 caracteres por descripción de herramienta, 150 por descripción de parámetro, 30 por nombre de herramienta y de parámetro, y 1,5K caracteres por salida de herramienta, y avisa de que «Estas recomendaciones pueden cambiar». El explainer de la especificación advierte de que «Exponer demasiadas herramientas (p. ej., docenas o cientos) puede degradar gravemente el rendimiento del agente»: registra lo que necesita el estado actual de la página y retira el resto con la señal del AbortController.
• El segundo argumento de execute lleva un AbortSignal, de modo que una llamada cancelada pueda detener una petición en curso.
• Las anotaciones son pistas. readOnlyHint marca una consulta. consequentialHint marca todo lo que reserva, compra, envía, borra o transfiere, y la documentación de Chrome dice que «permite que los agentes y los navegadores exijan avisos de confirmación obligatoria al usuario». untrustedContentHint marca la salida que contiene reseñas, contenido de usuarios o datos de terceros. Desde Chrome 156 existe una anotación debugging.
• El código de la página también puede listar y ejecutar herramientas, con document.modelContext.getTools() y executeTool(), y se dispara un evento toolchange cuando cambia la lista. Los argumentos convertidos en cadena JSON en executeTool() están obsoletos desde Chrome 155.

React, Angular y Vue tienen cada uno ayudas experimentales, y el paquete webmcp-types de npm aporta los tipos de TypeScript. Los tutoriales antiguos que llaman a navigator.modelContext están desfasados: la especificación movió la API a document el 27 de mayo de 2026.

La API declarativa: en el trial de Chrome, fuera de la especificación

La versión declarativa convierte un formulario HTML existente en una herramienta con dos atributos. Resulta atractiva para sitios antiguos y con muchos formularios, porque no hay que cambiar nada más:

<form toolname="request_quote"
      tooldescription="Send a request for a quote. The user reviews the form and submits it."
      action="/quote" method="post">
  <label for="email">Work email</label>
  <input id="email" name="email" type="email" required>
  <label for="details">What you need</label>
  <textarea id="details" name="details" required></textarea>
  <button type="submit">Send</button>
</form>
<script>
  document.querySelector('form[toolname]').addEventListener('submit', (e) => {
    e.preventDefault();
    const sent = sendQuoteRequest(new FormData(e.target)); // your existing submit, returning a promise
    if (e.agentInvoked) e.respondWith(sent.then(() => 'Quote request sent.'));
  });
</script>

En el trial de Chrome, «Cuando un agente llama a toolname, el navegador pone el foco en el formulario y rellena sus campos. El formulario sigue visible para el usuario». El navegador construye los parámetros a partir de los controles: sus nombres, sus <label>, required y las opciones de un <select>. Salvo que el formulario lleve toolautosubmit, «El usuario debe pulsar Enviar manualmente para completar la tarea», que es lo que quieres en cualquier cosa que haga un pedido o envíe un lead. SubmitEvent.agentInvoked avisa a tu controlador de que un agente ha rellenado el formulario, y respondWith(), tras preventDefault(), devuelve el resultado al agente. Escucha los eventos toolactivated y toolcancel en document.modelContext con addEventListener: window.ontoolactivated y window.ontoolcancel no se admiten desde Chrome 156.

El problema es su estado. El cambio más reciente del explainer, el 8 de octubre de 2026, se titula «Remove declarative API from the spec for now» y ahora dice que una contrapartida declarativa «se está explorando por separado ... pero no forma parte de la especificación en este momento». ChatGPT no la admite. Chrome sigue documentándola en el trial, y Farolino, de Google, sostuvo en el hilo de Mozilla que «vemos valor en la propuesta declarativa simplemente para los sitios heredados, sobre todo los basados en formularios». Tómala como un experimento de Chrome dentro de un experimento: sirve para probar, pero no conviene que sea tu única vía.

Cómo activarlo para visitantes reales

Un flag (chrome://flags/#enable-webmcp-testing) activa WebMCP en tu propio navegador para hacer pruebas. No hace nada por los visitantes. Para ellos, la página necesita un token de origin trial.

1. Registra el origen en la página del trial de WebMCP de Chrome. Los origin trials «son públicos y están abiertos a todos los desarrolladores», y un token «habilita una función para todos los usuarios de tu origen».
2. Sirve el token en cada página que deba exponer herramientas, como <meta http-equiv="origin-trial" content="..."> en el <head> o como cabecera de respuesta Origin-Trial:. Un token también puede inyectarse desde un script. Un token cubre un origen; una página puede llevar varios.
3. Renuévalo. Cuando se amplía un trial, Chrome pide a los inscritos que «proporcionen un token nuevo para cada origen inscrito en el trial», y «Chrome ignora los tokens no válidos o caducados». Un token caducado falla en silencio: las herramientas simplemente dejan de aparecer.
4. Para Edge, regístrate por separado en la página de su trial. Sus condiciones piden que «Siempre que sea posible, aceptes aplicar detección de funciones / degradación elegante».

Las auditorías de WebMCP de Lighthouse también requieren el registro en el trial, así que un sitio que las pruebe sin token verá que fallan.

Cómo escribir herramientas que se puedan llamar con seguridad

La sección de seguridad de la especificación no es normativa, y es franca sobre dónde recae la carga: impedir que se manipule a un agente «es sobre todo responsabilidad del propio modelo de seguridad del agente, más que algo que esta especificación pueda imponer de forma normativa». Tus herramientas siguen decidiendo cuánto daño puede causar un agente manipulado.

• Las pistas pueden mentir, así que los agentes no se fiarán de ellas. La especificación: «un sitio malicioso puede omitir o falsear esas pistas». OpenAI: «El nombre de una herramienta o su afirmación de que solo lee datos no demuestra lo que hace de verdad», y cada llamada en su navegador pasa una revisión de seguridad, con confirmación todavía obligatoria para las compras y acciones parecidas. Aun así, anota con honestidad. Es lo que usa un agente prudente para decidir cuándo preguntar al usuario.
• Describe los efectos con exactitud. El mal ejemplo de la propia especificación es una herramienta descrita como «Finaliza el carrito de la compra actual» que «en realidad desencadena una compra. El usuario no tenía intención de comprar nada». Si una herramienta cobra una tarjeta, la descripción lo dice y consequentialHint es true.
• Autoriza en el servidor, siempre. La herramienta se ejecuta con la sesión del usuario: la especificación señala que «Los agentes pueden heredar la identidad y el contexto de autenticación del usuario desde el navegador». Una llamada a una herramienta es una petición de ese usuario y recibe las mismas comprobaciones. El consejo del explainer sigue valiendo: «Valida de forma estricta en el código, de forma laxa en el esquema», porque los fallos estrictos de esquema pueden hacer que los agentes se atasquen.
• Cuenta con la inyección de prompts. La especificación la enumera la primera, en tres formas: instrucciones ocultas en los metadatos de la herramienta, en su salida y ataques que usan las herramientas como objetivo. La salida que contiene texto escrito por otras personas (reseñas, mensajes, preguntas sobre productos) va bajo untrustedContentHint, y debe devolverse como datos y no como prosa que un agente pueda tomar por instrucciones.
• Excluye páginas de forma deliberada. Una cabecera Permissions-Policy: tools=() hace que la API no esté disponible para un documento ni para nada de lo que incrusta. Los ajustes de la cuenta, las páginas de pago y las pantallas de administración son candidatas.

Una advertencia sobre la documentación de Chrome: su página de seguridad dice que el borrador incluye un método requestUserInteraction() para preguntar al usuario en mitad de una herramienta. El borrador de la especificación del 20 de octubre de 2026 no tiene ese método, y el explainer sigue enumerando la confirmación del usuario como una cuestión abierta. No diseñes en torno a él.

A qué se oponen los ingenieros de Safari y Firefox

Las objeciones merecen leerse aunque solo desarrolles para Chrome, porque describen cómo puede salir mal WebMCP en la práctica.

La posición de WebKit, publicada el 3 de junio de 2026, sostiene que las páginas difíciles de usar deben arreglarse en HTML y ARIA, «donde se benefician el usuario, la tecnología de asistencia y los agentes», y que con las herramientas «la fragilidad simplemente se traslada del DOM a las descripciones de las herramientas». Trata a un agente como tecnología de asistencia a la que no se debe señalar: «WebMCP hace lo contrario, y convierte “un agente está al volante” en un hecho observable». Y señala que la propuesta «no tiene ningún modelo de consentimiento ni de reversibilidad para las acciones con consecuencias».

Mozilla se decantó por la neutralidad en agosto: WebMCP «introduce una abstracción potencialmente valiosa», pero «abre una superficie cuya dinámica real deja demasiadas preguntas abiertas para respaldarla sin reservas». Advierte de que los sitios podrían «ofrecer herramientas que no coinciden con la experiencia de un usuario en la página», por ejemplo para «proporcionar una inyección de prompts invisible para los usuarios habituales». Algunos ingenieros de Mozilla a título individual han mostrado interés en una primitiva imperativa de llamada a funciones; eso no es un respaldo de Mozilla.

El propio Chrome considera bajo para los usuarios el riesgo de que otros motores no adopten WebMCP. La otra cara de esa moneda es que un sitio no gana nada en Safari ni en Firefox por añadir herramientas hoy.

Lo que funciona hoy con cualquier agente

Todos los agentes de navegador leen capturas de pantalla, HTML y el árbol de accesibilidad. La guía de web.dev de Google sobre sitios aptos para agentes dice que los agentes «usan el DOM y el árbol de accesibilidad para obtener una lista limpia y estructurada de elementos interactivos y luego la contrastan con una representación visual». Su lista práctica es corta:

• Usa elementos <button> y <a> reales, no <div> ni <span> en los que se pueda hacer clic.
• Vincula cada <label> a su campo con for.
• Nada de superposiciones transparentes sobre elementos interactivos, y nada interactivo de menos de 8 píxeles cuadrados.
• Un diseño estable, que no se desplace mientras el agente se dispone a hacer clic.

Su conclusión: «Todo lo que sugerimos para que un sitio esté “listo para agentes” también mejora los sitios para las personas». Es también, casi palabra por palabra, lo que WebKit pide en lugar de WebMCP. Si tu checkout no pasa una auditoría de accesibilidad, arregla eso antes de escribir una sola herramienta.

Lighthouse tiene una categoría Agentic Browsing desde la versión 13.2.0 (1 de mayo de 2026), disponible en Chrome desde la versión 150, y se habilitó para la API de PageSpeed Insights en Lighthouse 13.4.1 (20 de julio de 2026). Comprueba el subconjunto de auditorías de accesibilidad que importan a las máquinas, la estabilidad del diseño, las herramientas de WebMCP registradas y los formularios que no las tienen, la validez del esquema y la presencia de un archivo llms.txt. Chrome la describe como «informativa y sin referencias de comparación»: no hay una puntuación de 0 a 100. Sobre llms.txt, la propia guía de la Búsqueda de Google es que ignora esos archivos: añadir uno «ni perjudicará ni ayudará a la visibilidad o la posición de tu sitio en la Búsqueda de Google». Que Lighthouse compruebe el archivo no cambia eso.

¿Conviene añadir WebMCP ahora?

En Shopify con un tema Liquid: no hay que hacer nada. Las herramientas de tienda, carrito y checkout de Shopify ya están activas, «No hay nada que instalar ni configurar», con la salvedad de Shopify de que «la compatibilidad con agentes se limita por ahora a los navegadores basados en Chromium mediante un origin trial». Las tiendas headless solo están cubiertas por la developer preview de Hydrogen. No hemos encontrado ninguna otra plataforma de comercio, proveedor de pagos o CDN que active WebMCP para sus clientes.

En un sitio a medida, headless o heredado: depende de quiénes sean tus usuarios.

• Si tus clientes o tu personal usan el navegador de la app de escritorio de ChatGPT, las herramientas imperativas en la página de nivel superior son las únicas que les llegan. Empieza con dos o tres herramientas de solo lectura en torno a tu tarea más habitual (estado de un pedido, disponibilidad, un presupuesto), con detección de funciones, con un token de origin trial, y mide si alguien las llama.
• Si quieres experimentar a bajo coste en Chrome, los atributos declarativos sobre formularios existentes son cuestión de unas pocas horas. No te quedes ahí: ChatGPT no los verá, y la especificación ya no los contiene.
• Si no tienes ninguna prueba de que los agentes te visiten, arregla primero la semántica, las etiquetas y el diseño. Ese trabajo ayuda a todos los agentes y a todas las personas que usan tecnología de asistencia, y nada de él se tirará cuando cambie la API.

En todos los casos, mantén completa la interfaz normal. El consejo de OpenAI: «Conserva la interfaz normal para las personas y los navegadores que no admiten WebMCP».

Qué podría cambiar

• Un Intent to Ship. El equipo de Chrome espera pedirlo dentro de la ventana de ampliación, que termina con Chrome 162 (2 de febrero de 2027) si la ampliación se mantiene. El lanzamiento eliminaría la necesidad de tokens en Chrome.
• La forma de la API. Se están prototipando una API de continuación (resultados que llegan a la página siguiente tras una navegación), una API de estabilidad de herramientas y límites de tamaño. Las versiones recientes ya eliminaron window.ontoolactivated y los argumentos convertidos en cadena.
• El destino de la API declarativa. Fuera de la especificación «por ahora», todavía en el trial de Chrome.
• Quién llama. La compatibilidad de Gemini en Chrome se ha anunciado, pero no se ha lanzado. La página de estado de implementaciones de la especificación incluye WebMCP para aplicaciones web en las gafas Ray-Ban Display de Meta como próximamente, y compatibilidad experimental en el asistente Leo de Brave.

Si añades herramientas ahora, déjalas en un único módulo y tras la detección de funciones, para que el siguiente cambio sea una sola edición.

Dónde conseguir ayuda

Desarrollamos las partes de un sitio web y de su backend que tocan los agentes: herramientas que envuelven la lógica existente de pedidos, reservas y cuentas, una autorización que trata la llamada de un agente como cualquier otra petición de ese usuario, y las correcciones de semántica y accesibilidad que hacen utilizable un sitio antes de que exista ninguna herramienta. Nuestro servicio de desarrollo de agentes de IA e integración MCP cubre las herramientas de WebMCP y también los servidores MCP de backend, que son otra cosa a pesar del nombre.

Si quieres saber qué ve hoy un agente en tu sitio y si las herramientas cambiarían algo para tus clientes, escribe a office@c9group.dev.