Tutorial de WebMCP: Cómo crear sitios web preparados para los agentes con el nuevo estándar de Chrome

Ahora mismo, los agentes de IA navegan por Internet como un turista que lee un menú en un idioma que no conoce: entrecerrando los ojos para ver los píxeles, adivinando para qué sirven los botones y esperando que la página no cambie de diseño justo cuando están haciendo clic. Google y Microsoft decidieron que valía la pena resolver el problema de verdad.

En febrero de 2026, Chrome 146 lanzó una primera versión preliminar de WebMCP, un estándar web propuesto que permite a los sitios web indicar a los agentes exactamente qué pueden hacer y cómo hacerlo. 

Se acabó el screen scraping. 

Se acabó el tener que hacer ingeniería inversa con el DOM.

En este tutorial, quiero explicarte qué es realmente WebMCP, cómo configurar tu entorno y, a continuación, crear integraciones que funcionen utilizando tanto el enfoque basado en HTML como el basado en JavaScript. 

También te daré algunos consejos de seguridad para manejar las invocaciones de agentes, además de cómo probarlo todo con las herramientas de depuración de Chrome.

¿Qué es WebMCP?

WebMCP (Web Model Context Protocol) es un nuevo estándar para navegadores que permite a los sitios web declarar sus capacidades como herramientas estructuradas a las que los agentes de IA pueden recurrir directamente. En lugar de obligar a una IA a «leer» y hacer clic en una interfaz visual, WebMCP convierte la propia página web en una API limpia del lado del cliente.

Pensemos en lo que pasa cuando un agente intenta reservar un vuelo en una página web de viajes hoy en día. Tiene que averiguar en qué campo se introduce la ciudad de salida, adivinar si el formato de la fecha es MM/DD o AAAA-MM-DD, encontrar el botón de búsqueda y esperar que la página no se actualice con un diseño que nunca haya visto antes. Si, en cambio, la web pudiera publicar una herramienta llamadasearchFlights con parámetros específicos para el origen, el destino, las fechas y el número de pasajeros, ya no habría que andarse con conjeturas.

WebMCP lo hace posible. Un sitio registra herramientas a través de una API de navegador llamada navigator.modelContext, en la que cada herramienta incluye un nombre, una descripción en lenguaje natural y un esquema JSON para sus entradas y salidas. El agente detecta esas herramientas, envía parámetros que se ajustan al esquema y recibe a cambio datos estructurados.

Los ingenieros de Google y Microsoft elaboraron la especificación conjuntamente en el marco del grupo comunitario «Web Machine Learning» del W3C. La arquitectura es totalmente del lado del cliente, lo que la diferencia de las implementaciones típicas de MCP, en las que un servidor backend independiente se encarga de ejecutar las herramientas. Mientras que el MCP estándar conecta a los agentes con los servidores de fondo a través de JSON-RPC, WebMCP lo mantiene todo en la pestaña del navegador. 

Las herramientas se ejecutan en el JavaScript de la página; comparten la sesión que ya tenga el usuario, y el navegador controla lo que el agente puede hacer. Si ya has trabajado con servidores MCP (por ejemplo, en nuestro tutorial sobre el Protocolo de Contexto de Modelos MCP), los conceptos de registro de herramientas te resultarán familiares, pero el modelo de implementación es bastante diferente.

Características y funciones principales de WebMCP

Hay dos API disponibles, y cada una tiene una finalidad diferente:

• La API declarativa funciona mediante anotaciones HTML. Añades los tooldescriptionatributostoolname y al
• La API de Imperative te ofrece un control programático total. Llamas a la funciónnavigator.modelContext.registerTool()y defines el nombre de la herramienta, la descripción, el esquema de entrada y unaexecutefunción de devolución de llamada. Esta es la opción ideal para todo aquello que sea demasiado dinámico para un formulario sencillo: flujos de trabajo de varios pasos, llamadas a la API, resultados calculados y lógica de validación personalizada.

Ambas API permiten el registro dinámico, lo que significa que las herramientas pueden aparecer y desaparecer a medida que cambia el estado de la página. Antes de que un usuario inicie sesión, quizá solo quieras mostrar unaloginherramienta. Una vez iniciada la sesión, se registran las herramientas específicas de la cuenta.

