WebMCP ya está en Chrome 149: cómo preparar tu sitio web para los agentes de IA

Los agentes de IA en el navegador han estado navegando tu sitio web como turistas leyendo un menú en otro idioma: adivinando cada botón, interpretando cada formulario, esperando no equivocarse. El WebMCP Origin Trial de Chrome, disponible desde Chrome 149, finalmente les da un menú en su idioma: descripciones estructuradas de herramientas que convierten la adivinanza en llamadas a funciones deterministas. Esto cambia la arquitectura web a un nivel que la mayoría de los desarrolladores aún no han procesado.

Google lanzó WebMCP (Web Model Context Protocol) como Origin Trial en Chrome 149 en junio de 2026 — un estándar web abierto propuesto que permite a los sitios web exponer herramientas estructuradas directamente a agentes de IA en el navegador. El período de prueba permite a los desarrolladores integrar la API para pruebas en vivo en sus propios orígenes.

En Mintec, hemos estado experimentando con el prototipo de WebMCP desde el anuncio de Google I/O. Esto es lo que encontramos sobre cómo funciona, qué cambia arquitectónicamente y qué deberías hacer al respecto ahora mismo.

La Nueva Tercera Superficie: UI Humana, API Backend, Herramientas para Agentes

Cada aplicación web tiene actualmente dos interfaces: la superficie humana — botones, formularios, menús, enlaces — y la superficie de desarrollador — REST, GraphQL, webhooks e integraciones OAuth.

WebMCP introduce una tercera superficie: herramientas para agentes que operan dentro del contexto del navegador.

Esto importa porque los agentes de navegador actuales hacen algo incómodo: observan la superficie humana, toman capturas de pantalla, analizan el árbol de accesibilidad, adivinan qué significan los botones y hacen click. La fragilidad de este enfoque está bien documentada — la carga asíncrona, los tests A/B, la localización, los menús de permisos y los diseños responsivos rompen la automatización por selectores.

WebMCP resuelve un problema específico: "¿Qué pasaría si el sitio web pudiera describir las acciones que un agente puede realizar, en lugar de forzar al agente a adivinar?"

Cómo Funciona WebMCP en la Práctica

WebMCP expone dos APIs a los agentes del navegador:

WebMCPDiscovery — le dice al agente qué servidores MCP ofrece una página, cómo se llaman y cómo descubrirlos. Piensa en ello como un manifiesto de capacidades para agentes.

MCPServer (variante de navegador) — permite que el sitio exponga herramientas invocables. El agente las descubre, lee sus descripciones y esquemas de parámetros, solicita aprobación del usuario cuando es necesario y las invoca en lugar de recorrer la interfaz humana.

Una aplicación web que implementa descripciones de herramientas WebMCP dice efectivamente: "En lugar de hacer click en mi interfaz, aquí tienes las funciones exactas que puedes llamar, con descripciones de lo que hace cada una, justo aquí en la sesión actual del usuario."

El paralelo con la accesibilidad es útil. Un buen árbol de accesibilidad le dice a un lector de pantalla qué es un elemento y en qué estado está. WebMCP proporciona una capa semántica similar para los agentes, pero con implicaciones mayores — el agente puede realizar acciones, no solo describirlas.

Lo Que Cambia para los Desarrolladores Web

1. La Estrategia de Formularios se Vuelve Más Compleja

Los formularios son donde WebMCP ofrece el valor más inmediato. Actualmente, un agente que intenta "reservar un vuelo" en un sitio de viajes debe:

• Analizar el campo de salida (¿es un campo único o fecha/hora separados?)
• Descifrar el formato de destino (¿nombre de ciudad, código de aeropuerto o autocompletado?)
• Manejar selectores de fecha que son componentes React personalizados
• Enviar y manejar errores

Con WebMCP, el sitio expone una herramienta buscarVuelos con parámetros tipificados (origen, destino, fechaSalida, fechaRegreso). El agente la llama directamente. Sin adivinanzas, sin recorrer campo por campo.

Pero esto significa que cada formulario ahora necesita una descripción de herramienta WebMCP paralela. Es una superficie adicional de desarrollo y mantenimiento — un tercer contrato que mantener sincronizado con los otros dos.

