WebMCP explicado: qué es, cómo funciona y por qué está cambiando la web

El 10 de febrero de 2026, André Cipriani Bandarra, de Google, publicó una breve entrada en el blog Chrome for Developers en la que presentaba una vista previa temprana de WebMCP, el Web Model Context Protocol. La premisa era engañosamente sencilla: ¿y si los sitios web pudieran decirles a los agentes de IA exactamente qué pueden hacer, en lugar de obligarlos a adivinarlo?

Esa idea, sustituir las conjeturas por un contrato estructurado entre los sitios web y la IA, va camino de convertirse en un estándar web formal. Cuenta con el respaldo de Google y Microsoft, se está incubando en el W3C y su primera implementación en un navegador ya funciona en Chrome Canary.

Para entender por qué importa, piensa en lo que ocurre hoy cuando le pides a un asistente de IA que te reserve un vuelo. El agente hace una captura de pantalla de la web de la aerolínea, se la pasa a un modelo de visión, intenta averiguar qué elemento de la pantalla es el campo de salida, escribe en él, hace otra captura, busca el botón de búsqueda, lo pulsa, hace otra captura, y así sucesivamente: docenas de costosas llamadas de inferencia solo para rellenar un formulario. Si la aerolínea rediseña su página la semana siguiente, todo el proceso deja de funcionar.

WebMCP sustituye todo ese bucle por una única llamada a una función: searchFlights("AMS", "JFK", "2026-06-15"). El sitio web publica la función. El agente la llama. Y listo.

La comunidad SEO reaccionó de inmediato. El experto en SEO técnico Dan Petrovic lo calificó como el mayor cambio en el SEO técnico desde los datos estructurados, y WordLift resumió bien la analogía: si Schema.org aportó los sustantivos estandarizados de la web, WebMCP aporta los verbos estandarizados.

¿Qué es WebMCP?

WebMCP son las siglas de Web Model Context Protocol. Es una propuesta de estándar web que permite a los sitios exponer su funcionalidad como "herramientas" estructuradas e invocables que los agentes de IA pueden llamar directamente a través del navegador.

La especificación la firman conjuntamente ingenieros de Google y Microsoft: Brandon Walderman, Leo Lee y Andrew Nolan por parte de Microsoft, y David Bokan, Khushal Sagar y Hannah Van Opstal por parte de Google. Se está desarrollando en el W3C Web Machine Learning Community Group, el mismo foro del W3C en el que se incuban otros estándares de aprendizaje automático para el navegador, con el objetivo de que se convierta en un estándar web de adopción generalizada.

A fecha de febrero de 2026, WebMCP está disponible tras un flag experimental en Chrome 146 Canary. Los desarrolladores pueden acceder a la documentación y a las demos uniéndose al Early Preview Program de Google. Dado el papel activo de Microsoft como coautora de la especificación, se da por hecho que Edge también lo incorporará.

La propia especificación describe WebMCP como "una interfaz de JavaScript que permite a los desarrolladores web exponer la funcionalidad de su aplicación web como 'herramientas': funciones de JavaScript con descripciones en lenguaje natural y esquemas estructurados que pueden invocar agentes de IA, asistentes del navegador y tecnologías de asistencia".

Esa última expresión, tecnologías de asistencia, es fácil de pasar por alto, pero importa. Buena parte de lo que dificulta la web a los agentes de IA también se la dificulta a los lectores de pantalla y a otras herramientas de accesibilidad. El enfoque de herramientas estructuradas de WebMCP podría mejorar notablemente ambos casos.

El problema que resuelve WebMCP

Hoy, los agentes de IA interactúan con los sitios web de dos formas principales, y ambas tienen limitaciones de fondo.

Los agentes visuales hacen capturas de pantalla de las páginas, se las pasan a modelos de visión e intentan localizar botones y campos de formulario analizando píxeles. Cada interacción exige una nueva captura y una nueva llamada de inferencia. Una simple búsqueda de un producto puede requerir una docena de idas y vueltas. Si el diseño del sitio cambia aunque sea un poco (un rediseño, un test A/B, otro tamaño de pantalla), el agente puede fallar.

