Llevamos años optimizando webs para que las entiendan los robots de Google. Ahora llega otro tipo de visitante: agentes de IA que no solo leen tu web, sino que intentan hacer cosas en ella. Buscar un producto, rellenar un formulario o pedir una cita.
Para ponérselo fácil existe una propuesta nueva: WebMCP. Chrome la está probando en un origin trial y me he apuntado. Desde esta semana, esta web ofrece herramientas para agentes de IA.
Te cuento qué es, cómo lo he hecho paso a paso y, sobre todo, si a tu negocio le importa ahora mismo. Spoiler: a la mayoría todavía no, pero conviene saber de qué va.
Cómo usa hoy un agente de IA una página web
Cuando le pides a un agente que haga algo en una web, hoy lo hace más o menos como lo harías tú con los ojos tapados y alguien describiéndote la pantalla. Hace capturas o lee el código de la página, adivina qué botón es el bueno, hace clic, espera y vuelve a mirar.
Funciona, pero es lento, gasta muchos tokens y se rompe en cuanto cambias el diseño o un botón se llama distinto. Es como si Google tuviera que adivinar de qué va tu página sin títulos, sin schema y sin sitemap.
Qué es WebMCP
WebMCP es una propuesta de estándar web para que una página le diga al navegador: «estas son las acciones que se pueden hacer aquí, así se llaman, esto es lo que necesitan y esto es lo que devuelven».
Cada acción es una herramienta (tool) con un nombre, una descripción en lenguaje natural y un esquema de los datos que necesita. El agente ya no tiene que adivinar: ve la lista de herramientas, elige la que le sirve y la usa.
Algunos datos para situarlo:
- Se está desarrollando en el Web Machine Learning Community Group del W3C, con editores de Google y Microsoft. Todavía es un borrador, no un estándar cerrado.
- El nombre viene de MCP (Model Context Protocol), el protocolo con el que asistentes como Claude se conectan a herramientas externas. La diferencia es que aquí no montas ningún servidor: las herramientas viven en tu propia página y se ejecutan en el navegador de quien la visita.
- Chrome lo ofrece en origin trial desde la versión 149, según su documentación oficial. Según la consola de registro, estará disponible hasta Chrome 162 y el 30 de marzo de 2027.
Qué es un origin trial (y qué hice con el token)
Un origin trial es la forma que tiene Chrome de dejar que webs reales prueben una función experimental antes de que sea oficial. Te registras con tu dominio, te dan un token y lo pones en tu web. Mientras el token esté presente y no caduque, Chrome activa esa función para tus visitas.
El token es público (no es una contraseña) y se puede poner de dos formas. La primera es una etiqueta en el <head> de todas las páginas:
<meta http-equiv="origin-trial" content="TU_TOKEN">La segunda es una cabecera HTTP. En un servidor Apache o LiteSpeed basta con una línea en el .htaccess:
Header set Origin-Trial "TU_TOKEN"Si usas la cabecera y tienes caché o CDN, comprueba que llega una sola vez: si se duplica, Chrome junta los valores y el token deja de ser válido.
El error que cometí: marcar «Third-party matching»
Puse el token en la etiqueta y no funcionó. Con Chrome 155, mi web solo mostraba las herramientas si activaba el modo de pruebas de WebMCP en el navegador (chrome://flags/#enable-webmcp-testing), y ese ajuste solo vale para tu propio Chrome, no para tus visitas. Probé con la cabecera HTTP y tampoco.
El problema no estaba en cómo enviaba el token, sino en el propio token. Al registrarme en el origin trial había marcado la casilla Third-party matching. Suena a «más compatible», pero sirve para otra cosa: es para empresas que ofrecen un script que se incrusta en webs ajenas, como un chat o un widget. Y, según la documentación de Chrome, un token de ese tipo no funciona ni en una etiqueta <meta> ni en una cabecera HTTP: solo vale si lo inyecta un archivo JavaScript externo.
La solución fue pedir un token nuevo sin esa casilla. Con él, las herramientas aparecieron para cualquier visita, sin tocar nada en el navegador.
Dos trucos por si te pasa:
- Decodifica el token antes de usarlo. Es texto en Base64 y dentro se lee un JSON con el dominio, la función y la fecha de caducidad. Si aparece
"isThirdParty": truey el token es para tu propia web, pide otro. - Mira el estado en Chrome. En DevTools, ve a Application → Frames → top → Origin Trials. Si el token funciona verás Success. Si es third-party y lo has puesto en la etiqueta o en la cabecera, verás WrongOrigin.
Cuidao con esto porque es lo que más confunde: el token solo no hace nada. Solo enciende la función. Si después tu web no declara ninguna herramienta, los agentes no ven nada nuevo.
Las dos formas de crear herramientas
1. Declarativa: con atributos en un formulario
Es la más sencilla. Coges un formulario que ya tienes y le añades unos atributos HTML que explican qué hace. Así lo he hecho con mi formulario de contacto:
<form toolname="enviar_consulta"
tooldescription="Envía una consulta a Alicia Ruiz sobre un proyecto de SEO técnico, analítica SEO o automatización.">
<input name="name" toolparamdescription="Nombre de la persona que escribe">
<input name="email" toolparamdescription="Email al que Alicia enviará la respuesta">
…
</form>El agente puede rellenar los campos, pero la persona sigue viendo el formulario y es ella quien pulsa Enviar. Existe un atributo, toolautosubmit, para que lo envíe el propio agente, pero en un formulario de contacto prefiero que haya un humano dando el último clic.
2. Imperativa: con JavaScript
Para todo lo que no es un formulario. Registras una función con su nombre, su descripción y el esquema de lo que recibe:
document.modelContext.registerTool({
name: 'buscar_articulos',
description: 'Busca artículos del blog de Alicia Ruiz por palabras clave.',
inputSchema: {
type: 'object',
properties: { consulta: { type: 'string' } },
required: ['consulta']
},
annotations: { readOnlyHint: true },
execute: async ({ consulta }) => {
const r = await fetch('/wp-json/wp/v2/posts?search=' + encodeURIComponent(consulta));
return await r.json();
}
});Un detalle: en muchos tutoriales verás navigator.modelContext. Era el nombre de los primeros borradores y ya no es el bueno: ahora es document.modelContext. Es lo que tiene probar algo experimental, que cambia por el camino.
Qué he puesto en mi web
Mi web es de servicios y blog, no una tienda. Así que me he quedado con lo que un agente podría necesitar de verdad si alguien le pide «búscame una consultora de SEO técnico y pregúntale si me puede ayudar con mi migración»:
| Herramienta | Qué hace | Tipo |
|---|---|---|
ver_servicios | Devuelve mis servicios, qué incluye cada uno y cómo contactar | Solo lectura |
buscar_articulos | Busca en el blog por palabras clave y devuelve título, URL, fecha y resumen | Solo lectura |
leer_articulo | Devuelve el texto limpio de un artículo a partir de su URL | Solo lectura |
enviar_consulta | Rellena el formulario de contacto. La persona revisa y envía | Formulario |
Las de lectura tiran de la API REST de WordPress, que ya venía de serie, así que no he tenido que crear nada en el servidor. Todo el código son unas 100 líneas de JavaScript y unos atributos en el formulario.
Tres decisiones que tomaría igual en la web de un cliente:
- Marcar lo que es solo lectura con
readOnlyHint. Así el agente sabe que puede usarlo sin pedir permiso porque no cambia nada. - Nada que haga algo importante sin confirmación humana. Para acciones serias (pagar, reservar, borrar) existe
consequentialHint, que le indica al agente que debe preguntar antes. - Descripciones escritas para que las entienda un modelo de lenguaje, igual que escribirías una buena meta description: qué hace, para qué sirve y qué devuelve. Aquí el copy también importa.
Cómo puedes probarlo tú
- Usa Chrome 149 o superior. En esta web no tienes que activar nada: el token ya enciende WebMCP. Para probarlo en tu propia web antes de tener el token, activa
chrome://flags/#enable-webmcp-testingy reinicia el navegador (recuerda que eso solo vale para tu Chrome). - Instala la extensión Model Context Tool Inspector, que muestra las herramientas que declara cada página y deja ejecutarlas. Para hablar con el agente te pedirá una clave de la API de Gemini, que se crea gratis en Google AI Studio. Guárdala solo en la extensión y no la compartas.
- Entra en esta web y abre la extensión. Deberías ver en cualquier URL
ver_servicios,buscar_articulosyleer_articulo, y en la página de contacto tambiénenviar_consulta.
Desde la misma extensión puedes ejecutar cada herramienta a mano o escribirle al agente en lenguaje natural, por ejemplo: «Busca artículos sobre automatización con Claude, lee el más relevante y dime cómo contactar con Alicia». El agente encadena las herramientas por su cuenta: busca, lee el artículo y consulta los servicios.
buscar_articulos, elige un resultado y, sin que nadie se lo diga, usa leer_articulo con esa URL.Sin extensiones: el panel WebMCP de DevTools
Mientras lo probaba descubrí que Chrome ya trae un panel propio. En DevTools, ve a Aplicación → WebMCP (en mi Chrome 155 aparece con la etiqueta «Nuevo»). Ahí ves:
- Las herramientas disponibles en la página, con su descripción, si son de solo lectura y en qué línea del código se registraron.
- El registro de llamadas: qué herramienta se ha usado, con qué datos de entrada, qué ha devuelto y si ha dado error.
- Un botón para ejecutar cualquier herramienta a mano, sin necesidad de agente ni de clave de API.
Para depurar es mucho más cómodo que la extensión: si una herramienta no aparece o devuelve algo raro, lo ves aquí al momento.
Y Lighthouse ya lo comprueba. Lighthouse (y, con él, PageSpeed Insights) tiene una categoría nueva, «Navegación agéntica», que revisa si un agente de IA puede usar tu web y si las herramientas WebMCP están bien declaradas. Mi web saca un 3/3 jeje.
El propio informe avisa de que la categoría todavía está en desarrollo, así que tómalo como una comprobación técnica, no como una nota de SEO.
¿Esto es importante para tu negocio? Mi opinión
Hoy por hoy, para posicionar, no cambia nada. WebMCP no es un factor de ranking, no hace que Google te muestre más ni que ChatGPT o Perplexity te citen más. Y ahora mismo muy pocos agentes lo usan: es una función experimental de un solo navegador.
Pero la dirección está clara. Si los agentes acaban haciendo compras, reservas o búsquedas en nombre de las personas, las webs que les den herramientas claras tendrán ventaja frente a las que les obliguen a adivinar. Es lo mismo que pasó con los datos estructurados: al principio parecían un experimento y hoy nadie serio los ignora.
Mi recomendación según el tipo de web:
- Tiendas online, reservas, SaaS o webs con buscador interno potente: merece la pena empezar a probarlo ya, al menos en un entorno de pruebas. Ahí es donde un agente aporta más.
- Webs corporativas, de servicios o blogs: no hay prisa. Basta con tener los formularios bien hechos (con sus
<label>, campos con nombre claro y nada raro). Eso ya ayuda a los agentes de hoy, mejora la accesibilidad y te deja a dos atributos de distancia de WebMCP.
Y una advertencia: es un borrador. La API ya ha cambiado varias veces (por ejemplo, el paso de navigator a document) y puede volver a hacerlo. Si lo implementas, que sea con poco código, fácil de mantener y sin depender de ello para nada crítico.
TL;DR
WebMCP es a los agentes de IA lo que los datos estructurados fueron para Google: una forma de dejar de obligarles a adivinar. Hoy es un experimento. Implementarlo en una web sencilla cuesta una tarde y no afecta en nada a tus visitas normales.
Yo lo tengo funcionando aquí, en mi propia web, para aprender con una web real antes de recomendárselo a nadie. Si tienes una tienda, una web de reservas o un SaaS y quieres saber si te compensa preparar tu web para agentes de IA, escríbeme y lo vemos.
