Explicación de WebMCP: Proporcionar a los agentes de IA de los navegadores herramientas en lugar de conjeturas.

Pídale a un agente de IA que reserve un vuelo en un sitio web y observe qué sucede. Abre la página y comienza a explorarla. ¿Cuál es el elemento del selector de fechas? ¿Qué desplegable contiene la destinación? ¿Qué botón requiere dos clics porque hay un modal encima? A veces el agente logra completar la tarea. Otras veces hace clic en algo incorrecto, llena un campo con datos irrelevantes o se detiene en el paso de pago porque el diseño cambió después de entrenar el modelo.

Así es como operan hoy en día la mayoría de los agentes basados en navegador. Extraen el DOM, determinan la función de cada elemento a partir de su etiqueta y de su ubicación, y luego simulan los clics y pulsaciones que realizaría una persona. Esta técnica se denomina actuación, y aunque funciona bien en las demostraciones, falla en la práctica. Cambiar una clase CSS o mover un botón puede hacer que un agente que funcionaba ayer deje de funcionar.

WebMCP es una respuesta a eso. Si conoces el Model Context Protocol (MCP) en el backend, la idea es fácil de explicar: tomar el concepto de herramientas y trasladarlo al navegador, de modo que esté presente en las páginas que se crean.

Por qué no basta con analizar el DOM

Actualmente, los agentes acceden a un servicio por una de dos vías:

• Integración con el backend. El servicio registra las herramientas en una plataforma de IA, a través de un servidor MCP, OpenAPI o alguna API propietaria, y la IA se comunica directamente con el servidor sin interactuar con el navegador.
• Activación desde el navegador. El agente abre la página como lo haría un humano e intenta adivinar qué elementos hacer clic o completar.

Esta activación es costosa y fácil de error. Cada paso puede interpretarse mal, especialmente en interfaces complejas y en capas, como las aplicaciones modernas de una sola página.

WebMCP añade una tercera vía, que no es ni una integración con backend ni un clic automático. El propio sitio indica qué puede hacer. En lugar de que un agente adivine qué función tiene el botón de pago, el desarrollador especifica qué hace el proceso de pago, qué datos necesita y qué devuelve.

Qué es WebMCP

WebMCP es un estándar web propuesto por el Web Machine Learning Community Group del W3C. La especificación define una API de JavaScript además de anotaciones para los elementos de formulario HTML, de modo que un agente sepa cómo utilizar las funciones de la página sin tener que adivinar.

Compárelo con MCP de backend. Una página que implementa WebMCP se comporta como un servidor MCP cuyas herramientas se ejecutan como scripts del lado del cliente. Donde normalmente se necesitaría un servidor separado para exponer una función, se puede registrar esa función desde el JavaScript que ya está ejecutándose en la página.

El diseño está formado por tres componentes:

• Descubrimiento: una forma estándar para que las páginas registren herramientas como checkout o search_products con un agente.
• JSON Schema: definiciones explícitas de las entradas y salidas esperadas, lo que reduce las alucinaciones y los malentendidos.
• Estado: una visión compartida del contexto actual de la página, de modo que el agente sepa en qué puede actuar en ese momento.

Otro detalle: las herramientas siguen ejecutándose de forma visible en la página. Cuando un agente llama a una herramienta add_to_cart, el resultado se muestra en la interfaz de usuario en lugar de ocurrir en silencio. Esto es importante para generar confianza, ya que los usuarios pueden ver qué se ha hecho por ellos y el experiencia que diseñaste no se elude.

Registro de WebMCP en un sitio

Añadirlo a un sitio existente no implica reconstruirlo. Se trata de una capa de comunicación adicional que se coloca sobre un backend que ya funciona. Los pasos son los siguientes:

1. Habilitar el entorno. Dado que el estándar aún está en fase de propuesta, háblalo manualmente para realizar pruebas. En Chrome, abra chrome://flags/#enable-webmcp-testing, úselo en la opción “Habilitado” y reinicie el navegador. Para algo más cercano a la producción, regístrese en la prueba de origen WebMCP que estará disponible a partir de Chrome 149, de modo que los visitantes reales puedan utilizar esta función sin tener que manipular las opciones del navegador.

