Durante años, automatizar una página web significó una de dos cosas.

La primera era utilizar una API creada específicamente para máquinas.

La segunda era fingir ser un humano.

Un bot abría el navegador, buscaba un botón, hacía clic, escribía en un campo, esperaba una respuesta y volvía a inspeccionar la pantalla.

Los agentes de IA modernos llevaron esa segunda estrategia mucho más lejos gracias a modelos multimodales, árboles de accesibilidad, DOM, Playwright, Chrome DevTools Protocol y sistemas de computer use.

Pero el problema de fondo sigue siendo el mismo:

la mayor parte de la web fue diseñada para que un humano interprete una interfaz, no para que un agente descubra capacidades de forma estructurada.

WebMCP intenta cambiar eso.

La propuesta introduce una API del navegador mediante la cual una página puede declarar explícitamente qué operaciones ofrece a un agente, qué argumentos espera y qué código debe ejecutarse cuando el agente decide usar una de esas capacidades.

En vez de obligar al agente a deducir que un rectángulo azul significa “buscar pedidos”, la aplicación podría publicar una tool llamada get_order_status.

En vez de localizar visualmente un formulario, completar cinco campos y pulsar Submit, el agente podría descubrir una operación estructurada como createSupportRequest.

La idea parece pequeña, pero cambia la arquitectura de la automatización web.

De una interfaz para humanos a una interfaz también para agentes

Una página web tradicional expone principalmente una interfaz visual:

Usuario
   ↓
Browser
   ↓
HTML + CSS + JavaScript
   ↓
Botones, formularios, menús y contenido

Un agente que quiere operar esa página tiene que reconstruir la intención de la interfaz.

Puede hacerlo mediante visión:

Agente
   ↓
screenshot
   ↓
modelo multimodal
   ↓
"ese parece ser el botón Buscar"
   ↓
click

O mediante una representación más estructurada:

Agente
   ↓
DOM / accessibility tree
   ↓
localizar elemento
   ↓
Playwright / CDP
   ↓
click / type / submit

WebMCP añade una tercera posibilidad:

Agente
   ↓
descubre tools
   ↓
search_products(...)
add_to_cart(...)
checkout(...)
   ↓
la propia página ejecuta su lógica

La aplicación deja de ser únicamente una colección de controles visuales y empieza a disponer de una superficie semántica para agentes.

Ésa es la tesis fundamental de WebMCP.

document.modelContext: la pieza central

La propuesta de WebMCP está incubándose en el entorno de Web Machine Learning y ya cuenta con implementaciones experimentales en navegadores Chromium.

Una de sus interfaces más importantes aparece bajo document.modelContext.

Conceptualmente, una página podría registrar una tool así:

await document.modelContext.registerTool({
  name: "get_order_status",
  description: "Busca pedidos dentro de un periodo determinado",
  inputSchema: {
    type: "object",
    properties: {
      timeframe: {
        type: "string",
        enum: ["today", "yesterday", "last_7_days"]
      }
    },
    required: ["timeframe"]
  },
  execute: async ({ timeframe }) => {
    return await getOrders(timeframe);
  }
});

La página está declarando tres cosas importantes:

  1. qué capacidad existe;
  2. qué parámetros acepta;
  3. qué función debe ejecutarse.

El agente ya no necesita inferir esas tres cosas mirando la pantalla.

Puede trabajar con una representación parecida a la que ya utilizan los modelos cuando hacen tool calling.

Esto es especialmente interesante porque el código que realmente resuelve la acción puede seguir siendo el mismo JavaScript que utiliza la aplicación.

No hay que duplicar toda la lógica de negocio en un servicio separado únicamente para agentes.

Dos caminos: API imperativa y API declarativa

WebMCP explora dos maneras principales de publicar capacidades.

1. API imperativa

La primera consiste en registrar tools desde JavaScript.

Es el caso ideal cuando una aplicación ya tiene operaciones internas claramente definidas.

Por ejemplo:

registerTool({
  name: "search_flights",
  inputSchema: { ... },
  execute: async (args) => searchFlights(args)
});

El desarrollador controla explícitamente el nombre, la descripción, el schema y la función de ejecución.

2. API declarativa

La segunda idea es todavía más curiosa.

Un formulario HTML puede describirse de forma que el navegador lo convierta en una capacidad utilizable por agentes.

Una versión simplificada podría verse así:

<form
  toolname="createSupportRequest"
  tooldescription="Envía una solicitud de soporte">

  <input name="email" type="email">
  <textarea name="problem"></textarea>

  <button type="submit">Enviar</button>