• Los esquemas JSON de cada herramienta especifican los tipos, las enumeraciones, los campos obligatorios y las descripciones de los parámetros. Esta estructura es la que evita que los agentes se inventen valores de parámetros o introduzcan datos en los campos equivocados.
• Las pseudoclases CSS proporcionan información visual durante las interacciones con el agente. Chrome se aplica:tool-form-activea cualquier formulario que un agente esté rellenando en ese momento y:tool-submit-activeal botón de envío de ese formulario. La persona que mira la pantalla puede ver exactamente en qué formulario está trabajando el agente.

Todavía no hay ningún mecanismo de detección integrado. Un agente tiene que visitar tu página para saber qué herramientas ofreces. El equipo de Chrome ha barajado la idea de un archivo.well-known/webmcp de manifiesto que permita detectar el contenido antes de visitar la página, pero aún no se ha concretado nada al respecto.

Como WebMCP todavía está en fase de vista previa inicial, es normal que haya algunos fallos y cambios continuos, sobre todo porque la especificación ya ha ido evolucionando a lo largo de las distintas versiones, incluyendo la eliminación de los provideContextmétodos clearContexty en marzo de 2026. 

La visibilidad de las herramientas se limita a las páginas que ya has visitado, y aunque en la especificación se reconocen problemas de seguridad como la inyección de mensajes y la filtración de datos a través del encadenamiento de herramientas, aún no se han resuelto por completo. Puedes consultar el registro de cambios en la documentación de Chrome antes de empezar, ya que es posible que la interfaz de la API haya cambiado desde que se escribió este tutorial.

Requisitos previos y configuración del entorno de WebMCP

Preparar el entorno te llevará unos minutos, aunque si usas una versión incorrecta de Chrome perderás mucho más tiempo que eso.

Se necesita Chrome Canary versión 146.0.7672.0 o superior. Los canales Estable, Beta y Dev de Chrome no incluyen la opción WebMCP. Varios programadores han comentado en los foros de Chrome que instalaron la versión equivocada y se pasaron un buen rato preguntándose por qué no aparecía la opción. Descárgalo directamente desde la página de Canary.

Página de descarga de Chrome Canary

Además del navegador, necesitas tener conocimientos prácticos sobre formularios HTML y el manejo de eventos en JavaScript. Si necesitas repasar, el curso «Introducción a JavaScript» de DataCamp repasa los conceptos básicos. 

La extensión «Model Context Tool Inspector» no es estrictamente necesaria, pero vale la pena instalarla. Muestra todas las herramientas registradas en la página actual, te permite ejecutarlas manualmente con los parámetros que introduzcas y cuenta con compatibilidad integrada con la API de Gemini para probar la invocación de herramientas mediante lenguaje natural.

Activar la opción experimental WebMCP

Si tienes instalado Chrome Canary:

1. Escribechrome://flags/#enable-webmcp-testing en la barra de direcciones.
2. Activa la opción «WebMCP para pruebas» Habilitado.
3. Haz clic Reiniciar en la parte inferior de la página.

La página chrome://flags con la opción WebMCP resaltada y activada

Después de reiniciar la página, abre DevTools (F12), ve a la pestaña «Consola» y ejecuta:

console.log(navigator.modelContext);

La consola de DevTools muestra el objeto `navigator.modelContext`.

La presencia de un objeto en la salida (en lugar de undefined) confirma que la API está disponible. Desde aquí, puedes instalar la extensión Model Context Tool Inspector y abrir la demostración de viajes de Google para ver cómo funciona el registro de herramientas en una página real. 

Una vez allí, solo tienes que abrir la extensión y deberías ver algo parecido a esto:

Comprobación de las herramientas de searchFlights mediante la extensión Model Context Tool Inspector de Chrome con la sitio web de demostración de búsqueda de vuelos de Google. 

Como puedes ver, el Inspector de herramientas de contexto del modelo detecta la herramienta searchFlights y muestra su esquema de entrada, lo que permite al modelo comprender mucho mejor cómo interactuar con la página.