Los agentes basados en el DOM analizan el HTML en bruto de la página y su árbol de accesibilidad para extraer datos y disparar eventos. Es más fiable que analizar píxeles, pero sigue obligando al agente a consumir una gran parte de su ventana de contexto leyendo la estructura de la página, y le exige deducir qué hace realmente cada elemento. Un <button> con la etiqueta "Go" puede significar buscar, enviar, navegar o borrar: el agente tiene que inferirlo por el contexto.

Los dos enfoques comparten el mismo defecto de base: la IA intenta usar una interfaz humana que nunca se diseñó para máquinas. Como dice la especificación de WebMCP, "incluso cuando los agentes lo consiguen, las operaciones sencillas suelen requerir varios pasos y pueden ser lentas o poco fiables".

WebMCP propone una tercera vía. En lugar de que el agente averigüe qué puede hacer un sitio web, es el sitio el que declara explícitamente sus capacidades, y el agente las llama directamente.

Cómo funciona WebMCP

WebMCP introduce una nueva API del navegador: navigator.modelContext. A través de ella, un sitio web registra "herramientas": funciones de JavaScript con descripciones en lenguaje natural y esquemas de parámetros tipados. En conjunto, estas definiciones forman lo que se ha dado en llamar el Tool Contract del sitio: un menú legible por máquinas con todas las acciones que un agente de IA puede realizar en esa página.

La especificación ofrece dos formas complementarias de definir estas herramientas.

La API declarativa (basada en HTML)

Es la vía más sencilla. Los desarrolladores añaden atributos nuevos a sus formularios HTML ya existentes y el navegador los convierte automáticamente en herramientas que los agentes pueden invocar. No hace falta JavaScript.

<form toolname="searchFlights"
      tooldescription="Search for available flights between airports">
  <input name="origin" type="text" required pattern="[A-Z]{3}">
  <input name="destination" type="text" required pattern="[A-Z]{3}">
  <input name="date" type="date" required>
  <button type="submit">Search</button>
</form>

Los atributos toolname y tooldescription son lo único que se añade. El navegador lee la estructura que ya tiene el formulario (nombres de campo, tipos, patrones de validación, campos obligatorios) y genera un esquema que un agente de IA puede entender e invocar. En los sitios que ya tienen formularios bien estructurados, esto se acerca mucho a una mejora que se instala sin más.

Cuando un agente invoca una herramienta declarativa, el navegador dispara un SubmitEvent con la propiedad agentInvoked establecida en true. Así, el backend puede distinguir entre los envíos de personas y los de agentes, algo útil para la analítica, para limitar la frecuencia de peticiones o para devolver los datos en un formato pensado para máquinas en lugar de HTML renderizado.

La API imperativa (basada en JavaScript)

Para interacciones que van más allá del envío de formularios (flujos dinámicos de varios pasos, procesamiento de datos en tiempo real, lógica condicional), los desarrolladores registran las herramientas mediante código:

navigator.modelContext.registerTool({
  name: "getFlightStatus",
  description: "Check real-time status of a specific flight",
  schema: {
    type: "object",
    properties: {
      flightNumber: { type: "string", description: "IATA flight number" },
      date: { type: "string", format: "date" }
    },
    required: ["flightNumber"]
  },
  handler: async ({ flightNumber, date }) => {
    const status = await flightAPI.getStatus(flightNumber, date);
    return { status: status.state, gate: status.gate, delay: status.delay };
  }
});

Esto ofrece un control total desde el código. Los desarrolladores pueden añadir y quitar herramientas de forma dinámica según el estado de la aplicación, y mostrar unas capacidades u otras en función de si el usuario ha iniciado sesión, de la página en la que está o del paso del flujo al que ha llegado. Y lo más importante: las funciones handler pueden reutilizar la misma lógica de frontend que ya mueve la interfaz del sitio. No construyes una capa de integración aparte; expones lo que ya tienes hecho.

El navegador como intermediario

