Web agéntica y WebMCP: sitios que un agente puede operar

La web agéntica ya tiene estándar y se llama WebMCP. Cómo ve tu sitio un agente, y lo que aprendí implementándolo en dos sitios en producción.

La web agéntica es el escenario en que un agente de IA no solo lee tu sitio, sino que lo usa: busca, filtra, llena formularios y completa tareas en nombre de una persona. Y ahí aparece el problema que casi nadie está mirando: tu sitio fue diseñado para que un humano entienda dónde hacer clic, no para que una máquina sepa qué acciones existen.

Ese hueco ya tiene un estándar que intenta cerrarlo. Se llama WebMCP, lo escriben ingenieros de Google y Microsoft dentro del W3C Web Machine Learning Community Group, y desde Chrome 149 se puede probar en producción con un origin trial. Lo tengo implementado en este sitio y en milimetrix.com. Este artículo cuenta qué es, cómo funciona de verdad, cuál de sus dos APIs conviene usar en cada caso, y qué cuesta exponer tus acciones a los agentes sin romperle el sitio a las personas.

Qué es la web agéntica

La web agéntica es el modelo de internet en que los agentes de IA actúan como intermediarios entre la persona y los sitios: buscan, comparan, completan formularios y ejecutan tareas sin que el usuario navegue la interfaz. El sitio deja de ser solo un documento que se lee y pasa a ser un servicio que se opera. La consecuencia práctica es que la web ya no tiene un solo tipo de visitante.

La diferencia con el sitio que ya conoces está en el verbo. Un sitio optimizado para buscadores se deja leer: entrega texto, encabezados y datos estructurados para que una máquina los entienda. Un sitio preparado para la web agéntica además se deja usar: declara qué acciones se pueden ejecutar, con qué parámetros y con qué permisos. Leer y operar son dos capacidades distintas, y hoy casi todos los sitios resuelven solo la primera.

Cómo ve tu sitio un agente de IA: captura de pantalla, HTML y árbol de accesibilidad

Google documenta en web.dev que un agente puede acceder a un sitio de tres formas distintas, y cada una tiene un costo y una fragilidad propia. La primera es la captura de pantalla: el agente renderiza la página y usa un modelo de visión para identificar elementos. Es cara, lenta y se rompe con cualquier cambio de maqueta. La segunda es el HTML: el agente analiza el DOM, su anidamiento y sus atributos. La tercera es el árbol de accesibilidad.

El árbol de accesibilidad es el que importa. Google lo describe como una API nativa del navegador que destila el DOM y deja lo esencial: roles, nombres y estados de los elementos interactivos. Es el mismo mapa que usan los lectores de pantalla, y para un agente funciona como un plano de alta fidelidad que ignora el ruido visual del CSS. Si tu botón es un div con un onclick, no tiene rol ni nombre, y en ese plano simplemente no aparece.

De ahí salen recomendaciones que suenan viejas y que ahora tienen una consecuencia nueva. Google pide preferir button y a antes que div y span intervenidos, porque los agentes los reconocen como interactivos. Si no queda otra que usar un elemento genérico, hay que darle el role y el tabindex que corresponde, y cursor: pointer en CSS funciona como señal de accionabilidad. Los label deben ir enlazados a su input con el atributo for para que el agente sepa qué se le está pidiendo en cada campo.

Hay dos exigencias más que suenan menores y no lo son. Google pide layout estable, porque un agente que trabaja con capturas se confunde si el botón de comprar cambia de lugar entre categorías de producto. Y pide que los elementos interactivos necesarios para completar el recorrido tengan un área visible mayor a 8 píxeles cuadrados, sin capas transparentes ni elementos fantasma encima.

Nada de esto es nuevo. Es accesibilidad web bien hecha, que llevamos veinte años pidiendo y que ahora, además, decide si un agente puede comprarte.

Por qué el JavaScript se volvió el cuello de botella de la web agéntica

Un sitio que entrega su contenido solo después de ejecutar JavaScript queda fuera del alcance de la mayoría de los agentes. Googlebot ejecuta JS, con límites, pero la mayoría de los bots y agentes que hoy recorren la web no lo hacen de forma confiable. Lo que aparece recién después de hidratar la página, para ellos, no existe.

