WebMCP y agentes de IA: qué significa para tu sitio web

WebMCP es una propuesta para que un sitio web le diga a un agente de IA qué puede hacer en él —buscar un producto, reservar una hora, abrir un ticket— y cómo hacerlo, en vez de dejar que el agente adivine haciendo clic en la pantalla como un humano apurado. Está en borrador en el W3C y Chrome la tiene en vista previa. No es un estándar todavía, y nadie debería venderte "optimización para WebMCP" hoy. Pero conviene entenderla, porque apunta a la misma pregunta que ya está cambiando el SEO: cuando quien visita tu sitio no es una persona sino un programa que actúa por ella, ¿qué le estás dando?

Todo lo que sigue sale de dos fuentes primarias: el borrador de la especificación del grupo Web Machine Learning del W3C (versión del 30 de septiembre de 2026) y el anuncio de Chrome del 10 de febrero de 2026. Donde no hay información verificada, lo digo.

Qué problema intenta resolver

Los agentes de IA que navegan por ti —el modo agente de ChatGPT, los agentes de Gemini, Claude usando un navegador— hoy trabajan "mirando" la página: leen el HTML o una captura, deciden dónde hacer clic, escriben en formularios y vuelven a mirar. Funciona, pero es frágil y lento: un botón que cambia de lugar rompe el flujo, una ventana emergente lo confunde, y cada paso cuesta tiempo y tokens.

La alternativa del lado del servidor ya existe: el Model Context Protocol (MCP) permite que un servicio exponga herramientas a un modelo de lenguaje. El problema es que exige construir y mantener un servidor aparte, con su propia autenticación, para algo que tu sitio ya hace en el navegador.

WebMCP toma esa idea y la lleva al navegador. La propia especificación lo describe así: las páginas que usan WebMCP se convierten en servidores MCP que corren en el navegador. El sitio registra sus funciones con JavaScript, y el agente, a través del navegador, las descubre y las ejecuta.

Cómo funciona, según el borrador

La especificación define un objeto modelContext en el documento con tres operaciones básicas:

• registerTool() registra una herramienta: un nombre, un título legible, una descripción en lenguaje natural, un esquema de los parámetros que recibe y la función JavaScript que la ejecuta.
• getTools() devuelve las herramientas disponibles en la página.
• executeTool() ejecuta una de ellas con los parámetros indicados.

Una "herramienta" es, entonces, una función de tu sitio descrita de forma que un modelo de lenguaje pueda entender para qué sirve y qué necesita. En una tienda, "buscar producto" con parámetros de texto, talla y rango de precio. En una clínica, "consultar horas disponibles" con especialidad y fecha. El agente no tiene que encontrar el buscador ni interpretar el calendario: llama a la función.

El anuncio de Chrome habla de dos caminos: uno declarativo, para acciones estándar definidas directamente en formularios HTML, y uno imperativo, con JavaScript, para interacciones más complejas. Ojo con esto: en la versión actual del borrador, la parte declarativa está marcada como pendiente. Lo que existe hoy es la API imperativa.

Hay además una consideración de seguridad que me parece la parte más seria del documento. El acceso a las herramientas está controlado por una política de permisos (tools), que por defecto solo permite al propio origen del sitio exponerlas. La especificación menciona explícitamente el riesgo de inyección de instrucciones y de exposición de herramientas entre orígenes distintos. Es decir: los autores saben que abrirle funciones a un agente es abrir una puerta, y están diseñando la cerradura antes que la puerta.

En qué estado está, sin adornos

• Es un Draft Community Group Report del W3C. En lenguaje llano: un borrador de un grupo comunitario, no una recomendación ni un estándar. Puede cambiar de forma importante.
• Chrome lo ofrece en un programa de vista previa temprana desde febrero de 2026, con documentación y demos para quienes se inscriben.
• Sobre otros navegadores no tengo información verificada de primera mano, y por eso no voy a afirmar nada. Si lees que "todos los navegadores lo van a soportar", pide la fuente.