Una de las decisiones de diseño de mayor alcance de WebMCP es que el navegador hace de intermediario en toda la comunicación entre el sitio web y el agente. El sitio registra las herramientas a través de navigator.modelContext. El navegador se las presenta al agente en el formato que este necesite. El sitio web y el agente nunca hablan directamente.

Como explicó Patrick Brosset, del equipo de Microsoft Edge: "Es el navegador el que habla con el agente. La especificación usa el término 'Model context provider'. A través de navigator.modelContext, tu página web aporta contexto (las herramientas que luego utiliza un agente de IA), pero es el navegador el que se encarga del trabajo del protocolo por ti".

Esta arquitectura resuelve tres problemas a la vez.

La autenticación se hereda. Las herramientas se ejecutan dentro de la pestaña del navegador, en el contexto de la sesión que el usuario ya tiene abierta. Si has iniciado sesión en una tienda online, el agente tiene acceso a esa misma sesión: sin flujos OAuth aparte, sin claves de API y sin gestión de tokens.

El usuario mantiene el control. Todo ocurre dentro de la pestaña visible del navegador, así que el usuario puede ver lo que hace el agente. Para las acciones delicadas (compras, envío de datos personales, borrados), la especificación incluye agent.requestUserInteraction(), que detiene la ejecución y pide al navegador que obtenga la confirmación explícita del usuario antes de continuar.

Independencia de la plataforma. Da igual que el agente que visita el sitio funcione sobre ChatGPT, Claude, Gemini o un modelo empresarial propio: el Tool Contract del sitio web es el mismo. El navegador se encarga de normalizar la interacción.

De dónde viene WebMCP

WebMCP no nació en Google ni en Microsoft. Nació de la frustración de un ingeniero de Amazon.

A principios de 2025, Alex Nahas desarrollaba agentes de IA internos en Amazon con el Model Context Protocol (MCP) de Anthropic. Amazon había montado lo que en la práctica era un gigantesco servidor MCP que exponía miles de herramientas de sus servicios internos. "Tenías que desactivarlas con comandos de proceso en la cadena de conexión", contó Nahas a Arcade.dev. Era engorroso, pero el verdadero obstáculo era la autenticación. La especificación de MCP había adoptado OAuth 2.1, que prácticamente ningún servicio interno de Amazon había implementado. Cada servicio tenía su propio sistema de autenticación, y ninguno hablaba OAuth.

Entonces Nahas cayó en la cuenta de que el navegador ya había resuelto ese problema. Los empleados de Amazon accedían a todos los servicios internos mediante una autenticación federada basada en el navegador. Si se podían ejecutar herramientas al estilo MCP dentro de la pestaña del navegador, toda esa autenticación venía incluida sin coste alguno.

Desarrolló MCP-B (Model Context Protocol for Browser) como prueba de concepto. Funcionó. Y lo publicó como código abierto.

Mientras tanto, ingenieros de Google y Microsoft trabajaban por su cuenta en problemas parecidos. Los equipos entraron en contacto a través del W3C, llegaron a una especificación unificada en agosto de 2025 y la publicaron en GitHub. El W3C Web Machine Learning Community Group la aceptó como entregable formal en septiembre de 2025. En febrero de 2026, Google lanzó la primera implementación en un navegador.

Un matiz importante: pese al nombre, WebMCP no es técnicamente MCP. Según explicó Nahas, al principio insistió en llevar el protocolo MCP completo (JSON-RPC incluido) al navegador, pero el grupo de trabajo prefirió no atarse demasiado a la especificación de Anthropic. WebMCP comparte el modelo conceptual de MCP (herramientas con esquemas a las que llaman los agentes), pero es un estándar distinto y nativo del navegador.

WebMCP frente a MCP y NLWeb

Los nombres se prestan a confusión, así que conviene aclarar qué lugar ocupa WebMCP junto a los demás protocolos del ecosistema de agentes de IA.

El MCP (Model Context Protocol) de Anthropic es un protocolo de backend. Conecta las plataformas de IA con servicios externos mediante integraciones en el servidor que usan JSON-RPC. Si quieres que Claude o ChatGPT consulten la base de datos de tu empresa, MCP es la forma de construir esa conexión. Requiere una infraestructura de servidor dedicada.