Alfonso Moure lo planteó con precisión en su conversación con Gianluca Fiorelli en The Search Session, en julio de 2026: el TTFB, el tiempo hasta el primer byte, deja de ser una métrica de rendimiento y pasa a ser una métrica de visibilidad. La información que importa tiene que venir en la primera respuesta del servidor, no en la tercera petición del cliente. Su ejemplo era el peor caso posible del ecommerce: el stock y el precio en tiempo real, que son justo los datos que más se resuelven por JavaScript y justo los que un agente necesita para decidir.

Esto ordena las prioridades de una forma incómoda para muchos equipos. Renderizar en servidor los datos que deciden una acción (precio, disponibilidad, plazos, condiciones) vale más que cualquier optimización de contenido. Si el dato llega tarde, el agente decide sin él.

Cómo se trabaja esa capa de rendimiento está desarrollado en la guía de SEO técnico y Core Web Vitals.

Qué bots de IA pueden entrar a tu sitio y qué se pierde al bloquearlos está en la guía de robots.txt y bots de IA.

Qué es WebMCP y en qué se diferencia de que un agente raspe tu HTML

WebMCP es una propuesta de estándar web que permite a una página registrar herramientas para que los agentes de IA las invoquen, en lugar de deducir la interfaz mirándola. El sitio declara qué acciones existen, qué parámetros necesita cada una y qué devuelve. La propuesta la escribe el W3C Web Machine Learning Community Group, con autores de Google y Microsoft, y su explainer se publicó por primera vez en agosto de 2025.

La API es más simple de lo que sugiere el nombre. Se llama a document.modelContext.registerTool() pasando cuatro cosas: un nombre, una descripción en lenguaje natural que el modelo lee para decidir cuándo usarla, un inputSchema en JSON Schema que declara los parámetros, y una función execute que hace el trabajo. Se le puede añadir un objeto annotations para marcar la herramienta como de solo lectura, y un AbortSignal para desregistrarla después.

El estado importa tanto como la API. Chrome abrió el origin trial de WebMCP en la versión 149, y para pruebas locales existe el flag chrome://flags/#enable-webmcp-testing. Es una propuesta en evolución, no una API estable: la propia documentación de Chrome invita a comentar la forma de la API en GitHub. Quien lo implemente hoy tiene que asumir que puede cambiar.

Los límites declarados son la parte que más se ignora y la más reveladora del diseño. WebMCP solo funciona en documentos aislados por origen y se desactiva si se toca document.domain. Está controlado por una permissions policy llamada tools, que por defecto vale self, así que un iframe de otro origen no puede exponer herramientas salvo que se lo permitas explícitamente. Y no hay soporte para que un agente ejecute tools en estado headless.

Ese último punto no es una limitación técnica pendiente, es una decisión. Entre los non-goals que el explainer declara están el navegado headless y los flujos completamente autónomos sin supervisión humana. WebMCP no fue diseñado para que un bot opere tu sitio a solas. Fue diseñado para que un agente asista a una persona que está ahí, con el navegador abierto.

WebMCP imperativo y declarativo: dos formas de exponer lo mismo

WebMCP tiene dos APIs, y elegir mal cuesta caro. La imperativa se escribe en JavaScript y registra herramientas llamando a document.modelContext.registerTool(). La declarativa se escribe en HTML: se anota un formulario con los atributos toolname y tooldescription, y el navegador lo convierte solo en una herramienta con su JSON Schema, derivando los parámetros de los campos del formulario.

La regla práctica que saqué usándolas: si la acción ya es un formulario, va declarativa. Si la acción es traer datos que el formulario no representa, va imperativa.

Y hay un argumento que pesa más que la comodidad. El JavaScript deja a los agentes afuera, y la API declarativa es justamente la que no depende de JavaScript: los atributos viven en el HTML que el servidor ya entrega. Un sitio que expone sus acciones críticas solo por la vía imperativa reintroduce, en la capa de herramientas, exactamente el problema que estaba tratando de resolver en la capa de contenido.

Cómo implementé WebMCP en dos sitios en producción

Tengo WebMCP corriendo en este sitio y en milimetrix.com, y la decisión que más tiempo me tomó no fue técnica: fue cuáles herramientas no exponer. En cristobalcazor.com hay cuatro tools. Tres son globales y de solo lectura. La cuarta escribe, y por eso no es global.