Cómo crear tu primera integración con WebMCP

Hay dos formas de crear tu primera integración con WebMCP, y te las explicamos en las secciones siguientes:

El enfoque declarativo (HTML)

La forma más sencilla de registrar una herramienta WebMCP es añadir anotaciones a un formulario que ya exista en tu página. Aquí tienes un formulario estándar de búsqueda de productos sin anotaciones de WebMCP:

<form action="/search" method="GET">
  <label for="query">Search term</label>
  <input type="text" name="query" id="query" required>

  <label for="category">Category</label>
  <select name="category" id="category">
    <option value="all">All categories</option>
    <option value="electronics">Electronics</option>
    <option value="books">Books</option>
    <option value="clothing">Clothing</option>
  </select>

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

Hay cuatro atributos que hacen que esta herramienta pueda ser llamada por un agente. Los atributos «toolname» y «tooldescription» se incluyen en la propia etiqueta <form>. En los campos individuales, «toolparamtitle» y «toolparamdescription» sustituyen a las etiquetas predeterminadas cuando estas no son lo suficientemente descriptivas como para que un agente las entienda:

<form toolname="search_products"
      tooldescription="Search the product catalog by keyword and optional category filter"
      action="/search" method="GET">

  <label for="query">Search term</label>
  <input type="text" name="query" id="query" required
         toolparamdescription="The keyword or phrase to search for in product titles and descriptions">

  <label for="category">Category</label>
  <select name="category" id="category"
          toolparamtitle="Product Category"
          toolparamdescription="Filter results to a specific product category. Use 'all' for no filter.">
    <option value="all">All categories</option>
    <option value="electronics">Electronics</option>
    <option value="books">Books</option>
    <option value="clothing">Clothing</option>
  </select>

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

Lo que hace el navegador con esos atributos es generar un esquema JSON internamente. El nombre de la herramienta, los tipos de parámetros, los valores de la enumeración de las opciones <select> y los marcadores de obligatoriedad del HTML se transfieren sin necesidad de ninguna configuración adicional.

Para probarlo, crea un archivo .html sencillo en tu ordenador con cualquier editor de texto, pega el código anterior y ábrelo en Chrome usando file:///{tu_ruta_del_archivo.html}; para que la extensión funcione con el archivo local, también tienes que abrir la configuración de la extensión, ir a «Detalles» y habilitar el acceso a las URL de los archivos, tal y como se muestra en la captura de pantalla de abajo.

Permitir que la extensión acceda a los archivos locales.

De lo contrario, tu navegador no podrá interactuar con tu archivo HTML local. Una vez hecho esto, si abres el archivo con Chrome y activas la extensión WebMCP, deberías ver algo parecido a la siguiente captura de pantalla. 

La extensión que muestra el esquema generado para la herramienta search_products tras añadir las anotaciones.

¿Qué pasa realmente cuando un agente llama a esta herramienta? 

Chrome abre el formulario, rellena los campos con los valores que haya introducido el agente y ahí se queda. El usuario aún tiene que hacer clic en «Enviar». Esa configuración predeterminada está pensada así, porque el usuario debe confirmar la acción antes de que se lleve a cabo.

Si añades eltoolautosubmitatributo a la etiqueta del formulario, se elimina ese paso de confirmación. Tiene sentido para operaciones de solo lectura, como las consultas de búsqueda. Si algo modifica datos, activa una compra o cambia la configuración de la cuenta, no lo actives.

También hay una forma de realizar el intercepto del envío y devolver un resultado estructurado al agente. El método `respondWith()` del evento `submit` toma una promesa, y lo que le asignes como valor de resolución se convierte en la salida de la herramienta:

<form toolname="search_products"
      tooldescription="Search the product catalog"
      toolautosubmit
      action="/search">
  <input type="text" name="query" required>
  <button type="submit">Search</button>
</form>