NLWeb, de Microsoft, anunciado en mayo de 2025, ofrece a los sitios web una interfaz de consulta en lenguaje natural y convierte cada sitio en un servidor MCP para los agentes del ecosistema en general. Funciona a nivel de API: los agentes hablan directamente con el backend del sitio.

WebMCP se ejecuta por completo en el cliente, en el navegador. El sitio web registra las herramientas al cargarse la página. El navegador se las expone a los agentes que lo visitan. No hace falta infraestructura de backend. La autenticación se hereda de la sesión del usuario.

Los tres son complementarios, no rivales. Una empresa podría usar MCP para integraciones profundas con el backend, NLWeb para el acceso en lenguaje natural a nivel de API y WebMCP para las interacciones en el navegador en las que el usuario está presente. La diferencia clave: WebMCP es el único que permite a los desarrolladores reutilizar el código de frontend que ya tienen y no exige ninguna infraestructura nueva en el servidor.

Por qué es importante

Lo que hace relevante a WebMCP no es tanto una función concreta como la combinación de varias propiedades.

Un coste por interacción mucho menor. Una sola llamada estructurada a una herramienta sustituye lo que antes requería docenas de idas y vueltas con capturas de pantalla, inferencia de modelos de visión y análisis del DOM. Los primeros datos apuntan a una reducción de aproximadamente el 67 % de la carga computacional frente a los enfoques de agentes visuales. Para los sitios con mucho tráfico que gestionan miles de interacciones de agentes al día, el ahorro es considerable.

Una fiabilidad que no depende del diseño. Las llamadas a funciones estructuradas no dejan de funcionar cuando un diseñador mueve un botón, cambia el nombre de una clase CSS o lanza un test A/B. El Tool Contract ofrece una interfaz estable e independiente de la maquetación visual, lo que significa que los agentes y los diseñadores web pueden evolucionar cada uno por su lado.

Un esfuerzo mínimo para los desarrolladores. La API declarativa solo exige añadir dos atributos HTML a los formularios existentes. Sin JavaScript, sin endpoints nuevos y sin documentación de API que mantener. Para la mayoría de los sitios web, el camino para estar "preparados para agentes" es más corto que el de la mayoría de las optimizaciones SEO.

La accesibilidad como efecto secundario. Las mismas definiciones estructuradas que ayudan a los agentes de IA también ayudan a las tecnologías de asistencia. Los lectores de pantalla y otras herramientas de accesibilidad se enfrentan a muchas de las mismas dificultades que los agentes de IA cuando intentan entender qué hace una página web, y no solo qué dice. WebMCP podría mejorar de forma notable ambos casos.

Sectores y casos de uso

La documentación de la vista previa temprana de Google destaca varios casos de uso principales, todos ellos con flujos de usuario estructurados y de varios pasos.

El comercio electrónico es el beneficiario más evidente. En lugar de que un agente de IA tropiece con filtros de productos, selectores de talla y procesos de pago, la tienda expone herramientas como searchProducts(query, priceRange, category), addToCart(productId, quantity, size) y checkout(paymentMethod). Todo el recorrido, del descubrimiento a la compra, se convierte en una serie de llamadas a funciones limpias. Para las empresas, esto podría traducirse en tasas de conversión mucho más altas en las compras realizadas por agentes.

Los viajes y la hostelería encajan de forma natural. La búsqueda de vuelos, la reserva de hoteles y el alquiler de coches son transacciones estructuradas con varios parámetros que se corresponden directamente con definiciones de herramientas. Google citó expresamente la reserva de viajes como uno de los principales casos de uso verificados.

Los productos SaaS pueden exponer sus flujos de trabajo principales a los agentes. Imagina decirle a un asistente de IA "crea un tablero de proyecto nuevo con tres columnas e invita a mi equipo" y que lo ejecute mediante llamadas estructuradas a herramientas, en lugar de simular clics y pulsaciones de teclado.