2. Elija las herramientas que valga la pena exponer. Es fácil subestimar este paso. No exponga todas las funciones solo porque pueda hacerlo. Piense en qué acciones la gente realmente querría que un agente les ayudara a realizar, generalmente aquellas con un propósito claro: buscar, filtrar, enviar un formulario, realizar un pago. Evite decenas de herramientas en una sola página, ya que cada herramienta registrada ocupa espacio en la ventana de contexto y un menú largo dificulta la elección del agente.

3. Elija la API imperativa o declarativa. La API imperativa registra herramientas con JavaScript puro a través de registerTool y es adecuada para lógicas más complejas como la gestión de estado, la navegación o la concatenación de acciones. La API declarativa coloca anotaciones directamente en un <form> HTML estándar, y la herramienta se construye automáticamente, lo cual es adecuado para casos simples basados en formularios. Los proyectos React y Angular cuentan con opciones nativas del framework. React ofrece el paquete usewebmcp, cuyo hook useWebMCP vincula el ciclo de vida de una herramienta al montaje y desmontaje de un componente. Angular dispone de soporte experimental que permite convertir Signal Forms en herramientas.

4. Haga que inputSchema sea detallado. Esto determina hasta qué punto un agente comprende la herramienta. Escriba la description en un lenguaje natural sencillo y no en abreviaturas internas, y defina cada propiedad junto con su tipo. Para un conjunto cerrado de valores, utilice enum para que sea menos probable que el agente envíe algo inválido.

5. Establezca annotations de acuerdo con el riesgo real. Cada herramienta necesita una etiqueta precisa:

• readOnlyHint: true para una herramienta que solo lee y deja todo sin cambios.
• consequentialHint: true para una acción con efectos reales, que debería solicitar primero la confirmación del usuario.
• untrustedContentHint: true cuando la salida incluye contenido de otros usuarios, como reseñas o comentarios, que podrían ocultar una instrucción.

6. Conecte execute a un endpoint existente. La función execute puede simplemente llamar a la ruta de API que ya tiene, utilizando fetch(). Una ruta de Laravel funciona perfectamente. No existe un backend WebMCP separado. Está creando un puente frontend hacia una lógica de negocio ya probada en producción.

7. Pruébelo. Agregue la extensión de Chrome llamada Model Context Tool Inspector (Chrome Web Store), cargue su página y vea qué herramientas se registran. También puede comunicarse con un agente desde allí para confirmar que su herramienta se llama y que su esquema se lee con claridad.

8. Trátelo como una mejora progresiva. El soporte de los navegadores es limitado, por lo que los clics en botones normales deben seguir funcionando para los visitantes cuyos navegadores no cuentan con WebMCP. Esto añade una ruta adicional sin reemplazar la anterior.

Ejemplo: una herramienta de estado de pedidos

Tomemos una tienda en línea construida con Laravel que cuenta con una página de estado de pedidos. El flujo normal consiste en que un usuario inicia sesión, abre “Mis pedidos”, elige un rango de fechas y consulta una lista de pedidos con su estado de envío. Un agente que utilice métodos manuales tendría que encontrar el menú desplegable y el botón de envío adecuados, y luego analizar una tabla de resultados a partir de HTML sin procesar, lo cual deja de funcionar en cuanto cambia la estructura del marcado.

Con WebMCP, una sola herramienta abarca el endpoint que ya existe:

await document.modelContext.registerTool({
  name: 'get_order_status',
  description: 'Look up orders within a given timeframe. Returns order number, shipping status, and current location.',
  inputSchema: {
    type: 'object',
    properties: {
      timeframe: {
        type: 'string',
        enum: ['today', 'yesterday', 'last_7_days', 'last_30_days', 'last_6_months'],
        description: 'Timeframe for the order lookup.'
      }
    },
    required: ['timeframe']
  },
  annotations: {
    readOnlyHint: true,
    consequentialHint: false,
    untrustedContentHint: false
  },
  execute: async ({ timeframe }) => {
    const response = await fetch(`/api/orders/status?range=${timeframe}`, {
      headers: { 'Accept': 'application/json' }
    });
    const data = await response.json();
    return JSON.stringify(data);
  }
});