<script>
  document.querySelector("form").addEventListener("submit", (e) => {
    e.preventDefault();

    const query = new FormData(e.target).get("query");

    if (!query || query.trim().length === 0) {
      if (e.agentInvoked) {
        e.respondWith(Promise.resolve({
          error: "Search query cannot be empty. Please provide a keyword."
        }));
      }
      return;
    }

    const results = performSearch(query);

    if (e.agentInvoked) {
      e.respondWith(Promise.resolve({
        content: [{ type: "text", text: JSON.stringify(results) }]
      }));
    }
  });
</script>

El valor booleano «agentInvoked» del evento «submit» es «true» cuando un agente ha activado el envío y «false» en el caso de un clic normal de un usuario. Puedes usarlo para alternar entre el formato de respuesta específico del agente y tu gestión habitual de formularios.

Cuando no hay ningún atributo «toolparamdescription» en un campo, el navegador toma la descripción del elemento <label> asociado o, en su defecto, del atributo «aria-description». Así que el marcado accesible ya ofrece descripciones razonables de los parámetros sin necesidad de ningún trabajo adicional.

Una peculiaridad actual: en un grupo de elementos <input type="radio">, el atributo «toolparamdescription» debe ir en el primer botón de radio del grupo, y se aplica a todo el parámetro.

El enfoque imperativo (JavaScript)

Los formularios abarcan muchos aspectos, pero hay algunas herramientas que necesitan interactuar con el estado de la aplicación, realizar llamadas a la API o devolver resultados calculados que no se corresponden con el envío tradicional de un formulario. Aquí tienes una herramienta básica para añadir elementos a una lista de tareas pendientes:

window.navigator.modelContext.registerTool({
  name: "addTodo",
  description: "Add a new item to the user's to-do list. Use when the user asks to create, add, or remember a task.",
  inputSchema: {
    type: "object",
    properties: {
      text: {
        type: "string",
        description: "The task description"
      },
      priority: {
        type: "string",
        enum: ["low", "medium", "high"],
        description: "Task priority level. Default to 'medium' if not specified by the user."
      }
    },
    required: ["text"]
  },
  execute: ({ text, priority = "medium" }) => {
    const newItem = { id: Date.now(), text, priority, done: false };
    todoApp.addItem(newItem);
    todoApp.renderList();

    return {
      content: [{
        type: "text",
        text: Added task: "${text}" with ${priority} priority. The to-do list now has ${todoApp.getCount()} items.
      }]
    };
  }
});

La función de devolución de llamada «execute» recibe los parámetros que ha enviado el agente (que deben coincidir con el «inputSchema»), ejecuta la lógica de tu aplicación y devuelve un arreglo de contenido. 

Un detalle importante: actualiza la interfaz de usuario antes de volver. 

A veces, los agentes comprueban cómo se ve la página después de llamar a una herramienta para asegurarse de que ha funcionado, así que, si la interfaz de usuario aún no ha cambiado, el agente puede pensar que la llamada ha fallado. Puedes registrar y dar de baja herramientas a medida que cambia el estado de la página:

function onUserLogin(user) {
  navigator.modelContext.registerTool({
    name: "viewOrderHistory",
    description: "Show the user's past orders with dates and totals",
    inputSchema: {
      type: "object",
      properties: {
        limit: {
          type: "number",
          description: "Maximum number of orders to return. Defaults to 10."
        }
      }
    },
    execute: async ({ limit = 10 }) => {
      const orders = await fetchOrders(user.id, limit);
      return {
        content: [{ type: "text", text: JSON.stringify(orders) }]
      };
    }
  });
}

function onUserLogout() {
  navigator.modelContext.unregisterTool("viewOrderHistory");
}

Un ejemplo más realista: una página para reservar mesa en un restaurante que comprueba la disponibilidad. Este ejemplo también muestra la validación en el código, algo que recomienda la documentación de Chrome, ya que las restricciones del esquema son útiles para los agentes, pero no todos las aplican.

