Exponer las acciones de tu sitio a los agentes de IA con WebMCP

WebMCP invierte la dirección del Model Context Protocol. En lugar de que un agente se conecte hacia un servidor que tú alojas, tu página registra sus propias herramientas en JavaScript con document.modelContext.registerTool(), y un agente que ya tiene la página abierta invoca directamente esas acciones declaradas, en vez de navegar a ciegas por tu interfaz haciendo clics y adivinando el propósito de tus campos de formulario.

Si ya has conectado un servidor MCP a un agente de programación, el modelo del lado del servidor te resultará familiar: un proceso, un transporte, una lista de herramientas, un cliente que se conecta. El caso del navegador es el incómodo. El tráfico de agentes llega a una página renderizada con una sesión iniciada, y hasta ahora la única vía era la actuación: leer el DOM, inferir qué hacen los botones y confiar en que el paso de checkout no se vuelva a renderizar a mitad del clic.

Este artículo cubre los mecanismos que importan a quien tiene a su cargo una aplicación real: cómo es un registro de herramienta correcto, qué cambian realmente las tres anotaciones (hints) en el comportamiento del agente, dónde se ejecutan hoy las herramientas de sitio y cuál es la consecuencia de seguridad de que una herramienta se ejecute dentro de la sesión autenticada del usuario.

La inversión: ¿qué hace diferente a WebMCP?

Un servidor MCP del lado del servidor es algo a lo que un agente se conecta, configurado una vez y accesible con independencia de cualquier página abierta. WebMCP funciona al revés. La documentación de site tools de OpenAI marca la diferencia en dónde residen las herramientas. MCP apunta una aplicación de IA hacia un servidor, local o remoto, que vive fuera de la página y funciona haya o no un navegador abierto. Un sitio con WebMCP entrega sus propias capacidades como un conjunto de herramientas listo para usar que el agente encuentra al llegar, y el usuario no tiene nada que instalar.

La ganancia es la precisión. La documentación de WebMCP de Chrome plantea la diferencia en términos de quién decide qué significa un control: con una herramienta, el sitio lo dice de forma explícita, y al agente no le queda nada por deducir. La actuación le deja una cadena de pasos y una decisión de criterio en cada uno. Un agente que invoca search_orders({ status: "open" }) contra un esquema que tú escribiste no puede equivocarse de opción en un desplegable de filtros, ni puede romperse porque hayas renombrado una clase CSS.

¿Cómo se registra una herramienta con document.modelContext.registerTool()?

El registro de una herramienta recibe un objeto con name, description e inputSchema; la referencia de la API imperativa de Chrome trata esos tres como campos obligatorios, y annotations junto con una función execute aportan el comportamiento. Comprueba la disponibilidad de la característica antes de llamarla, exactamente como hace el propio ejemplo de OpenAI, porque la API todavía no está presente en la mayoría de los navegadores.

async function registerAgentTools() {
  if (typeof document.modelContext?.registerTool !== "function") return;

  await document.modelContext.registerTool({
    name: "list_orders",
    description:
      "List the signed-in customer's orders, newest first, optionally filtered by fulfilment status. Returns order number, placed date, status and total.",
    inputSchema: {
      type: "object",
      properties: {
        status: {
          type: "string",
          enum: ["open", "shipped", "delivered", "cancelled"],
          description: "Fulfilment status to filter by. Omit for all orders.",
        },
        limit: {
          type: "integer",
          minimum: 1,
          maximum: 20,
          description: "Maximum orders to return. Defaults to 10.",
        },
      },
      required: [],
      additionalProperties: false,
    },
    annotations: { readOnlyHint: true },
    // Same function the orders table calls. The API still checks the session.
    execute: async ({ status, limit = 10 }) => fetchOrders({ status, limit }),
  });
}

La descripción es lo único que lee el modelo al decidir si esta herramienta encaja con la solicitud, así que pesa tanto como el código que hay detrás. Nombra la forma del valor de retorno, nombra el filtro y di qué no cubre la herramienta.

Fíjate en lo que hace execute aquí: delega. La herramienta llama a la misma función de obtención de datos que llama la UI, y el servidor que hay detrás aplica la misma autorización que ya aplica. Las recomendaciones de OpenAI dirigen a los desarrolladores hacia su autenticación y autorización existentes en lugar de a una vía paralela, y la razón de ingeniería es evidente: dos rutas de código hacia la misma capacidad acabarán divergiendo, y la que no tiene una UI delante es precisamente la que nadie nota cuando se desvía.

