WebMCP es una API del navegador propuesta que descubre, describe y ejecuta herramientas estructuradas para un agente de IA en nombre de una persona usuaria. El sitio web declara qué hace cada acción y qué entradas acepta; el agente llama a esa herramienta en lugar de adivinar sobre qué botón o campo hacer clic. Eso puede hacer más rápido y fiable un formulario, un flujo de reserva o una tarea de diagnóstico, pero no es un reemplazo universal de la automatización del navegador. la documentación de WebMCP de Chrome
La decisión práctica es de arquitectura. WebMCP es cooperación del lado del servidor: quien es dueño del sitio publica un contrato dirigido a los agentes. La automatización del navegador es observación del lado del cliente: un agente opera la interfaz que ya existe, incluida una sesión con sesión iniciada y autorizada. Usa lo primero cuando controlas el sitio y puedes definir herramientas seguras; usa lo segundo cuando necesitas trabajar con la web de hoy. las guías de herramientas seguras
¿Qué es WebMCP?
WebMCP (Web Model Context Protocol) es una propuesta de API orientada al navegador, del equipo de Chrome y de la comunidad WebMCP. La documentación de Chrome lo describe como una forma de construir y exponer herramientas estructuradas para los agentes, conservando la aplicación web visible y el control de la persona usuaria. Un sitio puede publicar una herramienta de búsqueda, de pago, de selección de fechas, de soporte o de diagnóstico como mejora progresiva; una persona puede seguir usando la misma página cuando no hay ningún agente delante. el anuncio del origin trial de Chrome
¿Cómo funciona WebMCP?
Una página con WebMCP registra herramientas en el navegador. Cada herramienta tiene un nombre, una descripción, un esquema de entrada y una implementación que se ejecuta en la página. La API imperativa usa JavaScript para acciones personalizadas; la API declarativa anota formularios HTML normales. La documentación de Chrome destaca tres piezas que le importan a un agente: el descubrimiento, los esquemas JSON de entradas y salidas, y el estado que describe qué puede hacer la página actual.
El resultado puede ser un camino de acción más corto. En lugar de leer un DOM enorme, deducir que un botón significa submit_application y confiar en que un selector sobreviva a un rediseño, un agente puede llamar a la herramienta con nombre propio usando campos descritos por el esquema. La acción se sigue ejecutando a la vista dentro del sitio web, así que la página puede mostrar el progreso y pedir confirmación antes de una compra o de otra operación que cambie el estado.
Qué vimos en nuestra prueba de WebMCP, paso a paso
El 11 de septiembre de 2026 hicimos una prueba guiada sobre la demo oficial Hotel Chain de Chrome Labs, con Google Chrome 152.0.7977.76 en macOS y WebMCP Model Context Tool Inspector 1.9.15. El operador usó datos sintéticos de huésped, sin clave de API de Gemini y sin credenciales reales de hotel, pago o cuenta. Fue un recorrido de comportamiento, no un benchmark de velocidad ni de fiabilidad.
- El Inspector descubrió las herramientas y los esquemas de la página. Llamamos a search_location para París, el 18 de septiembre, tres noches y una persona adulta; la página mostró dos alojamientos.
- Llamamos a filter_search_results con breakfast. El recuento visible de resultados pasó de dos a uno, y quedó Montmartre Suites.
- Abrimos ese hotel, iniciamos el flujo de reserva y facilitamos la identidad sintética Alex Chen. La herramienta preparó el formulario, pero no finalizó la reserva.
- La página se detuvo en Confirm Reservation. Solo después de que la persona operadora hiciera clic en ese control apareció Reservation Confirmed.
También importó una limitación de las herramientas: la acción Copy trace del Inspector devolvió un array JSON vacío después de nuestro flujo manual de Execute Tool. Por eso usamos capturas de pantalla y un registro estructurado de pasos como evidencia de esta ejecución, y no generalizamos ese resultado del trace a otros modos del Inspector.
Qué aporta WebMCP frente a la automatización del navegador
WebMCP y la automatización del navegador resuelven fallos distintos. WebMCP elimina la ambigüedad cuando el sitio publica un buen contrato. La automatización tradicional, ya sea Playwright, Selenium, browser-use o un agente que conduce un navegador real, se ocupa de los sitios que no publican ningún contrato leyendo la página renderizada e interactuando con ella. Por eso WebMCP complementa la automatización: un cliente puede llamar a una herramienta de página cuando está disponible y recurrir a la navegación normal cuando no lo está.
La distinción se audita mejor como frontera de capacidades. Lee tanto la columna positiva como la negativa antes de elegir una ruta.
| Enfoque | Qué puede hacer | Qué no puede hacer |
|---|---|---|
| WebMCP | Llamar a herramientas con nombre propio y descritas por esquema que expone una página | Llegar a páginas que no registran herramientas ni importar un inicio de sesión de otro navegador |
| Automatización basada en el DOM | Operar casi cualquier página renderizada con selectores, capturas de pantalla o el estado de accesibilidad | Conocer la acción prevista del sitio sin interpretar la interfaz |
| Reutilización de una sesión de navegador real | Usar un estado de navegador con sesión iniciada, autorizado y aprovisionado de forma explícita | Garantizar el acceso, saltarse el CAPTCHA o imponerse a las políticas del sitio |
Un despliegue práctico empieza con una herramienta de solo lectura, un navegador compatible y un paso de confirmación visible. Amplía solo cuando la ruta de respaldo funcione.
El límite de sesión es igual de importante. WebMCP se ejecuta dentro de la página que visitó el cliente; no transfiere las cookies de Chrome de una persona a una nueva sesión en la nube. En un sitio sin WebMCP, ego (lite) es el navegador Chromium local para agentes de IA: tú proporcionas explícitamente el estado del navegador y un agente compatible opera el sitio mediante ego-browser en un Space dedicado y visible. El Space mantiene las pestañas y el control de la tarea separados de tu trabajo activo, pero no es una máquina virtual remota ni una frontera de aislamiento entre clientes. Esta ruta cambia el modelo de ejecución del navegador, no el contrato de interfaz del sitio. las notas de la versión 2.0 de OpenClaw
Usa esta tabla de evaluación para que la decisión sea explícita en lugar de tratar WebMCP como una mejora universal.
| Pregunta de evaluación | Elige WebMCP cuando... | Elige la automatización del navegador cuando... |
|---|---|---|
| ¿Controlas el sitio? | Sí; puedes publicar y asegurar herramientas de página | No; necesitas trabajar con un sitio de terceros |
| ¿La tarea necesita un inicio de sesión ya existente? | Basta con la sesión autenticada de la propia página | El agente debe reutilizar una sesión local aprovisionada aparte |
| ¿Cuál es el objetivo del despliegue? | Un contrato estable y tipado para los clientes compatibles | Un flujo inmediato entre páginas y sin trabajo de adopción |
¿Cuándo tiene sentido usar WebMCP?
Elige WebMCP cuando la aplicación es tuya, puedes definir fronteras de tarea estables y quieres que los agentes completen trabajo estructurado como formularios de soporte, búsqueda de viajes, pagos o diagnóstico interno. Resulta especialmente útil en interfaces complejas donde una persona conoce la acción prevista pero un agente necesitaría muchos clics interpretados. Mantén la herramienta pequeña, tipada y observable.
Elige la automatización con navegador real cuando no controlas el sitio, necesitas un inicio de sesión autorizado que ya existe, tienes que trabajar en muchos sitios distintos o necesitas un flujo hoy y no después de que el sitio adopte nada. Para scripts de CI comprometidos, la automatización determinista sigue siendo lo adecuado; para trabajo interactivo con sesión iniciada, un navegador local visible le da al agente la misma cuenta y el mismo estado de página que una persona puede revisar.
Los límites de seguridad de WebMCP
WebMCP no concede autoridad por sí solo. Chrome controla las API con aislamiento de origen y la política de permisos tools; los iframes de origen cruzado están desactivados por defecto. Un sitio solo puede exponer herramientas a los orígenes en los que confía, y la guía de seguridad de Chrome recomienda readOnlyHint para herramientas que no mutan nada y untrustedContentHint cuando la salida contiene texto externo o generado por usuarios.
La inyección de prompt sigue siendo posible porque un agente procesa a la vez las instrucciones y el contenido web. Mantén las descripciones y las salidas concisas, valida las entradas en el servidor, exige confirmación de la persona usuaria para acciones con consecuencias y expón el conjunto más pequeño posible de orígenes y herramientas. WebMCP es una interfaz más clara, no una razón para saltarse la autenticación, la autorización, los registros de auditoría ni la revisión humana.
Retos y limitaciones de WebMCP
La principal limitación de WebMCP es la adopción: un cliente debe visitar una página compatible y el navegador debe implementar la API experimental. Chrome también señala que los escenarios headless no son el objetivo de diseño principal, que las aplicaciones complejas pueden necesitar una reestructuración de estado y que la propuesta sigue cambiando.
Eso crea una pila mixta durante el tiempo que se ve venir. Un sitio puede exponer una herramienta de pago excelente y dejar la configuración de la cuenta como controles DOM normales; un navegador puede admitir WebMCP en pruebas pero no en tu parque de producción. Mantén un respaldo de automatización normal y mide los errores de las herramientas, las tasas de confirmación y los traspasos a una persona a lo largo de ejecuciones repetidas.
Cómo probar WebMCP hoy
Para experimentos locales, activa chrome://flags/#enable-webmcp-testing en Chrome y reinicia. Para pruebas en vivo, la documentación de Chrome remite a los desarrolladores al origin trial de Chrome 149. Usa las demos oficiales y la extensión Model Context Tool Inspector para ver las herramientas registradas, llamarlas a mano y probar tanto entradas válidas como inválidas. Como la propuesta sigue en discusión activa, fija la versión del navegador y cuenta con que la API cambie. el WebMCP Challenge de OpenAI
Si usas agentes y no eres dueño de un sitio, no necesitas esperar a que WebMCP se adopte. Ejecuta /ego-browser en tu agente de programación compatible, describe la tarea acotada y mantén explícitos la sesión del navegador y los permisos. Los dos enfoques convivirán: WebMCP hace más fáciles de operar los sitios que cooperan; la automatización con navegador real llega al resto.
Preguntas frecuentes
¿WebMCP es lo mismo que un servidor MCP?
No. Un servidor MCP tradicional es un proceso o servicio externo que expone herramientas a un cliente. WebMCP expone herramientas desde la propia página web a un agente en el navegador, con fronteras de origen del navegador y de la política de permisos.
¿Puede WebMCP automatizar un sitio que no tiene soporte de WebMCP?
No. El cliente debe visitar una página que registre herramientas. Usa automatización del navegador normal para un sitio que no ha adoptado WebMCP y detente para pedir intervención humana cuando la autenticación o un desafío lo exijan.
¿Quién tiene que implementar WebMCP?
Quien es dueño del sitio web implementa las herramientas de WebMCP; un cliente de agente y un navegador deben saber consumirlas. Una persona que visita el sitio no puede añadir herramientas a un sitio ajeno.
¿Cuáles son los principales beneficios de WebMCP?
WebMCP da a los agentes acciones con nombre propio, entradas descritas por esquema y estado de página, lo que reduce las conjeturas sobre selectores y los clics interpretados en sitios que cooperan. La aplicación sigue teniendo que validar cada carga útil.
¿Cuáles son las principales limitaciones de WebMCP?
WebMCP necesita que las páginas lo adopten y que los navegadores lo soporten, sigue siendo experimental en Chrome y no resuelve la paridad headless, la política de autenticación ni la inyección de prompt.
¿Pueden ejecutarse las herramientas de WebMCP sin una persona?
Algunas herramientas de bajo riesgo pueden ejecutarse solas, pero las acciones sensibles deberían pedir interacción y confirmación de la persona usuaria. El diseño de Chrome apunta a flujos locales en el navegador con una persona dentro del circuito.
¿WebMCP expone herramientas a todos los iframes?
No. El aislamiento de origen y la política de permisos tools controlan el acceso al registro; los iframes de origen cruzado necesitan permiso explícito y una exposición de confianza.
¿Cuánto tiempo se mantendrá estable la API de WebMCP?
Todavía no hay ninguna garantía de estabilidad. Chrome etiqueta WebMCP como estándar propuesto y en discusión activa, así que fija versiones y vigila el explainer y las notas del origin trial.
¿Puedo usar WebMCP con una cuenta con sesión iniciada?
Una página puede exponer herramientas dentro de su propia sesión autenticada, pero WebMCP no transfiere cookies a otro navegador. Mantén la autorización y la confirmación dentro del modelo de seguridad del sitio.
¿Qué debería usar mientras un sitio no tiene WebMCP?
Usa automatización del navegador normal. Para una sesión local autorizada, ego (lite) permite que un agente compatible opere un navegador real aprovisionado aparte mediante /ego-browser.
¿Dónde puedo leer la guía de implementación?
Empieza por la documentación de WebMCP de Chrome, las guías de herramientas seguras, la página del origin trial y el explainer de WebMCP en GitHub; los enlaces están en las notas de fuentes que hay más abajo.