navigator.modelContext.registerTool({
  name: "checkAvailability",
  description: "Check table availability for a given date and party size at this restaurant. Returns available time slots.",
  inputSchema: {
    type: "object",
    properties: {
      date: {
        type: "string",
        description: "The desired reservation date in YYYY-MM-DD format"
      },
      partySize: {
        type: "number",
        description: "Number of guests, between 1 and 12"
      }
    },
    required: ["date", "partySize"]
  },
  execute: async ({ date, partySize }) => {
    if (partySize < 1 || partySize > 12) {
      return {
        content: [{
          type: "text",
          text: "Party size must be between 1 and 12. For larger groups, please call the restaurant directly at (555) 123-4567."
        }]
      };
    }

    const parsedDate = new Date(date);
    if (isNaN(parsedDate.getTime()) || parsedDate < new Date()) {
      return {
        content: [{
          type: "text",
          text: "Please provide a valid future date in YYYY-MM-DD format."
        }]
      };
    }

    const slots = await api.getAvailableSlots(date, partySize);
    renderAvailabilityCalendar(date, slots);

    return {
      content: [{
        type: "text",
        text: JSON.stringify({
          date,
          partySize,
          availableSlots: slots.map(s => s.time),
          message: slots.length > 0
            ? Found ${slots.length} available time slots.
            : "No availability for this date. Try a different date or smaller party."
        })
      }]
    };
  }
});

Vale la pena destacar algunos puntos de la documentación de Chrome. Acepta la entrada del usuario sin procesar siempre que sea posible. Si alguien dice «de las 11:00 a las 15:00», tu herramienta debería aceptar esas cadenas tal cual, en lugar de obligar al agente a convertirlas a minutos desde la medianoche o a cualquier otro formato interno. 

Valida en el código, no solo en el esquema, porque la aplicación del esquema varía según el agente. Y no salgas hasta que se haya actualizado la interfaz de usuario, ya que los agentes pueden consultar la página para confirmar que la operación se ha realizado correctamente.

Si buscas herramientas MCP del lado del servidor que complementen una implementación de WebMCP del lado del cliente, nuestra guía sobre la creación de servidores MCP con FastMCP explica la configuración al detalle.

Gestión de la invocación de agentes y la seguridad en WebMCP

La especificación WebMCP da por hecho que hay una persona mirando. Los desarrolladores de Google y Microsoft lo diseñaron pensando en flujos de trabajo cooperativos, no en un funcionamiento autónomo. Los mecanismos que se describen a continuación reflejan esa filosofía.

Distinguir entre usuarios de IA y usuarios humanos

En laSubmitEventinterfaz aparece una nueva propiedad booleana llamada agentInvoked. Cuando un agente activa el envío de un formulario, la propiedad toma el valor «true». Cuando alguien hace clic en «Enviar» de forma normal, el valor es «false».

document.querySelector("form").addEventListener("submit", (e) => {
  if (e.agentInvoked) {
    console.log("AI agent submitted the form");
    if (!isWithinAgentRateLimit()) {
      e.preventDefault();
      e.respondWith(Promise.resolve({
        error: "Too many requests. Please wait before trying again."
      }));
      return;
    }
  }
});

Además del envío de formularios, hay dos eventos a nivel de ventana que registran la actividad del agente.toolactivatedSe activa cuando un agente abre una herramienta y Chrome rellena automáticamente los campos del formulario correspondientes.toolcancelSe activa si el usuario cancela la operación o restablece el formulario. 

Ninguno de los dos eventos se puede cancelar, pero ambos tienen unatoolNamepropiedad que te permite saber qué herramienta se ha utilizado.

window.addEventListener("toolactivated", ({ toolName }) => {
  showAgentActivityBanner(toolName);
});

window.addEventListener("toolcancel", ({ toolName }) => {
  hideAgentActivityBanner();
});

Aplicación de los permisos de intervención humana

Con las herramientas declarativas, lo normal es que el usuario tenga que hacer clic en «Enviar» después de que el agente haya rellenado los campos. Esa configuración predeterminada debería mantenerse para todo lo que tenga consecuencias reales.

Eltoolautosubmitatributo elimina ese paso. Es para herramientas de solo lectura o de bajo riesgo: consultas de búsqueda, comprobaciones de disponibilidad, comprobaciones de estado. 

Cualquier acción que cree, modifique o elimine datos debería requerir un clic manual.