Tres detalles destacan. inputSchema evita que el agente tenga que adivinar el formato, ya que sabe qué valores acepta timeframe. La anotación readOnlyHint: true indica que la herramienta no tiene efectos secundarios, por lo que no se requiere confirmación. Además, execute simplemente llama a una ruta existente de Laravel, por lo que no se reconstruye nada.

El proceso de pago es más delicado, ya que se transfiere dinero y se realiza un pedido. Esto requiere una señal diferente:

await document.modelContext.registerTool({
  name: 'checkout_cart',
  description: 'Completes checkout for the currently logged-in user\'s cart.',
  inputSchema: {
    type: 'object',
    properties: {
      paymentMethod: { type: 'string', description: 'Payment method selected by the user' }
    },
    required: ['paymentMethod']
  },
  annotations: {
    readOnlyHint: false,
    consequentialHint: true,
    untrustedContentHint: false
  },
  execute: async ({ paymentMethod }) => {
    const response = await fetch('/api/checkout', {
      method: 'POST',
      headers: { 'Content-Type': 'application/json' },
      body: JSON.stringify({ payment_method: paymentMethod })
    });
    return await response.text();
  }
});

Con consequentialHint: true, el navegador o agente sabe que debe mostrar un diálogo de confirmación antes de ejecutarse. Incluso si el agente pulsa el botón, la decisión final queda en manos de la persona.

Para listar las herramientas registradas en una página:

const tools = await document.modelContext.getTools();
console.log(tools);

Y para activar uno manualmente a efectos de pruebas:

const [tool] = await document.modelContext.getTools();
const result = await document.modelContext.executeTool(tool, '{"timeframe": "last_7_days"}');

Un viaje de ida y vuelta completo

Esta es la secuencia cuando chateas con un agente que utiliza la herramienta get_order_status.

1. Escribes algo como “encuentra mis pedidos de la semana pasada” a un agente con la página de la tienda abierta, en lenguaje sencillo.
2. El agente ejecuta la búsqueda llamando a getTools() en la página.
3. La página devuelve su lista de herramientas con sus esquemas, incluyendo get_order_status junto con su descripción y formato de entrada.
4. El agente compara tu solicitud con las descripciones. Una descripción clara le ayuda a elegir la herramienta adecuada de inmediato.
5. El agente llama a executeTool() con argumentos generados a partir de la conversación, como {timeframe: 'last_7_days'}.
6. La función execute de la página llama al mismo endpoint de Laravel mediante fetch(), tal como ocurriría si se hiciera clic en un botón.
7. El backend responde con JSON, y la herramienta se lo devuelve al agente.
8. El agente formula el resultado en lenguaje natural y lo muestra, mientras todo permanece visible en la interfaz de la página.

¿Por qué es esto mejor que la activación?

• Requiere menos contexto. El agente lee un esquema compacto, no miles de líneas de marcado, por lo que las respuestas son más rápidas y económicas.
• Los resultados son consistentes. La herramienta llama a tu función real, así que cambiar el color de un botón o mover un elemento no la daña.
• Las personas mantienen el control. Las acciones de alto riesgo marcadas con consequentialHint: true siguen necesitando una confirmación, por lo que un agente no puede actuar sin ser solicitado.
• Es más fácil auditarlo. Cada interacción pasa por una herramienta explícita, por lo que puedes registrar con exactitud lo que un agente hizo por un usuario, lo cual es mucho más difícil cuando se trata solo de hacer clics al azar.

Seguridad

Dado que las herramientas se encuentran en tus páginas, la seguridad está más cerca de la superficie que con MCP en el backend, que generalmente se ejecuta de forma aislada en su propio servidor. La especificación cuenta con varias medidas de protección:

