Cuando un agente de IA visita un sitio web, es esencialmente un turista que no habla el idioma local. Ya sea que esté construido sobre LangChain, Claude Code o el cada vez más popular marco OpenClaw, el agente se reduce a adivinar qué botones presionar: raspar HTML sin procesar, disparar capturas de pantalla en modelos multimodales y quemar miles de tokens solo para descubrir dónde está una barra de búsqueda.
Esa era puede estar terminando. A principios de esta semana, el equipo de Google Chrome lanzó WebMCP – Protocolo de contexto de modelo web: como vista previa en Chrome 146 Canary. WebMCP, desarrollado conjuntamente por ingenieros de Google y Microsoft e incubado a través del W3C Grupo comunitario de aprendizaje automático webes un estándar web propuesto que permite que cualquier sitio web exponga herramientas estructuradas y llamables directamente a agentes de IA a través de una nueva API del navegador: navigator.modelContext.
Las implicaciones para la TI empresarial son significativas. En lugar de crear y mantener servidores MCP back-end separados en Python o Node.js para conectar sus aplicaciones web a plataformas de IA, los equipos de desarrollo ahora pueden empaquetar su lógica JavaScript del lado del cliente existente en herramientas legibles por los agentes, sin necesidad de volver a diseñar una sola página.
Los agentes de IA son turistas caros y frágiles en la Web
Cualquiera que los haya implementado a escala comprende bien los problemas de costo y confiabilidad de los enfoques actuales para la interacción entre agentes web (agentes de navegador). Los dos métodos dominantes (captura de pantalla visual y análisis DOM) adolecen de ineficiencias fundamentales que impactan directamente en los presupuestos empresariales.
Con enfoques basados en capturas de pantalla, los agentes pasan imágenes a modelos multimodales (como Claude y Gemini) y esperan que el modelo pueda identificar no solo lo que hay en la pantalla, sino también dónde se encuentran los botones, campos de formulario y elementos interactivos. Cada imagen consume miles de tokens y puede tener una latencia prolongada. Con los enfoques basados en DOM, los agentes ingieren HTML y JavaScript sin procesar, un lenguaje extranjero lleno de diversas etiquetas, reglas CSS y marcado estructural que es irrelevante para la tarea en cuestión, pero que aún consume espacio de ventana de contexto y costo de inferencia.
En ambos casos, el agente está traduciendo entre para qué fue diseñado el sitio (ojos humanos) y lo que necesita el modelo (datos estructurados sobre las acciones disponibles). Una búsqueda de un solo producto que un ser humano completa en segundos puede requerir docenas de interacciones secuenciales de agentes (hacer clic en filtros, desplazarse por páginas, analizar resultados), cada una de las cuales es una llamada de inferencia que agrega latencia y costo.
Cómo funciona WebMCP: dos API, un estándar
WebMCP propone dos API complementarias que sirven como puente entre los sitios web y los agentes de IA.
EL API declarativa maneja acciones estándar que se pueden definir directamente en formularios HTML existentes. Para organizaciones con formularios bien estructurados que ya están en producción, este camino requiere un trabajo adicional mínimo; Al agregar nombres y descripciones de herramientas al marcado de formularios existentes, los desarrolladores pueden hacer que estos formularios sean accesibles para los agentes. Si sus formularios HTML ya están limpios y bien estructurados, probablemente haya recorrido el 80% del camino.
EL API imperativa maneja interacciones más complejas y dinámicas que requieren la ejecución de JavaScript. Aquí es donde los desarrolladores definen esquemas de herramientas más completos, conceptualmente similares a las definiciones de herramientas enviadas a los puntos finales de OpenAI o Anthropic API, pero que se ejecutan completamente en el lado del cliente en el navegador. A través de RegisterTool(), un sitio web puede exponer funciones como searchProducts (consulta, filtros) u orderPrints (copias, tamaño de página) con esquemas de parámetros completos y descripciones en lenguaje natural.
La idea clave es que una sola llamada a una herramienta a través de WebMCP puede reemplazar lo que podrían haber sido docenas de interacciones de uso del navegador. Un sitio de comercio electrónico que registra una herramienta searchProducts permite al agente realizar una llamada a una función estructurada y recibir resultados JSON estructurados, en lugar de que el agente haga clic en los menús desplegables de filtros, se desplace por los resultados paginados y capture imágenes de cada página.
El caso empresarial: coste, fiabilidad y el fin de la chatarra frágil
Para los tomadores de decisiones de TI que evalúan las implementaciones de IA de agentes, WebMCP aborda tres puntos débiles persistentes simultáneamente.
Reducción de costos es el beneficio cuantificable más inmediatamente. Al reemplazar secuencias de capturas de pantalla, llamadas de inferencia multimodal y análisis DOM iterativo con llamadas de herramientas estructuradas únicas, las organizaciones pueden esperar reducciones significativas en el consumo de tokens.
Fiabilidad Mejora porque los agentes ya no tienen que adivinar la estructura de la página. Cuando un sitio web publica explícitamente un contrato de herramienta (“aquí están las funciones que admito, aquí están sus parámetros, esto es lo que devuelven”), el agente opera con certeza en lugar de inferencia. Las interacciones fallidas debido a cambios en la interfaz de usuario, carga dinámica de contenido o identificación de elementos ambiguos se eliminan en gran medida para cualquier interacción cubierta por una herramienta registrada.
Velocidad de desarrollo se acelera porque los equipos web pueden aprovechar su JavaScript front-end existente en lugar de construir una infraestructura back-end separada. La especificación enfatiza que cualquier tarea que un usuario pueda realizar a través de la interfaz de usuario de una página se puede convertir en una herramienta, reutilizando gran parte del código JavaScript existente de la página. Los equipos no necesitan aprender nuevos marcos de servidores ni mantener superficies API separadas para los consumidores de agentes.
Humano en el circuito por diseño, no una ocurrencia tardía
Una decisión arquitectónica crítica separa a WebMCP del paradigma de agente totalmente autónomo que ha dominado los titulares recientes. El patrón está diseñado explícitamente en torno a flujos de trabajo humanos cooperativos, no a una automatización no supervisada.
Según Khushal Sagar, ingeniero de software de Chrome, la especificación WebMCP identifica tres pilares que respaldan esta filosofía.
Contexto: Todos los agentes de datos deben comprender lo que está haciendo el usuario, incluido el contenido que a menudo no es visible en la pantalla.
Capacidades: Acciones que el agente puede realizar en nombre del usuario, desde responder preguntas hasta completar formularios.
Coordinación: Controla la transferencia entre usuario y agente cuando el agente encuentra situaciones que no puede resolver de forma autónoma.
Los autores de la especificación en Google y Microsoft ilustran esto con un escenario de compras: una usuaria llamada Maya le pide a su asistente de inteligencia artificial que la ayude a encontrar un vestido ecológico para una boda. El agente sugiere proveedores, abre un navegador a un sitio web de vestidos y descubre que la página expone herramientas WebMCP como getDresses() y showDresses(). Cuando los criterios de Maya van más allá de los filtros básicos del sitio, el agente llama a estas herramientas para obtener datos del producto, usa su propio razonamiento para filtrar por “atuendo de cóctel apropiado” y luego llama a showDresses() para actualizar la página solo con los resultados relevantes. Es un ciclo fluido de gusto humano y capacidad de los agentes, exactamente el tipo de navegación colaborativa para la que WebMCP fue diseñado.
Este no es un patrón de navegación sin cabeza. EL La especificación establece explícitamente que los escenarios sin cabeza y totalmente autónomos no son objetivos. Para estos casos de uso, los autores señalan protocolos existentes, como el protocolo Agente a Agente (A2A) de Google. WebMCP trata sobre el navegador, donde el usuario está presente, observando y colaborando.
No es un sustituto de MCP, sino un complemento.
WebMCP no reemplaza el protocolo de contexto modelo de Anthropic, a pesar de compartir un linaje conceptual y parte de su nombre. No sigue la especificación JSON-RPC que utiliza MCP para la comunicación cliente-servidor. Mientras que MCP opera como un protocolo backend que conecta plataformas de inteligencia artificial con proveedores de servicios a través de servidores alojados, WebMCP opera completamente en el lado del cliente dentro del navegador.
La relación es complementaria. Una empresa de viajes puede mantener un servidor MCP back-end para integraciones API directas con plataformas de inteligencia artificial como ChatGPT o Claude, al mismo tiempo que implementa herramientas WebMCP en su sitio web orientado al consumidor para que los agentes basados en navegador puedan interactuar con su flujo de reservas en el contexto de la sesión activa de un usuario. Los dos patrones sirven a patrones diferentes de interacción libre de conflictos.
La distinción es importante para los arquitectos empresariales. Las integraciones de backend de MCP son adecuadas para la automatización de servicio a servicio donde no se requiere una interfaz de usuario del navegador. WebMCP es apropiado cuando el usuario está presente y la interacción se beneficia del contexto visual compartido, que describe la mayoría de las interacciones web orientadas al consumidor que interesan a las empresas.
Lo que sigue: de la bandera al estándar
WebMCP está actualmente disponible en Chrome 146 Canary detrás de la bandera “WebMCP para pruebas” en chrome://flags. Los desarrolladores pueden participar en Programa de vista previa anticipada de Chrome para acceder a documentación y demostraciones. Otros navegadores aún no han anunciado cronogramas de implementación, aunque la coautoría activa de la especificación por parte de Microsoft sugiere que es probable que se admita Edge.
Los observadores de la industria esperan anuncios formales de navegadores para mediados de 2026, con Google Cloud Next y Google I/O como lugares probables para anuncios de lanzamiento más amplios. La especificación está pasando de una incubación comunitaria dentro del W3C a un borrador formal, un proceso que históricamente ha llevado meses pero que indica un compromiso institucional serio.
La comparación que hizo Sagar es instructiva: WebMCP pretende convertirse en el USB-C de las interacciones de los agentes de IA con la web. Una interfaz única y estandarizada a la que cualquier agente puede conectarse, reemplazando la actual maraña de estrategias de scraping personalizadas y frágiles scripts de automatización.
Hacer realidad esta visión depende de la adopción, tanto por parte de los proveedores de navegadores como de los desarrolladores web. Pero con Google y Microsoft enviando conjuntamente el código, el W3C proporcionando el marco institucional y Chrome 146 ya ejecutando la implementación detrás de un banner, WebMCP ha superado el obstáculo más difícil que enfrenta cualquier estándar web: pasar de una propuesta a un software funcional.