Los portales de atención al cliente pueden definir herramientas para crear incidencias, consultar su estado y clasificarlas. Un agente que puede llamar directamente a createTicket(category, urgency, description) es mucho más fiable que uno que tiene que recorrer visualmente un formulario de soporte de varios pasos.

Las implicaciones para el SEO

La fuerte reacción de la comunidad SEO ante WebMCP no es exageración: refleja un cambio estructural en la forma en que se descubren y se usan los sitios web.

La analogía con Schema.org resulta útil. Cuando llegaron los datos estructurados, dieron a los buscadores una forma estandarizada de entender qué significa el contenido. Los sitios que los adoptaron pronto consiguieron fragmentos enriquecidos, presencia en los paneles de conocimiento y más visibilidad en las búsquedas. Los que no lo hicieron se encontraron en desventaja, y tardaron años en recuperar el terreno.

WebMCP hace algo paralelo, pero para otra época. Da a los agentes de IA una forma estandarizada de entender qué acciones admite un sitio web. A medida que los agentes se convierten en una vía principal para interactuar con la web (reservar viajes, comprar, gestionar servicios), los sitios con Tool Contracts claros y fiables serán aquellos con los que los agentes puedan trabajar con confianza.

Esto crea un nuevo tipo de dinámica competitiva. Si un agente de IA puede llamar directamente a bookFlight() en una web de viajes pero en otra tiene que abrirse paso a la fuerza analizando píxeles, la opción estructurada será más rápida, más barata y menos propensa a errores. Con el tiempo, esa ventaja en fiabilidad se acumula: los agentes (y las plataformas que los alojan) tenderán a dirigir a los usuarios hacia los sitios con los que resulta más fácil y barato interactuar.

Para las empresas, estar preparado para WebMCP podría llegar a ser tan importante como lo fue el diseño adaptable a móviles hace una década. No de la noche a la mañana, sino de forma progresiva, a medida que se amplíe la compatibilidad de los navegadores y crezcan las interacciones a través de agentes.

Cómo empezar

WebMCP está en vista previa temprana, así que el momento de adoptarlo pronto es ahora.

Revisa los flujos clave de tu sitio. Identifica las acciones principales de los usuarios (búsqueda, reservas, pago, envío de formularios, gestión de la cuenta) que saldrían ganando si se expusieran como herramientas. Empieza por las transacciones de mayor valor.

Empieza por la API declarativa. Si tienes formularios HTML limpios y bien estructurados, añadir los atributos toolname y tooldescription es el camino más rápido. No requiere JavaScript y apenas implica cambios en el código.

Únete al Early Preview Program. El EPP de Google da acceso a la documentación completa, a demos y a herramientas de prueba. Puedes apuntarte a través del sitio de Chrome for Developers.

Haz pruebas en Chrome Canary. Activa el flag "WebMCP for testing" en Chrome 146 Canary. El Model Context Tool Inspector de Google ofrece herramientas de depuración para validar las definiciones de tus herramientas.

Explora la API imperativa para los flujos complejos que necesiten registrar herramientas de forma dinámica o lógica de varios pasos.

Si quieres empezar a desarrollar antes de que la compatibilidad nativa de los navegadores esté generalizada, el polyfill MCP-B de Alex Nahas (@mcp-b/global) ya te permite registrar herramientas con navigator.modelContext.registerTool(). Funciona con frameworks de frontend de llamadas a herramientas ya existentes, como CopilotKit, AGUI y SystintUI. La documentación completa está en docs.mcp-b.ai.

La especificación del W3C está disponible en GitHub.

Qué viene ahora

La especificación sigue siendo un borrador, pero la dirección está clara.

El despliegue formal en los navegadores se espera para mediados o finales de 2026. Google I/O y Google Cloud Next son los escenarios más probables para anuncios de mayor alcance. Dado que Microsoft es coautora de la especificación, Edge debería seguir el calendario de Chrome. Patrick Brosset, del equipo de Edge, ha dejado clara la intención de seguir invirtiendo: "En el equipo de Edge no solo nos importa mantener a la persona dentro del proceso, también a los desarrolladores. Por eso nos importa WebMCP".