Esa última fila es la regla que más recomiendo copiar. Una herramienta que modifica estado se registra únicamente en la página donde ese estado existe, no en el layout global. Y pre-llena, no envía: la persona revisa y aprieta el botón. Es human in the loop, y coincide con un non-goal explícito de la especificación. El día que un agente mande un mensaje en nombre de alguien que no lo revisó, el problema no va a ser de código.

const mc = document.modelContext ?? navigator.modelContext;
if (!mc?.registerTool) return;

const controller = new AbortController();

mc.registerTool(
  {
    name: "get_blog_post",
    title: "Leer un artículo completo",
    description: "Devuelve el contenido completo de un artículo del blog en formato markdown, a partir de su slug.",
    inputSchema: {
      type: "object",
      properties: {
        slug: { type: "string", description: "Identificador del artículo" }
      },
      required: ["slug"]
    },
    annotations: { readOnlyHint: true },
    execute: async ({ slug }) => serializeBlocks(BLOG_CONTENT[slug])
  },
  { signal: controller.signal }
);

Hay cuatro cosas que aprendí implementándolo y que no vi escritas en ningún lado.

La detección tiene que cubrir dos superficies. La API se movió de navigator a document, y la documentación de Chrome lo dice sin rodeos: navigator.modelContext quedó deprecado en Chrome 150. Como no todos los navegadores en circulación van a la misma velocidad, el sitio resuelve document.modelContext y cae a navigator.modelContext si no existe. Si no encuentra ninguna, no hace nada. El registro además va dentro de un try/catch, porque un navegador con soporte parcial no puede romper la página de nadie.

El explainer y Chrome no dicen lo mismo sobre qué devuelve execute. El explainer del W3C muestra un objeto con un arreglo de contenido tipado. La documentación de la API imperativa de Chrome devuelve texto plano. Implementé sobre la de Chrome porque es la que corre hoy en el navegador, pero es exactamente el tipo de detalle que confirma que esto todavía es una propuesta en movimiento.

El ciclo de vida se maneja con AbortController y también a mano. Las tools se registran en un efecto y el signal las desregistra al desmontar. Sumé además una llamada explícita a unregisterTool en la limpieza, porque no todos los navegadores implementan igual la cancelación por señal. Sin limpieza, cada navegación interna de una aplicación de una sola página acumula herramientas fantasma.

Exponer tu contenido a los agentes puede arruinarte el rendimiento. Este es el hallazgo que me costó caro. La tool get_blog_post necesita el cuerpo completo de los artículos, y el componente que registra las tools se monta en el layout. Con un import estático, ese contenido entraba al bundle de todas las rutas, la home incluida, solo por si un agente llamaba a la herramienta. Lo resolví cargándolo con import dinámico dentro del handler: el peso viaja únicamente cuando la tool se ejecuta de verdad. Para los agentes no cambió nada.

Esa última lección es la que ordena todo el artículo. Preparar un sitio para agentes puede degradar la experiencia de las personas si se hace sin cuidado, y ahí no ganó nadie.

Hay dos decisiones más que valen. La primera es tener una sola fuente de verdad: la metadata de las tools vive en un archivo que alimenta a la vez la capa imperativa del navegador y el manifiesto de descubrimiento que el sitio publica en /.well-known/webmcp, con CORS abierto para que cualquier agente lo lea. Si la lista se define dos veces, se desincroniza en la primera semana. La segunda es que get_blog_post no devuelve HTML: serializa el artículo a markdown. Un agente que pide un artículo recibe texto limpio y citable, no una sopa de divs.

En milimetrix.com la arquitectura es distinta porque el problema es distinto. Ahí hay cinco tools, también todas de solo lectura, y los datos no salen del bundle sino de dos endpoints propios que devuelven JSON. La tool es una fachada delgada y la verdad vive en el servidor. Ese patrón resuelve el problema del JavaScript de raíz: la respuesta no depende de qué alcanzó a renderizar el cliente, y el mismo endpoint sirve después para un MCP server o para cualquier integración que venga.

Los dos sitios publican además un llms.txt. Son capas distintas y conviene no confundirlas: llms.txt es descubrimiento, dice cómo está organizado el sitio; WebMCP es ejecución, dice qué se puede hacer. Una no reemplaza a la otra.

UCP, ACP y Shopify: los protocolos que ya mueven dinero