2. Postura de Seguridad: Herramientas Accesibles Son Herramientas Atacables

Las descripciones de herramientas WebMCP deben ser lo suficientemente precisas para que un agente las entienda. Esa misma precisión las convierte en objetivos útiles para la inyección de prompts — una instrucción maliciosa incrustada en el contenido de la página, un correo electrónico o un documento que el usuario abre.

Una herramienta llamada eliminarWorkspace es fácil de razonar para un agente útil. También es fácil de weaponizar para una instrucción inyectada. Como discutimos en nuestro artículo sobre CMS agéntico, el cambio de leer a actuar cambia completamente el cálculo de seguridad.

La documentación de WebMCP de Google enfatiza los flujos de aprobación del usuario y los límites de permisos. En la práctica, el enfoque correcto es defensa en profundidad: permisos de herramientas acotados, valores predeterminados de solo lectura, registros de auditoría y confirmación explícita para operaciones destructivas.

3. El Dilema de la Arquitectura de Renderizado

Las herramientas de agente WebMCP se ejecutan en el contexto del navegador del usuario — funciones JavaScript que pueden leer y escribir el estado de la página. Eso significa que tu sitio debe estar estructurado para que sus herramientas para agentes sean descubribles y mantenibles independientemente de la interfaz humana.

Aquí es donde la arquitectura web componible se vuelve directamente relevante. Si tu sitio está construido como una colección de componentes independientes con límites claros, cada componente puede declarar su propia superficie de herramientas WebMCP. Si tu sitio es una SPA monolítica con estado enmarañado, añadir herramientas para agentes será más difícil.

Además, como mencionamos en nuestro artículo sobre agentes de IA autónomos, la tendencia hacia agentes que operan de forma independiente dentro del navegador no va a desacelerarse. Cuanto antes estructuren tus sitios web para esta realidad, mejor preparado estarás.

El Ángulo de Rendimiento del Que Nadie Habla

Las herramientas WebMCP añaden peso a la página. Cada descripción de herramienta, esquema de parámetros y registro de servidor MCP son bytes que el navegador debe descargar y analizar. En sitios con mucho contenido que ya luchan con el rendimiento, cada kilobyte adicional importa.

La ventaja es que WebMCP puede reducir la necesidad de JavaScript complejo del lado del cliente para la interacción con agentes. En lugar de construir flujos de UI elaborados que un agente intentará recorrer haciendo click (y fallará), construyes una superficie de formularios simple para humanos + una superficie de herramientas WebMCP para agentes. La ruta del agente es más ligera porque se salta el renderizado y la gestión de estado.

Qué Hacer Ahora Mismo

WebMCP es un Origin Trial, lo que significa que es experimental y está sujeto a cambios. No apuestes tu arquitectura de producción todavía — pero empieza a experimentar.

Alta prioridad: Si tu sitio tiene formularios complejos (reserva de viajes, solicitudes de seguros, registro de cuentas), vale la pena unirse al trial porque los formularios son donde el problema de la adivinanza del agente es más doloroso hoy.

Prioridad media: Si estás construyendo un dashboard o producto SaaS donde los agentes podrían necesitar consultar datos o activar acciones, declara primero herramientas de solo lectura y mide las tasas de éxito de interacción del agente antes de añadir herramientas de escritura.

Prioridad baja: Los sitios de contenido y páginas de marketing pueden esperar. La Speculation Rules API para prerenderizado instantáneo es una inversión de rendimiento con mayor ROI hoy que WebMCP.

El Mensaje Final

WebMCP no es un click bot mejorado. Es el comienzo de una nueva capa de interfaz para la web. Cada sitio web tiene actualmente dos superficies — humana y API — y WebMCP añade una tercera. Los equipos que empiecen a diseñar para esa tercera superficie ahora, aunque sea experimentalmente, tendrán una ventaja estructural cuando los agentes de navegador se conviertan en la forma predeterminada en que los usuarios interactúan con aplicaciones web complejas.

El Origin Trial está abierto. La pregunta no es si los agentes interactuarán con tu sitio — ya lo hacen. La pregunta es si prefieres que adivinen o que llamen.