</form>

El agente no necesita descubrir cada campo por separado.

Puede razonar sobre algo mucho más cercano a:

createSupportRequest({
  email: "usuario@ejemplo.com",
  problem: "No puedo acceder a mi cuenta"
})

La interfaz visual sigue existiendo, pero ahora dispone de una representación explícita para máquinas.

Eso crea una propiedad muy importante: humanos y agentes pueden interactuar con la misma aplicación sin obligar al desarrollador a construir dos productos completamente separados.

WebMCP no es simplemente “MCP dentro del navegador”

El nombre puede generar confusión.

Model Context Protocol, o MCP, define una arquitectura general para conectar modelos y agentes con herramientas, recursos y otras fuentes de contexto.

De forma simplificada:

LLM / Agent
     ↓
MCP Host
     ↓
MCP Client
     ↓
JSON-RPC
     ↓
MCP Server
     ↓
API / filesystem / database / servicio

Un servidor MCP puede publicar tools y recursos sin depender de una página web concreta.

WebMCP ataca otro nivel del problema:

LLM / Agent
     ↓
Browser Agent
     ↓
Browser
     ↓
document.modelContext
     ↓
Web Application

La diferencia no es cosmética.

MCP es un protocolo de integración entre componentes.

WebMCP es una Web API dentro del contexto de la página.

Eso significa que la página puede reutilizar directamente:

  • su JavaScript;
  • su estado actual;
  • la sesión del usuario;
  • las cookies y credenciales ya gestionadas por el navegador;
  • la interfaz visible;
  • el flujo de navegación actual.

Chrome explica precisamente que WebMCP y MCP son tecnologías complementarias, no sustitutos directos.

Una empresa podría tener un servidor MCP para integraciones backend y, al mismo tiempo, exponer WebMCP desde su aplicación web para operaciones ligadas al estado de la sesión y de la interfaz.

La gran ventaja: reutilizar la sesión y el estado existente

Éste puede ser uno de los argumentos más fuertes a favor del modelo.

Supongamos que un usuario ya inició sesión en una aplicación.

El navegador ya mantiene:

identidad
cookies
sesión
estado de navegación
permisos
preferencias
contexto de la página

Si queremos construir una integración MCP externa, puede ser necesario resolver otra vez parte de esa autenticación mediante OAuth, tokens, APIs o credenciales específicas.

Con WebMCP, la tool vive dentro del mismo contexto de la aplicación.

Podemos imaginarlo así:

Usuario autenticado
       ↓
Aplicación web
       ↓
WebMCP tools
       ↓
Agente autorizado

La capacidad no tiene que reconstruir desde cero la identidad del usuario.

Para aplicaciones complejas, eso puede reducir una cantidad considerable de infraestructura duplicada.

Por qué puede ser mejor que el computer use

Los sistemas de computer use son impresionantes porque pueden operar aplicaciones que jamás fueron diseñadas para agentes.

Ésa es precisamente su gran fortaleza.

Pero también es su principal limitación.

Imaginemos que un agente quiere reservar un hotel.

Con automatización visual podría necesitar:

1. localizar destino
2. hacer click
3. escribir Miami
4. localizar fechas
5. elegir entrada
6. elegir salida
7. buscar botón Search
8. hacer click
9. esperar navegación
10. interpretar resultados
11. localizar filtros
12. aplicar filtros
13. seleccionar hotel

Cada paso añade una posibilidad de error.

Un cambio de diseño puede romper la automatización.

Un popup puede bloquear un botón.

Una traducción puede cambiar un texto.

Una animación puede retrasar un elemento.

Con una superficie WebMCP, parte del flujo podría convertirse en:

search_hotels({
  destination: "Miami",
  check_in: "2026-09-10",
  check_out: "2026-09-13"
})

Después:

filter_results({
  max_price: 250,
  min_rating: 4
})

Y finalmente:

start_booking({ hotel_id: "..." })

No significa que la interfaz desaparezca.

Significa que el agente deja de depender de ella para comprender operaciones que la propia aplicación ya conoce perfectamente.

Tools que aparecen y desaparecen según el estado

Cloudflare ha experimentado con WebMCP dentro de Browser Run y muestra una propiedad especialmente interesante: el conjunto de tools puede cambiar dinámicamente según el estado de la página.

Eso encaja mucho mejor con cómo funcionan las aplicaciones reales.

Por ejemplo:

Página inicial
   ↓
search_products(...)