Mientras WebMCP resuelve la capa de interfaz, tres protocolos de comercio resuelven la capa de transacción, y esos ya están operando. Google impulsa el Universal Commerce Protocol (UCP), un estándar abierto co-diseñado con Shopify, Etsy, Wayfair, Target y Walmart, que conecta las superficies de consumo (AI Mode en la Búsqueda y Gemini) con el backend del comercio. Se integra por API REST, por Model Context Protocol o por Agent2Agent, es compatible con el Agent Payments Protocol, y usa los feeds que el comercio ya tiene en Merchant Center. Google es explícito en un punto que a los retailers les importa: el comercio sigue siendo el merchant of record y se queda con los datos del cliente y con la post venta.

El Agentic Commerce Protocol (ACP) es la apuesta de OpenAI y Stripe, publicada con licencia Apache 2.0. Define los flujos programáticos entre compradores, agentes y negocios: el comercio expone endpoints de cara al agente, se comparten credenciales de pago de forma delegada, y el comercio decide si acepta o rechaza por agente o por transacción. El agente nunca se convierte en el merchant of record.

Shopify es el caso más útil de mirar porque ya lo tiene empaquetado. Su capa se llama Shopify Catalog, que la propia Shopify describe como la capa de datos estructurados que hace los productos legibles para agentes de IA, con taxonomía universal y verificación de precio e inventario en tiempo real. Encima corre Agentic Storefronts, un canal de venta del admin que sindica los productos a ChatGPT, Microsoft Copilot y AI Mode en la Búsqueda y Gemini, sin apps que instalar. Cada tienda tiene además su propio endpoint de Storefront MCP para búsqueda de productos, operaciones de carrito y preguntas de políticas. Y hay una pieza que casi nadie comenta: la app Knowledge Base, que permite ver con qué frecuencia los agentes consultan información de la tienda y editar las respuestas que la IA entrega sobre la marca.

Esa última app es la señal más clara de hacia dónde va esto. Shopify convirtió la pregunta de qué le contesta la IA sobre mi negocio en una pantalla de configuración con métricas.

Todo el lado de catálogos, feeds y schema de producto está desarrollado en la guía de comercio agéntico, y no lo repito acá.

Falta una cuarta capa, la de conocimiento. En junio de 2026 Google Cloud publicó el Open Knowledge Format (OKF), una especificación abierta para representar conocimiento como un directorio de archivos markdown con frontmatter YAML, enlazados entre sí como un grafo que un agente puede recorrer. Nació para contexto interno de agentes (esquemas de tablas, definiciones de métricas, runbooks), pero la convención de servirlo en una ruta pública y apuntarlo desde llms.txt ya está circulando.

Cómo se audita si un sitio está listo para agentes: Lighthouse y WebMCP Inspector

Desde Chrome M150, Lighthouse incluye una categoría de auditoría de navegación agéntica que revisa de forma determinista qué tan preparado está un sitio para agentes. No es una opinión ni un score de marketing: son auditorías de pasa o no pasa sobre tres frentes concretos.

El primero es accesibilidad, y verifica que cada elemento interactivo tenga un nombre programático leyendo el árbol de accesibilidad. El segundo es estabilidad, y mide Cumulative Layout Shift para prevenir clics errados de un agente que trabaja con capturas. El tercero es WebMCP, y comprueba si hay tools registradas y si sus esquemas son válidos.

Conviene calibrar la expectativa: Chrome declara que la categoría es informativa y todavía no está benchmarkeada, así que no hay un número objetivo que perseguir. Sirve para detectar qué está roto, no para presumir un puntaje. Chrome publicó además herramientas de DevTools que permiten simular los pasos exactos que daría un agente, y un conjunto de guías llamado Modern Web Guidance que incluye una skill de webmcp para delegar la implementación a un agente de código.

Para revisar sitios ajenos, o el propio desde fuera, existe una extensión de Chrome llamada WebMCP Inspector. Escanea la página y devuelve un puntaje sobre quince comprobaciones agrupadas en cuatro bloques: infraestructura (HTTPS, CORS), acceso para IA (llms.txt, robots.txt, meta robots), descubrimiento (/.well-known/webmcp, JSON-LD, canonical) y las dos capas de WebMCP, imperativa y declarativa. Es la forma más rápida de auditar la superficie agéntica de cualquier dominio, incluida la competencia.

Hay una regla que conviene aplicar con cualquier herramienta de esta generación: no persigas los checks verdes sin leer qué está midiendo cada uno.