¿Qué cambian las tres anotaciones?

Las anotaciones son metadatos que indican a un agente cómo tratar una herramienta antes de invocarla. Chrome documenta tres, y la guía de seguridad de herramientas de Chrome replantea cada una en términos del riesgo que señala.

Configúralas herramienta por herramienta, de forma deliberada. Una herramienta cancel_subscription sin consequentialHint es una herramienta que un agente puede disparar sin detenerse, y una herramienta que obtiene reseñas sin untrustedContentHint entrega al modelo un bloque de texto escrito por desconocidos sin ninguna marca.

¿Dónde se ejecuta WebMCP hoy?

La página de site tools de OpenAI detalla dónde honrará ChatGPT una herramienta registrada: en el navegador integrado de la aplicación de escritorio de ChatGPT, mantenida actualizada, donde ChatGPT Work y Codex pueden encontrar e invocar lo que ofrezca la página. El modelo también importa: GPT-5.6 Sol y GPT-5.6 Terra están soportados y WebMCP está deshabilitado en GPT-5.6 Luna. Los espacios de trabajo Enterprise y Edu quedan fuera, y que la función aparezca o no sigue dependiendo del despliegue progresivo y de lo que registre la página abierta. Una flecha en la barra de direcciones lista las herramientas que ofrece una página, y toda la función se puede desactivar desde los permisos del navegador.

La implementación de Chrome sigue siendo una preview. Chrome documenta WebMCP detrás del flag chrome://flags/#enable-webmcp-testing para desarrollo local, activándolo y reiniciando el navegador, junto con una prueba de origen (origin trial) a la que puedes unirte desde Chrome 149. No está activado por defecto en la versión estable, y las declaraciones de soporte de ambos proveedores cambian, así que consulta las páginas originales antes de lanzar algo que dependa de ellas.

Lo que el navegador de ChatGPT no admite

La documentación de OpenAI es clara en que el navegador integrado cubre solo una parte de WebMCP, y señala dos carencias. Las herramientas definidas mediante atributos de formularios HTML no se convierten en site tools, y las herramientas registradas dentro de un iframe no se descubren, incluidos los iframes del mismo origen. La instrucción práctica es breve: registra de forma imperativa, en el documento de nivel superior, y no dependas de nada exótico.

Esa restricción de los iframes es de ChatGPT, no del estándar. Chrome sitúa ambas APIs detrás de la Permissions Policy tools, cuyo valor inicial es self. Con ese valor por defecto, el documento de nivel superior y los frames del mismo origen pueden registrar herramientas, y un iframe de origen cruzado no. Un widget embebido en otro origen puede registrar herramientas si al frame se le concede la política tools, si la herramienta pasa exposedTo con la lista de orígenes autorizados y si quien la invoca pasa fromOrigins a getTools(). Chrome además limita WebMCP a documentos aislados por origen, de modo que una página que use document.domain no obtiene API alguna.

Tu herramienta se ejecuta como el usuario autenticado

Una herramienta registrada se ejecuta dentro de la página en vivo bajo la sesión autenticada del usuario, lo que significa que cada capacidad que expongas es una capacidad que un agente puede ejercer con la autoridad de ese usuario. La pregunta de alcance no es qué sería cómodo automatizar. Es qué aceptarías que se invocara sin un clic.

La guía de seguridad de Chrome es inusualmente directa sobre por qué esto importa. Un modelo toma instrucciones y datos como una única secuencia continua de tokens, sin ninguna frontera entre ambos. La seguridad no puede garantizarse dentro de algo probabilístico. La inyección de prompts ya ha funcionado, de forma reproducible, contra sistemas de agentes que ejecutan los mejores modelos disponibles, y el número de este tipo de ataques en la web no deja de crecer. OpenAI dice algo muy parecido sobre las propias herramientas: en su documentación de site tools, tanto las definiciones de herramientas de un sitio web como los resultados que devuelven cuentan como contenido no confiable.

