WebMCP en Chrome 149: webs que hablan con agentes de IA

Por qué los agentes actuales rompen tus webs cada vez que rediseñas

Cuando un agente de IA intenta reservar una mesa en un restaurante online hoy, opera como un interno muy paciente y un poco confundido: carga la página, lee el HTML en crudo, intenta identificar cuál de los cuarenta <div> es el selector de fecha, asume que el botón verde es "confirmar", hace clic y vuelve a leer toda la pantalla para ver si algo cambió. Mueve ese botón la semana que viene y el agente se rompe. Renombra una clase CSS y se rompe. Añade un banner de cookies encima y hace clic donde no debe.

Esa es, en esencia, la "automatización" que la mayoría de los agentes aplican hoy a la web: screen-scraping y esperanza. Es el equivalente a manejar un ordenador describiendo capturas de pantalla por teléfono. Y, según datos del sector citados por HackerNoon, WebMCP opera todavía en "near-zero real deployment" dentro del ecosistema de agentes, lo que hace especialmente relevante que founders y equipos de producto entiendan la propuesta antes de que se masifique.

Qué es WebMCP y por qué Google y Microsoft lo están co-editando

WebMCP es un estándar web en fase de borrador, desarrollado de forma conjunta por Google (Chrome) y Microsoft (Edge) dentro del W3C Web Machine Learning Community Group. En la práctica, ofrece a una página una pequeña API en JavaScript para registrar herramientas (tools) que un agente de IA puede descubrir y llamar, en lugar de tener que adivinar cómo está hecha la interfaz.

🤖 La IA no es solo para leer sobre ella

En la comunidad la aplicamos: automatización, agentes IA y herramientas reales para emprender, no solo para informarte.

👥 Aplicarla en la comunidad

El equipo de Chrome lo resume así en su documentación oficial: una vía para "construir y exponer herramientas estructuradas para agentes de IA", donde el sitio anota sus propias funciones para que los agentes "sepan exactamente cómo interactuar" con ellas. Para ser rigurosos, hoy es un Community Group draft, no un estándar W3C terminado ni está todavía en el standards track, lo que significa que el momento de aprenderlo y darle forma es precisamente ahora.

Tres piezas lo hacen encajar:

Descubrimiento. Una forma estándar de que la página diga "ofrezco estas herramientas" (p. ej. checkout, book_table), para que un agente las liste.
Esquemas. Cada herramienta declara sus entradas y salidas en JSON Schema, de modo que el agente sepa exactamente qué pasarle y haya mucho menos margen para alucinar o malinterpretar.
Estado. Una comprensión compartida de lo que hay en la página en ese momento, para que el agente sepa sobre qué puede actuar.

Chrome 149 y el origin trial: cómo se prueba hoy

El 9 de junio de 2026, Chrome anunció la apertura del origin trial de WebMCP en Chrome 149, según publicó Alexandra Klepper en el blog Chrome for Developers. Los origin trials son programas temporales que ofrecen acceso temprano a funciones experimentales de la plataforma: los desarrolladores pueden integrar la función en producción, con tráfico real, y el equipo de Chrome recoge datos de uso antes de decidir si se lanza de forma permanente o se retira.

Para participar, según la guía técnica publicada en developer.chrome.com y replicada por el sitio de referencia webmcp.ro, hay que:

Registrarse en developer.chrome.com/origintrials con una cuenta de Google.
Solicitar un token para el origen exacto del sitio (incluido protocolo, dominio y puerto).
Entregar el token a la página mediante una <meta> en el <head> o vía header HTTP.
Invalidar cachés tras cualquier cambio, porque un token caducado o mal cacheado simplemente desactiva la API sin mostrar error visible.

La duración del trial se extiende, según HackerNoon, hasta Chrome 156, con co-edición activa de Google y Microsoft. Es decir: hay una ventana real de varios meses para experimentar, reportar bugs y empujar el estándar en una dirección útil para producto.

Cómo fluye una llamada, del agente a tu página

Nada exótico ocurre: la página registra herramientas, el agente las lista, elige una, la llama con argumentos estructurados, y tu propio JavaScript hace el trabajo dentro de la página. El detalle importante es que la llamada ocurre en la pestaña que ya tienes abierta, con la sesión en la que ya estás autenticado. No es un bot externo logueándose con credenciales robadas: es una función invocada en tu pestaña real, usando tu sesión real.

Un detalle de implementación útil si decides probarlo: el punto de entrada de la API se movió recientemente desde navigator.modelContext (nombre original, ya deprecated) a document.modelContext, porque las herramientas pertenecen al documento, no al navegador entero. Un shim mínimo (const mc = document.modelContext || navigator.modelContext) conecta ambas formas mientras el cambio se termina de desplegar.

MCP, el protocolo que WebMCP extiende al navegador

Para entender por qué WebMCP importa, conviene recordar qué es el Model Context Protocol (MCP). MCP estandariza la forma en que un modelo accede a herramientas y datos externos; en lugar de construir N×M integraciones a medida entre N clientes y M servidores, colapsa el problema a N+M.

MCP se ha convertido, en poco más de un año, en una de las piezas de infraestructura más relevantes de la economía agentic. Según HackerNoon, en diciembre de 2025 Anthropic donó MCP a la Agentic AI Foundation del Linux Foundation, donde reportó 97 millones de descargas mensuales del SDK y más de 10.000 servidores públicos activos. El 28 de julio de 2026 se publicó la versión 2.0 del protocolo, una reescritura profunda que eliminó handshake y sesiones para pasarse a HTTP sin estado, lo que permite escalar con balanceadores estándar. Esa misma semana, Cloudflare anunció el 6 de agosto la retirada de su primitivo McpAgent porque la nueva especificación lo hacía innecesario, una señal poco habitual: los proveedores no retiran una primitiva diferenciada a menos que el estándar se haya simplificado de verdad.