El caso más claro hoy es el check de navigator.modelContext. Un rojo ahí parece decir que el sitio no tiene WebMCP imperativo, y casi siempre significa lo contrario: navigator.modelContext es la superficie que Chrome deprecó en la versión 150, y la implementación correcta usa document.modelContext. Corregir ese rojo implicaría escribir sobre una API deprecada para complacer a una extensión. Se deja en rojo y se sigue. Lo mismo con el check de window.ai, que apunta a la IA integrada del navegador y no a WebMCP.

Los checks que sí hay que atender son otros dos, y ambos tienen una forma correcta de resolverse que no es la obvia.

El llms.txt no se escribe a mano. Se genera desde las mismas constantes que alimentan el sitemap y el listado del blog, para que se actualice solo al publicar. Un llms.txt escrito a mano queda desactualizado en la primera publicación, y un índice que miente sobre lo que hay en el sitio es peor que no tenerlo.

Los atributos declarativos no van en el layout, van en la página donde está la acción. Un formulario de contacto anotado con toolname y tooldescription solo aparece en la ruta de contacto, así que un escaneo de la portada devuelve cero elementos declarativos aunque el sitio los tenga bien puestos. Ese cero no es un error: es la consecuencia de declarar la herramienta donde vive la acción, que es exactamente donde debe estar.

Qué hacer esta semana si tu sitio no está preparado para agentes de IA

El orden importa más que la lista, porque las tres primeras cosas cuestan poco y las últimas cuestan mucho. Esta es la secuencia que uso:

• Corre Lighthouse con la categoría de navegación agéntica y anota cuántos elementos interactivos no tienen nombre programático. Ese número es tu línea base.
• Arregla los botones falsos. Todo div con onclick que sea parte de un recorrido crítico pasa a button, o al menos recibe role y tabindex. Es la corrección de mejor relación costo beneficio de toda esta lista.
• Enlaza cada label a su input con el atributo for en los formularios que importan: contacto, búsqueda, carrito, filtros.
• Audita qué datos de decisión dependen de JavaScript. Precio, stock, plazos, disponibilidad. Todo lo que decide una acción tiene que venir en la primera respuesta del servidor.
• Estabiliza el layout en las plantillas donde el elemento de acción se mueve de lugar entre categorías o entre estados.
• Publica un llms.txt con la estructura real del sitio. Genéralo desde las mismas constantes que alimentan el sitemap: si lo escribes a mano, queda desactualizado en la primera publicación.
• Anota tus formularios con la API declarativa: toolname y tooldescription sobre el formulario, name en cada campo y toolparamdescription donde el propósito no sea obvio. Es la vía que no depende de JavaScript y la más barata de todas.
• Recién ahí, evalúa la API imperativa. Empieza por dos o tres tools de solo lectura sobre endpoints que ya tengas, con AbortController para la limpieza. No expongas nada que escriba hasta tener resuelta la confirmación humana.
• Escanea con WebMCP Inspector y con Lighthouse, y contrasta cada rojo con la documentación antes de tocar código.

Si tu sitio falla en los tres primeros puntos, implementar WebMCP no te va a salvar. Un agente que no puede identificar tus botones tampoco va a confiar en tus tools.

Preguntas frecuentes sobre la web agéntica y WebMCP

El punto de fondo

La pregunta ya no es si un agente puede leer tu sitio. Es si puede hacer algo con él. Durante veinte años optimizamos para que una máquina entendiera un documento, y el trabajo que viene es otro: declarar qué acciones existen, con qué esquema y bajo qué permisos.

Lo que más me llamó la atención implementando esto no fue la API, que es simple. Fue que la mitad del trabajo es accesibilidad web que debimos hacer hace años, y la otra mitad es una decisión de producto disfrazada de decisión técnica: qué le dejas hacer a un agente en nombre de tu cliente. Esa segunda mitad no la resuelve ningún estándar.

Esta guía es el satélite técnico del pilar sobre AEO y GEO, donde está el marco completo de visibilidad en IA.

En Milimetrix, como expertos en AEO, preparamos sitios para la web agéntica: accesibilidad para agentes, render de servidor de los datos que deciden, llms.txt y tools WebMCP sobre endpoints propios. Si quieres que un agente pueda operar tu sitio y no solo mirarlo, hablemos.