De ahí se derivan tres controles concretos. La visibilidad de las herramientas parte cerrada, ya que otros sitios e iframes de origen cruzado no pueden ver tus herramientas hasta que nombres sus orígenes en exposedTo; aplica el mismo cuidado a las herramientas de solo lectura que revelan datos de usuario que a las de escritura. Chrome también señala una vía de acceso que tú no abriste: las extensiones pueden consultar y ejecutar tus herramientas desde un content script, y una que tenga host_permission para tu sitio ya puede, en cualquier caso, ejecutar su propio JavaScript en la página. Y mantén los textos breves. Chrome recomienda 500 caracteres para la descripción de una herramienta, 150 por descripción de parámetro, 30 para nombres de herramientas y parámetros, y 1,5 K por salida de herramienta, describiendo las cuatro cifras como recomendaciones que pueden cambiar con la retroalimentación del ecosistema y que más adelante podrían formalizarse. El trabajo sobre gestión del consentimiento continúa, incluido un requestUserInteraction() en borrador de especificación para preguntar algo al usuario a mitad de la ejecución, que aún no se ha publicado.

WebMCP no es una jugada de SEO

Registrar site tools cambia lo que un agente puede hacer una vez que llega a tu página. No hace nada para que llegue. La propia lista de limitaciones de Chrome nombra la descubribilidad de herramientas como un problema abierto: un cliente o un navegador solo descubre que un sitio tiene herramientas invocables si va hasta allí. No hay rastreo, ni índice, ni feed de herramientas registradas. Leída junto con ese mecanismo, la conclusión es directa, aunque es nuestra lectura y no una declaración del proveedor: WebMCP es una superficie de ruta de conversión, no una palanca de posicionamiento o de citación, y tratar la descripción de una herramienta como texto de meta description es malinterpretar quién la lee.

Elige una acción que tus usuarios ya completen en tu sitio, regístrala primero como de solo lectura y dedica el trabajo real a la descripción y al esquema. Ahí es donde un agente entiende tu aplicación o no la entiende, y es la parte que ningún despliegue de navegador va a resolver por ti.

Preguntas frecuentes

¿Cómo doy de baja una herramienta WebMCP cuando el usuario navega fuera de la página?

No existe un método unregisterTool. Pasa un AbortSignal en el objeto de opciones de document.modelContext.registerTool y aborta ese controlador cuando la herramienta deje de ser aplicable, por ejemplo al desmontar un componente o en un cambio de ruta en una SPA. Las buenas prácticas de Chrome lo plantean en términos del estado de la página: registra una herramienta mientras sea útil y dala de baja cuando deje de serlo. Vincular el abort a tus transiciones de página es la forma práctica de hacerlo, y evita que una herramienta obsoleta persista o choque con un nuevo registro del mismo nombre. Los agentes observan el cambio mediante el evento toolchange en document.modelContext.

¿Cuál es la diferencia entre las APIs declarativa e imperativa de WebMCP?

La API declarativa convierte un formulario HTML existente en una herramienta: añade los atributos toolname y tooldescription al elemento form, más toolparamdescription en campos concretos, y el navegador deriva una representación estructurada a partir del formulario. Eliminar cualquiera de esos atributos da de baja la herramienta. La API imperativa, document.modelContext.registerTool, encaja mejor con herramientas dinámicas y lógica compleja. El navegador integrado de ChatGPT solo admite la vía imperativa.

¿Hay soporte de React o Angular para registrar herramientas WebMCP?

Ambos existen y ambos son experimentales. Chrome Labs mantiene el hook useWebMCP en el paquete use-webmcp-tool, que registra una herramienta al montar, la da de baja al desmontar, requiere React 18 o posterior y se degrada a un no-op donde la API no está presente. Angular expone provideExperimentalWebMcpTools desde su paquete core, ligando la vida de la herramienta a un injector, y recomienda ubicarlo en los providers de ruta o de aplicación.

¿Valida el navegador los argumentos que pasa un agente frente a mi inputSchema?

No des por hecho que lo haga. Trata la entrada que llega a execute como no validada y verifícala en código antes de actuar sobre ella. La guía de WebMCP de Chrome indica a los desarrolladores que validen las restricciones y devuelvan errores descriptivos para que el agente pueda reintentar, y Angular afirma con claridad que no comprueba los argumentos suministrados por el agente frente al esquema JSON que declaraste. Las comprobaciones de autorización del lado del servidor siguen aplicándose por encima de todo esto.