Con ese cuadro, la conclusión práctica es simple: WebMCP no es algo que debas implementar hoy en un sitio de producción salvo que estés experimentando a propósito. Sí es algo que conviene seguir, sobre todo si tu negocio depende de transacciones que un agente podría hacer por el usuario: reservas, compras, cotizaciones, soporte.

Lo que sí importa hoy: el SEO es indivisible, también para los agentes

Esta es mi lectura, y es la parte que no encontrarás en la documentación. WebMCP es un síntoma de algo más grande: los visitantes de tu sitio ya no son solo personas con un navegador. Son rastreadores de Google, modelos de lenguaje que leen tu contenido para responder preguntas y, cada vez más, agentes que ejecutan tareas. Y a todos ellos les sirve lo mismo que le sirve a Google desde hace veinte años.

Lo que un agente necesita para operar bien en tu sitio hoy, sin WebMCP:

• HTML semántico. Formularios con etiquetas de verdad, botones que son botones, enlaces que son enlaces. Un agente que mira la página entiende mucho mejor un <button> con texto claro que un <div> con un ícono.
• Contenido en el HTML, no solo después del JavaScript. Si la información aparece solo cuando se ejecuta un script del lado del cliente, cualquier programa que lea la página tiene que renderizarla primero. Google lo hace, con retraso; muchos agentes y modelos, no.
• Datos estructurados que digan la verdad. Un producto con precio, disponibilidad y variantes declaradas en schema.org es legible por cualquier máquina. Es la versión disponible hoy de "exponer herramientas": no exponer funciones, pero sí exponer hechos.
• URLs estables y una arquitectura clara. Un agente que llega a una categoría y entiende cómo se llega al producto es un agente que termina la tarea.
• Nada que dependa de engañar al visitante. Las ventanas emergentes que tapan el contenido, los botones falsos y los textos ocultos confunden a las personas y hacen fracasar a los agentes.

Fíjate en que esa lista es la misma que te daría para posicionar en Google. Por eso insisto en que el SEO es indivisible: lo técnico, el contenido y la estructura no son capas separadas, y lo que ordena un sitio para un buscador lo ordena para un modelo de lenguaje y para un agente. Lo explico más en la guía sobre posicionamiento en IA.

Qué haría yo si tengo un sitio transaccional

1. Hoy: auditar el sitio con los ojos de una máquina. Contenido en el HTML inicial, formularios accesibles, datos estructurados completos y correctos, sin contenido crítico escondido tras interacciones. Es trabajo de SEO técnico de siempre y rinde ahora, con o sin agentes.
2. Este trimestre: identificar las dos o tres acciones que un agente querría hacer en tu sitio por un usuario (buscar, cotizar, reservar) y verificar que hoy se pueden completar sin trucos, con teclado y sin JavaScript sorpresa. Si una persona con lector de pantalla puede hacerlo, un agente también.
3. Cuando WebMCP salga del borrador: evaluar exponer esas mismas acciones como herramientas. La ventaja de haber hecho los pasos 1 y 2 es que las funciones ya estarán definidas y probadas; solo faltará registrarlas.

Lo que no haría es contratar hoy un "servicio de preparación para WebMCP". No hay nada que preparar que no sea SEO técnico bien hecho, y eso se llama por su nombre.

Preguntas frecuentes

¿WebMCP reemplaza al MCP?

No. MCP conecta modelos con servicios del lado del servidor; WebMCP lleva la misma idea al navegador, para funciones que ya existen en la página. Son complementarios, y la propia especificación define las páginas con WebMCP como servidores MCP que corren en el navegador.

¿Esto afecta mi posicionamiento en Google?

Hoy, no. WebMCP no es una señal de posicionamiento ni Google ha dicho nada en ese sentido. Lo que sí afecta tu posicionamiento es todo lo que hace a un sitio legible para máquinas, y eso es anterior e independiente de WebMCP.

¿Dónde sigo las novedades?

En el repositorio y la especificación del grupo Web Machine Learning del W3C, y en el blog de desarrolladores de Chrome. Desconfía de cualquier resumen que no enlace a esas dos fuentes.