Puedes personalizar el estado de interacción del agente con pseudoclases CSS:

form:tool-form-active {
  border: 2px solid #2563eb;
  background-color: #eff6ff;
  font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre;white-space:pre-wrap;">1rem;
  border-radius: 8px;
}

form:tool-form-active::before {
  content: "AI agent is filling this form";
  display: block;
  font-size: 0.875rem;
  color: #2563eb;
  font-weight: 600;
  font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre;white-space:pre-wrap;">0.5rem;
}

Un formulario al que se le ha aplicado el estilo :tool-form-active, que muestra el borde azul y la etiqueta «El agente de IA está rellenando este formulario».

Las herramientas imperativas plantean un reto diferente. No hay ningún formulario ni botón de enviar, así que la ejecución se inicia de inmediato cuando el agente llama a la herramienta. 

Para cualquier operación que no deba realizarse sin la aprobación de una persona, tienes que integrar la confirmación directamente en la propia herramienta:

navigator.modelContext.registerTool({
  name: "deleteAccount",
  description: "Permanently delete the user's account and all associated data. Cannot be undone.",
  inputSchema: {
    type: "object",
    properties: {
      confirmPhrase: {
        type: "string",
        description: "The user must type 'DELETE MY ACCOUNT' to confirm."
      }
    },
    required: ["confirmPhrase"]
  },
  execute: ({ confirmPhrase }) => {
    if (confirmPhrase !== "DELETE MY ACCOUNT") {
      return {
        content: [{
          type: "text",
          text: "Confirmation phrase does not match. Ask the user to confirm explicitly."
        }]
      };
    }

    return new Promise((resolve) => {
      showConfirmationModal("Are you sure?", {
        onConfirm: async () => {
          await api.deleteAccount();
          resolve({ content: [{ type: "text", text: "Account deleted." }] });
        },
        onCancel: () => {
          resolve({ content: [{ type: "text", text: "Deletion cancelled by user." }] });
        }
      });
    });
  }
});

La dinámica en todo el ecosistema MCP es siempre la misma: el agente expresa su intención y la persona confirma la ejecución. Para tener una visión más amplia de cómo funciona esto en las distintas implementaciones de MCP, echa un vistazo a nuestra descripción general de los principales servidores y clientes de MCP.

Cómo probar tu implementación de WebMCP

Una vez que tengas tu primera integración de WebMCP en funcionamiento, es hora de probarla. 

Cómo usar el simulador de agentes de Chrome DevTools

Una vez instalada la extensión Model Context Tool Inspector, una pequeña insignia en su icono te indica cuántas herramientas tiene registradas la página actual. Al abrir la ventana emergente, se muestran todas las herramientas con su nombre, descripción y esquema de entrada. Si una herramienta que has registrado no aparece aquí, significa que el registro no se ha realizado correctamente.

El panel de extensiones muestra una lista de varias herramientas registradas con sus esquemas desplegados.

Para probar el simulador de agentes, volvamos a la página web de demostración de búsqueda de vuelos de Google. Ahora podemos probar cómo ejecutar esta aplicación, ya sea manualmente o mediante lenguaje natural. 

Método de ejecución manual

La ejecución manual elimina el elemento no determinista de las pruebas de agentes. Selecciona una herramienta en el menú desplegable del panel de extensiones, escribe un objeto JSON en el campo «Argumentos de entrada» y haz clic en «Ejecutar herramienta». La extensión ejecuta la herramienta directamente con los parámetros que hayas indicado.

La extensión con la herramienta «searchFlights» seleccionada, los parámetros JSON rellenados y el botón «Ejecutar herramienta» visible.

Esto resulta muy útil para identificar los problemas. Cuando una herramienta funciona correctamente con parámetros introducidos manualmente, pero falla cuando el agente la ejecuta, sabes que el problema está en la descripción o el esquema de la herramienta, no en la función de ejecución. Por ejemplo, usando la demostración de viajes de Google:

{
  "origin": "LON",
  "destination": "NYC",
  "tripType": "round-trip",
  "outboundDate": "2026-06-10",
  "inboundDate": "2026-06-17",
  "passengers": 2
}