Después de buscar:

Resultados
   ↓
filter_products(...)
compare_products(...)
open_product(...)

Después de seleccionar un producto:

Detalle
   ↓
add_to_cart(...)
select_variant(...)

Y dentro del carrito:

Cart
   ↓
checkout(...)
apply_coupon(...)

La interfaz para agentes puede evolucionar junto con el flujo de la aplicación.

Eso permite que la página exponga solamente las operaciones válidas en cada momento.

Para un agente, es una forma de reducir el espacio de acciones posibles y, por tanto, parte de la incertidumbre del razonamiento.

WebMCP no elimina Playwright, DOM ni visión

Sería un error interpretar WebMCP como el final de la automatización tradicional del navegador.

La web no va a migrar de golpe.

Durante mucho tiempo existirán páginas sin soporte para WebMCP.

Incluso dentro de una página compatible habrá acciones que no estén publicadas como tools.

Por eso una arquitectura de agente web robusta probablemente termine utilizando varias capas:

Agente
   ↓
¿Existe WebMCP tool?
   ├── sí → usar tool estructurada
   │
   └── no
        ↓
     DOM / accessibility
        ↓
     Playwright / CDP
        ↓
     visión / computer use como fallback

Esta jerarquía tiene bastante sentido.

Usar primero la abstracción más determinista y recurrir a técnicas más heurísticas solamente cuando sea necesario.

En otras palabras:

WebMCP puede convertirse en el camino rápido; la automatización del navegador seguiría siendo el camino universal.

La parte difícil: seguridad

Todo esto sería poco relevante si las tools únicamente pudieran consultar datos inocuos.

El problema aparece cuando una página expone operaciones como:

send_message
purchase_item
transfer_money
delete_repository
cancel_subscription
submit_application

Ahora el agente está operando dentro de una sesión autenticada y potencialmente puede ejecutar acciones con consecuencias reales.

Esto introduce varios vectores de riesgo.

Descripciones maliciosas

Los nombres, descripciones y schemas de una tool forman parte del contexto que recibe el agente.

Una página hostil podría intentar introducir instrucciones diseñadas para manipular al modelo.

Outputs contaminados

Incluso una tool legítima puede devolver contenido controlado por terceros.

Un comentario, una reseña, un mensaje o un documento podrían contener instrucciones de prompt injection dirigidas al agente.

Confusión de autoridad

Que una tool exista no significa que el usuario haya autorizado todas sus posibles ejecuciones.

Un agente puede descubrir delete_account, pero eso no debería equivaler automáticamente a permiso para utilizarla.

Acciones irreversibles

Una compra o transferencia no debería depender únicamente de que el modelo haya interpretado correctamente una conversación.

Por eso los diseños alrededor de WebMCP ponen tanto énfasis en restricciones de origen, exposición controlada de tools y mecanismos human-in-the-loop.

Human-in-the-loop como parte de la arquitectura

Una propiedad muy útil es que una tool no necesariamente tiene que completar toda la operación de forma silenciosa.

Puede preparar una acción y detenerse antes del punto irreversible.

Por ejemplo:

Agent
   ↓
prepare_booking(...)
   ↓
la página muestra el resumen
   ↓
usuario confirma
   ↓
complete_booking(...)

Esta combinación puede ser mucho más razonable que los dos extremos tradicionales:

100% manual

versus

100% autónomo

Para operaciones sensibles, el agente puede encargarse del trabajo mecánico y dejar al usuario el gate final.

Es un patrón que probablemente aparecerá repetidamente en sistemas agénticos serios.

Restricciones de origen

Las páginas web llevan décadas desarrollando un modelo de seguridad basado en orígenes.

WebMCP intenta apoyarse en esa infraestructura en lugar de inventar un universo completamente separado.

Entre las consideraciones de diseño aparecen restricciones para documentos de nivel superior, iframes del mismo origen y exposición explícita cuando se trata de contextos cross-origin.

Esto es importante porque un iframe arbitrario no debería obtener automáticamente acceso a todas las capacidades agénticas de una página.

La pregunta de seguridad cambia de:

¿puede JavaScript ejecutar esta operación?

A algo más amplio:

¿qué agente puede descubrir esta tool, quién puede invocarla y qué confirmación necesita antes de producir efectos reales?

Todavía no es un estándar consolidado

Aquí conviene poner freno al entusiasmo.

WebMCP sigue siendo una tecnología experimental.