• Aislamiento de origen. WebMCP solo funciona en documentos con aislamiento de origen. Si una página habilita document.domain, por ejemplo a través del encabezado Origin-Agent-Cluster: ?0, WebMCP se desactiva.
• Política de permisos. El registro de herramientas está controlado por la política tools, cuyo valor predeterminado es self; por lo tanto, los iframes entre orígenes no pueden registrar herramientas a menos que se permita con allow="tools".
• Exposición de origen. Para que una herramienta sea accesible desde otro origen, incluya ese origen en la opción exposedTo. Nada se expone automáticamente.
• Tres indicaciones de anotación. readOnlyHint, consequentialHint y untrustedContentHint son más que etiquetas. Indican si un agente puede ejecutar una herramienta sin confirmación, o si debe tratar su salida con cuidado porque contiene contenido no confiable como reseñas de usuarios, que podrían presentar inyección de comandos.

Una advertencia honesta: el aislamiento entre pestañas aún está en desarrollo. Si un agente funciona en dos pestañas, nada impide que el contexto sensible se filtre de una a otra. En flujos de alta confianza como los bancarios, observe esta área antes de confiar en esta función.

Estado del soporte en los navegadores

A mediados de 2026 todavía es temprano:

• El Grupo Comunitario de Aprendizaje Automático en la Web del W3C aceptó formalmente la especificación en septiembre de 2025.
• Chrome cuenta con una prueba de origen desde la versión 149, y se prevé soporte nativo en Chrome y Edge para la segunda mitad de 2026.
• Para experimentos locales, la bandera chrome://flags/#enable-webmcp-testing funciona sin necesidad de unirse a la prueba.
• La extensión Model Context Tool Inspector muestra qué herramientas registra una página y puede simular una conversación con un agente.

La propuesta aún puede cambiar, así que no dependa de ella para una función de producción. Utilice el enfoque de mejora progresiva. Donde el navegador soporte WebMCP, los agentes tendrán una experiencia más precisa, y donde no lo haga, el flujo manual seguirá funcionando como antes.

Límites actuales

• Sin navegación sin interfaz gráfica. La API está dirigida a flujos de trabajo de navegadores locales con una persona involucrada, no a automatización sin supervisión.
• Carga adicional en interfaces complejas. Una aplicación con una gestión de estado intrincada probablemente necesitará ser refactorizada para que las herramientas reflejen el estado real de la aplicación.
• El descubrimiento requiere una visita. Los clientes solo saben que un sitio cuenta con herramientas al visitar la página. Aún no existe un índice global como un mapa del sitio para las herramientas.
• Aún no hay recursos ni indicaciones. Otras dos primitivas del MCP completo aún no han llegado a WebMCP. Si un agente debe leer documentos o obtener datos estructurados de otro lugar, sigue siendo necesario un servidor MCP separado.

Por dónde empezar

WebMCP complementa a MCP de backend y no lo reemplaza. MCP de backend sigue siendo adecuado para los datos y la lógica que deben residir en un servidor, mientras que WebMCP se adapta a la capa de interacción del frontend: formularios complejos, navegación multi-paso y acciones vinculadas al estado de la interfaz que se muestra en pantalla.

Una forma segura de comenzar:

• Activar la marca local y registrar una herramienta simple, idealmente de solo lectura como una búsqueda de productos.
• Usar annotations correctamente desde el primer día. No posponer readOnlyHint y consequentialHint, ya que constituyen la base de seguridad que determina hasta qué punto se puede confiar en un agente para utilizar su herramienta.
• Siguir el repositorio del Grupo Comunitario de Aprendizaje Automático en la Web en GitHub, ya que las discusiones de la comunidad siguen dando forma a las especificaciones.

WebMCP está lejos de estar maduro, pero la dirección es clara. La web está adquiriendo un lenguaje explícito para comunicarse con los agentes, un contrato claro entre el desarrollador y el agente en lugar de tener que adivinar mediante el DOM. Para quienes están acostumbrados a las herramientas y esquemas del MCP backend, este cambio les resultará familiar. Ahora el contrato simplemente se encuentra en el navegador.