La API sigue evolucionando. La interfaz ya ha pasado del anterior window.agent a window.navigator.modelContext, y desde la propuesta inicial de agosto de 2025 se han añadido funciones como agent.requestUserInteraction(). La comunidad del W3C está puliendo activamente la especificación a partir de pruebas reales.

La compatibilidad multimodal figura en la hoja de ruta del ecosistema MCP en general. Se espera que las futuras versiones del protocolo admitan imágenes, vídeo y audio, de modo que los agentes no solo lean y escriban, sino que también interpreten contenido visual y sonoro dentro del mismo marco.

La comunicación entre agentes es la próxima frontera. La especificación actual se centra en la interacción entre usuario y agente a través del navegador, pero la hoja de ruta contempla escenarios en los que unos agentes delegan tareas en otros a través de múltiples servicios y páginas.

Preguntas frecuentes

¿WebMCP es lo mismo que el MCP de Anthropic? No. Comparten un modelo conceptual (herramientas con esquemas a las que pueden llamar los agentes), pero WebMCP es un estándar distinto. No usa JSON-RPC, se ejecuta por completo en el navegador (no en servidores de backend) y se diseñó específicamente para la plataforma web. Los dos son complementarios: una empresa podría adoptar ambos para casos de uso distintos.

¿Qué navegadores son compatibles con WebMCP? A fecha de febrero de 2026, WebMCP está disponible en Chrome 146 Canary tras el flag "WebMCP for testing". Se espera en general que Edge lo incorpore, dado el papel de Microsoft como coautora de la especificación. El despliegue formal está previsto para mediados o finales de 2026.

¿Tengo que reescribir mi sitio web? No. La API declarativa te permite añadir compatibilidad con WebMCP incorporando dos atributos HTML a los formularios que ya tienes. En los sitios con un HTML limpio y bien estructurado, los cambios son mínimos. La API imperativa requiere JavaScript, pero puede reutilizar la lógica de frontend existente.

¿Pueden los agentes de IA actuar sin el permiso del usuario? No por diseño. WebMCP incluye agent.requestUserInteraction(), que detiene la ejecución para pedir la confirmación del usuario en las acciones delicadas. La especificación se basa en el principio de que ninguna acción con consecuencias debe producirse sin que el usuario lo sepa y lo consienta.

¿WebMCP mejora la accesibilidad? Es posible que sí. Las definiciones estructuradas de herramientas que ayudan a los agentes de IA a entender qué hace una página también pueden ayudar a los lectores de pantalla y a otras tecnologías de asistencia. La especificación del W3C menciona expresamente las tecnologías de asistencia como caso de uso, junto a los agentes de IA.

¿Cómo afecta WebMCP al SEO? El panorama completo todavía se está definiendo, pero el paralelismo estructural con Schema.org es claro. A medida que los agentes de IA se convierten en un canal de transacciones y de descubrimiento, los sitios con Tool Contracts bien definidos serán más fáciles y baratos de usar para los agentes, lo que crea una ventaja natural similar a la que obtuvieron en las búsquedas quienes adoptaron pronto los datos estructurados.

En resumen

Durante treinta años, la web ha sido un lugar pensado para ojos y manos humanos. Cada página, cada botón y cada formulario dan por hecho que al otro lado hay una persona. WebMCP es el primer intento serio, respaldado por estándares, de que los agentes de IA puedan entender la web y actuar en ella de forma nativa, sin sacar a la persona del proceso.

Todavía es pronto. La especificación es un borrador. La compatibilidad de los navegadores es experimental. Pero los cimientos son sólidos: dos de los mayores fabricantes de navegadores del mundo colaborando a través del W3C, una implementación funcional ya disponible para pruebas y una experiencia de desarrollo lo bastante sencilla como para que la mayoría de los sitios puedan empezar con dos atributos HTML.

Las empresas que supieron ver pronto la importancia de los datos estructurados se ganaron años de ventaja competitiva en las búsquedas. Con WebMCP se está abriendo ahora la misma ventana, y no permanecerá abierta para siempre.