En agosto de 2026 existen implementaciones y pruebas en Chromium, incluyendo trabajo en Chrome y Edge, pero no estamos ante una API universal soportada de forma interoperable por todos los navegadores.

WebKit ha expresado objeciones dentro de su proceso de estándares y Mozilla también ha evaluado la propuesta.

Eso significa que todavía pueden cambiar:

  • nombres de APIs;
  • modelos de permisos;
  • detalles del ciclo de vida de las tools;
  • mecanismos de seguridad;
  • integración con agentes;
  • alcance final de la especificación.

Para desarrolladores, WebMCP debe verse hoy como una tecnología para experimentar y aprender, no como una dependencia que podamos asumir disponible en toda la web.

Una posible evolución de la automatización web

Podemos ordenar la evolución de los agentes web en tres generaciones aproximadas.

Primera generación: computer use

LLM
 ↓
screenshot
 ↓
visión
 ↓
mouse / keyboard

Es muy general, pero relativamente frágil.

Segunda generación: automatización estructurada del navegador

LLM
 ↓
DOM / accessibility tree
 ↓
Playwright / CDP

Más determinista, pero todavía requiere interpretar la estructura creada para humanos.

Tercera generación: web agent-native

LLM
 ↓
discover_tools()
 ↓
search()
checkout()
create_issue()
send_message()

Aquí la aplicación reconoce explícitamente que además de usuarios humanos puede tener consumidores agénticos.

WebMCP intenta construir esa tercera capa directamente dentro de la plataforma web.

Lo interesante no es eliminar la interfaz, sino añadir otra

Durante años se habló de que los asistentes de IA podían hacer desaparecer las aplicaciones tradicionales.

WebMCP sugiere una evolución distinta.

La interfaz humana puede seguir existiendo.

HTML
CSS
formularios
botones
visualizaciones

Pero junto a ella aparece una interfaz semántica:

tools
schemas
acciones
estado
confirmaciones

Podemos pensar en una aplicación futura con dos superficies complementarias:

                Aplicación web
                     │
          ┌──────────┴──────────┐
          │                     │
      Human UI             Agent API
          │                     │
 HTML / CSS / UX        WebMCP tools

Ambas operan sobre la misma lógica de negocio.

Eso puede ser bastante más eficiente que mantener una web, una API pública, una integración especial para cada asistente y varias capas de automatización separadas.

MCP + WebMCP + browser automation

La arquitectura más interesante probablemente no será elegir una sola tecnología.

Será combinarlas.

Un agente moderno podría trabajar así:

                        Agent
                          │
             ┌────────────┼────────────┐
             │            │            │
            MCP        WebMCP      Browser Use
             │            │            │
        backend APIs   página viva   fallback UI
             │            │            │
             └────────────┴────────────┘
                          │
                    mundo digital

MCP puede darle acceso estable a servicios y datos backend.

WebMCP puede darle operaciones ligadas a la sesión y al estado actual de una página.

Playwright, DOM y computer use pueden cubrir todo lo que no exponga una interfaz explícita para agentes.

En vez de competir, estas capas pueden formar una jerarquía de herramientas.

Es una idea parecida a lo que ocurre en los agent harnesses: cuanto mejor es la infraestructura alrededor del modelo, menos trabajo tiene que resolver el LLM mediante razonamiento frágil. En Capital de Tokens ya analizamos ese cambio al hablar de Codex como plataforma y agent harness y de DeepSeek Harness.

WebMCP lleva esa misma lógica al navegador.

La web empieza a asumir que los agentes también son usuarios

Ésa puede ser la lectura más importante.

Durante décadas, la web optimizó su plataforma alrededor de humanos que navegan páginas.

Los agentes llegaron después y empezaron a operar sobre esa infraestructura mediante visión, scraping, DOM y automatización.

WebMCP invierte la relación.

La aplicación puede empezar a decir explícitamente:

Estas son mis capacidades.
Éstos son sus parámetros.
Éste es el estado válido.
Ésta es la función que debes ejecutar.
Y aquí necesitas confirmación humana.

Si ese modelo consigue suficiente adopción, la automatización web puede dejar de parecerse a un robot que mueve un ratón y empezar a parecerse mucho más a un sistema operativo de servicios descubribles por agentes.

Todavía estamos lejos de que toda la web funcione así.

Pero la dirección es importante.

WebMCP no intenta enseñar al agente a mirar mejor una página. Intenta hacer que la propia página pueda hablar el idioma de los agentes.

Y si la web realmente se vuelve agéntica, esa diferencia puede terminar siendo enorme.

Fuentes técnicas