WebMCP lleva esa misma idea al navegador: la página pasa a ser un servidor que ofrece herramientas, en la sesión del usuario. Cuando madure, un agente podrá combinar ambos planos sin costuras: llamar a add_to_cart vía WebMCP en la página, y a un servidor MCP remoto para consultar inventario.

El caso real: automatizar hasta el último paso, sin saltar el botón

Un ejemplo publicado por Sreenath Menon para ilustrar el modelo es Career Copilot, un portal de empleo agentic: el usuario sube su CV, el agente lee ofertas reales en portales de empresas, calcula el fit real, identifica skill gaps y prepara un lote de aplicaciones listas para aprobar con un clic. Lo interesante no es una sola llamada a una herramienta, sino el encadenamiento: una fase de lectura, y una fase de acción que se detiene ante un humano antes del clic final.

El aprendizaje de ingeniería que el autor destaca es honesto: todo hasta el botón de "enviar" es fácil y útil de automatizar; el último tramo (los sistemas de Workday, Greenhouse y otros, cerrados detrás de logins y detección de bots) es deliberadamente no abierto. La solución correcta no es falsear el último tramo, sino automatizar todo lo anterior y mantener un humano en el envío. Hasta que esos portales expongan una herramienta submit_application declarada (precisamente lo que WebMCP permitiría), ese diseño no es un compromiso: un agente que aplica a ofertas en tu nombre sin confirmación es un pasivo; uno que hace todo el trabajo y pregunta antes de actuar, una súper-habilidad.

El modelo de confianza: lo que WebMCP ya intenta resolver

La preocupación obvia: si una página puede entregar herramientas a un agente, ¿puede una página maliciosa engañarlo para que haga algo grave? El diseño toma esto en serio y articula cuatro guardarraíles:

Visibilidad en la pestaña. No hay ejecución headless ni en segundo plano: las acciones ocurren donde el usuario puede verlas.
Aislamiento por origen. Las herramientas solo se registran en documentos origin-isolated, con una Permissions Policy que por defecto vale self. Un iframe cross-origin no puede registrar herramientas en silencio.
Confirmación humana para acciones sensibles. Para compras u operaciones delicadas, una herramienta puede exigir un diálogo explícito de confirmación antes de proceder.
Anotaciones de confianza. Las herramientas llevan hints como readOnlyHint y untrustedContentHint, para que el agente trate con sospecha adecuada el contenido de terceros, clave frente al prompt injection.

No hace al estándar mágicamente seguro: la especificación es joven y el modelo de seguridad sigue trabajándose. Pero la forma es la correcta: visible, mismo origen, consentimiento explícito y honesto sobre datos no confiables.

Qué significa esto para tu startup

Para un founder hispanohablante, WebMCP no es una curiosidad académica: cambia qué productos pueden operar los agentes y, por tanto, qué productos sobreviven al próximo rediseño.

Tres acciones concretas para esta semana:

Audita qué acciones de tu producto un agente ya quisiera llamar. Apunta las 3-5 funciones más valiosas (checkout, búsqueda, reserva, apply, exportar). Esas serán candidatas naturales a envoltorios registerTool cuando decidas participar en el trial.
Reserva una semana para hacer un prototipo con el origin trial de Chrome 149. Elige una sola acción (la más repetida por usuarios reales), impleméntala como tool y pruébala con un agente en navegador. La curva real, según la experiencia publicada, es de unas horas para una primera versión funcional.
Diseña con la frontera humano/agente desde el inicio. Separa lo que el agente puede leer de lo que puede actuar, y pon el gate humano solo donde de verdad importa. Esta disciplina, además de más segura, encaja con la tendencia del sector: la auditoría de la que se hizo eco HackerNoon halló que el 88% de los servidores MCP abiertos requieren credenciales y solo el 8,5% usa OAuth, es decir, el talón de Aquiles actual del stack agentic es el consentimiento.

Una señal macro a observar. El 20 de agosto de 2026, Google transfirió su protocolo A2A a la Agentic AI Foundation, según Forkast, reuniendo bajo un mismo paraguas中立 los dos estándares abiertos dominantes de la economía agentic: MCP (integración vertical agente-herramientas) y A2A (comunicación horizontal entre agentes). Cuando WebMCP termine de aterrizar, se sumará a esa pila compartida. Para founders, eso significa que invertir en interfaces agent-friendly deja de ser un experimento y empieza a ser infraestructura durable.

Conclusión

WebMCP encaja en una frase: en vez de obligar al agente a adivinar qué hace tu web mirando botones, le entregas un catálogo limpio de herramientas declaradas. Ese único cambio (declarar en lugar de scrapear) hace las interacciones confiables, mantiene al sitio en control, corre dentro de la sesión real del usuario y sobrevive al próximo rediseño.

Es pronto, es Chrome-first y el estándar cambiará. Pero la barrera para probarlo es casi nula: activa chrome://flags/#enable-webmcp-testing, añade una llamada registerTool envolviendo una función que tu sitio ya tiene, y mira cómo un agente la llama. Entenderás mejor que la mayoría lo que significa una web operable por agentes.