La página de demostración de viajes que muestra los resultados de la búsqueda tras ejecutar la herramienta manualmente.

Pruebas de lenguaje natural

Las pruebas de lenguaje natural utilizan la API de Gemini. Pega una clave de AI Studio en la configuración de la extensión y, a continuación, escribe una instrucción como 

Search for round-trip flights from London to New York leaving June 10th, returning June 17th, for 2 passengers.

La extensión envía esa solicitud a Gemini 2.5 Flash junto con tus definiciones de herramientas, y el modelo decide qué herramienta ejecutar y qué parámetros pasar.

El campo de entrada de lenguaje natural de la extensión con una solicitud escrita y, debajo, la respuesta del agente al ejecutar la herramienta.

Si el agente elige la herramienta equivocada o configura mal los parámetros, es probable que las descripciones de tus herramientas deban ser más específicas. Las buenas descripciones explican lo que hace la herramienta en términos positivos («usa esto para comprobar la disponibilidad de vuelos»), no para qué no se debe usar.

Una secuencia de pruebas práctica:

1. Comprueba que las herramientas aparezcan en la extensión una vez que se haya cargado la página.
2. Ejecuta cada herramienta manualmente con los parámetros correctos. Comprueba que la lógica de ejecución funciona y que la interfaz de usuario se actualiza como se espera.
3. Ejecutar con parámetros incorrectos. Asegúrate de que tu validación detecte los errores y de que los mensajes sean lo suficientemente claros como para que el agente pueda corregirlos por sí mismo.
4. Prueba con lenguaje natural. Comprueba si el agente elige la herramienta adecuada y asigna correctamente las palabras del usuario a los parámetros del esquema.
5. Prueba los casos extremos: usuarios sin autenticar, formularios desactivados, interrupciones en el servicio de la API y llamadas rápidas y repetidas.

Si quieres conocer el contexto de las herramientas de MCP dentro del ecosistema de Google en concreto, nuestro tutorial sobre servidores MCP de Google aborda varios patrones relevantes. Y si quieres tener una visión más amplia del panorama de los protocolos más allá de Chrome, echa un vistazo a «Los mejores servidores MCP remotos».

Conclusión

WebMCP ofrece a los sitios web un canal de comunicación directo con agentes de IA. En lugar de que los agentes tengan que adivinar cómo funciona una página, el sitio publica definiciones estructuradas de las herramientas, y el agente las invoca con parámetros específicos. La API declarativa convierte los formularios existentes en herramientas a las que los agentes pueden acceder con solo unos pocos atributos HTML. La API de imperativos abarca todo lo que es más complejo. El modelo de seguridad permite que seas tú quien controle las acciones que realmente importan.

La especificación aún está en una fase temprana, solo está disponible en Chrome Canary activándola mediante un indicador, y no es apta para uso en producción. Pero el hecho de que tanto Google como Microsoft lo estén elaborando conjuntamente, con el W3C a cargo de la supervisión, sugiere que tiene muchas posibilidades de convertirse en un estándar web estable. Si te familiarizas con la API ahora, ya conocerás los patrones de diseño y los mecanismos de seguridad de la herramienta cuando salga la versión estable.

Si quieres empezar a prepararte ya, revisa los formularios de tus sitios web actuales e identifica cuáles se beneficiarían más del acceso de los agentes. Los formularios de búsqueda y los verificadores de disponibilidad son puntos de partida de bajo riesgo. Cuando te hayas familiarizado con la API declarativa de esas herramientas, pasa a las herramientas imperativas para los flujos de trabajo que requieran lógica personalizada. 

Si quieres seguir profundizando en el tema, te recomiendo:

• Tutorial sobre el Protocolo de Contexto del Modelo MCP sobre los conceptos básicos de WebMCP.
• Creación de servidores MCP con FastMCP para herramientas MCP del lado del servidor que complementan WebMCP del lado del cliente.
• Tutorial de Google MCP Servers sobre patrones de integración específicos de Google.
• Los mejores servidores MCP remotos y Los mejores servidores y clientes MCP para el ecosistema en general.