WebMCP: expone las herramientas del sitio web para que los agentes dejen de escanear el DOM

Los sitios web se diseñaron para los clics humanos, los formularios y las APIs. Cada vez más, el “usuario” puede ser un agente de IA que nunca interactúa con la interfaz visual. Los agentes que extraen datos del árbol DOM o controlan navegadores fallan cuando cambia el marcado. WebMCP (Web Model Context Protocol), propuesto en el ecosistema de Chrome, tiene como objetivo permitir que los sitios expongan herramientas estructuradas directamente a los agentes: nombres, entradas, salidas y cuándo llamarlas, de modo que la automatización sea explícita en lugar de inferida.

¿Qué es WebMCP?

En resumen, WebMCP permite que una página publique herramientas dirigidas a los agentes en lugar de depender de que los extractores adivinen correctamente.

Sin WebMCP, un agente debe improvisar frente a una interfaz opaca:

AI Agent → Reads HTML → Guesses → Clicks → Hopes it works

Con WebMCP, la misma intención se convierte en una llamada a herramienta declarada:

AI Agent → Reads structured tools → Executes correctly

La documentación de Chrome presenta las ventajas como velocidad, fiabilidad y precisión en las interacciones con agentes.

Por qué existe WebMCP

Considere reservar un hotel. El camino frágil abre una página, busca los campos de entrada, interpreta las fechas, hace clic en buscar y analiza los resultados; resulta vulnerable ante cambios en el DOM. Con WebMCP, el agente invoca una operación estructurada:

searchHotels({
 location: "Tokyo",
 checkIn: "2026-08-10",
 checkOut: "2026-08-15",
 guests: 2
})

Ninguna arqueología con XPath, ninguna ruleta de selectores CSS, ni desvíos visuales para flujos rutinarios: solo ejecución directa al escribir las instrucciones.

Cómo funciona WebMCP

Dos APIs complementarias:

1. API imperativa

JavaScript registra las herramientas de forma explícita:

navigator.webMCP.registerTool({
  name: "create-event",
  description: "Creates a calendar event",
  inputSchema: {
    type: "object",
    properties: {
      title: { type: "string" },
      date: { type: "string" }
    }
  },
  execute: async ({ title, date }) => {
    return await createCalendarEvent(title, date);
  }
});

Los agentes reciben el nombre de la herramienta, su propósito, los campos de entrada requeridos y una ruta de ejecución; la lógica del frontend se exporta como capacidades llamables.

2. API declarativa

Enfoque en HTML, especialmente para formularios:

<form webmcp-tool="book-flight">
  <input name="from" />
  <input name="to" />
  <input name="date" />
</form>

El entorno de ejecución convierte el formulario en una herramienta estructurada, permitiendo que las aplicaciones existentes se vuelvan compatibles con agentes mediante pequeños cambios en el marcado.

WebMCP frente a MCP

La confusión es común. Una distinción práctica: WebMCP está orientado a la interfaz de usuario; MCP, en cambio, se dirige a los sistemas y servicios backend. Un modelo mental posible es considerar a MCP como el “cerebro” del lado del servidor y a WebMCP como el “cuerpo” de la interfaz. Juntos, abarcan las herramientas para agentes full-stack sin obligar a realizar cada acción mediante una automatización del navegador frágil.

Casos de uso en el mundo real

1. Comercio electrónico

Un comprador solicita zapatillas de deporte dentro de un presupuesto determinado y desea realizar el pago. Las herramientas que podrían utilizarse incluyen:

searchProducts()
filterProducts()
addToCart()
applyCoupon()
checkout()

El agente completa el proceso sin necesidad de navegar por tableros o grids.

2. Reservas de viajes

Búsqueda de vuelos, comparación de hoteles, reserva de transporte terrestre, adición de seguro: todo a través de herramientas, no de macros frágiles.

3. Paneles de control SaaS

Las pantallas de análisis pueden mostrar operaciones como:

generateReport()
downloadCSV()
inviteMember()
changeBillingPlan()

Los copilotos integrados en la aplicación luego invocan las mismas funcionalidades que los usuarios ven como botones.

4. Sistemas CRM

En lugar de diez pantallas llenas de clics:

createLead()
assignSalesRep()
scheduleFollowUp()

5. Atención al cliente

Cancelar suscripciones, solicitar reembolsos y rastrear envíos mediante herramientas verificadas en lugar de métodos obsoletos basados en HTML.

Por qué deberían importarle a los desarrolladores

El trabajo en el frontend pasa de “dibujar píxeles” a “publicar herramientas para los agentes”. Las responsabilidades se centran en nombres claros, esquemas sólidos y una ejecución fiable. El diseño de funcionalidades antes y después se parece menos a:

Build components for humans

y más a:

Build components for humans + machines

Buenas prácticas

Mantener las herramientas para un único propósito

Evite operaciones que abarcan demasiadas tareas:

manageEverything()

Prefiera herramientas especializadas:

createInvoice()
sendInvoice()
downloadInvoice()

La especificidad mejora la precisión de los agentes.

Usar nombres claros

Rótulos opacos:

doTask()

Nombres que revelan la función:

submitExpenseClaim()

Reducir la carga cognitiva

No fuerce al modelo a calcular de antemano lo que la aplicación ya sabe. Evite:

durationInMinutes

Prefiera aceptar entradas en bruto que el backend pueda normalizar:

startTime: "10:00"
endTime: "12:00"

Maneje los fallos de manera adecuada

Los agentes deben intentarlo nuevamente; las herramientas deben ser seguras durante esos intentos repetidos: la idempotencia es importante.

Preocupaciones de seguridad

Si los agentes pueden ejecutar herramientas, la inyección de scripts maliciosos que simulan herramientas legítimas representa un problema de investigación. Las medidas de mitigación a considerar incluyen la validación del origen, la auditoría de registros, los límites de permisos y las confirmaciones por parte del usuario respecto a los efectos secundarios. No confíe ciegamente en los registros.

El panorama general

WebMCP forma parte de una web agente más amplia: los sitios exponen sus capacidades, los agentes las comprenden, las personas delegan tareas y el trabajo se completa más rápido. Los equipos ya crean APIs para desarrolladores; la siguiente etapa son las herramientas para agentes. Los adoptantes tempranos que se pregunten “¿qué partes de esta aplicación deberían convertirse en herramientas de IA?” darán forma a la próxima ola de arquitectura web, de manera similar a cómo REST, GraphQL, WebSockets y los componentes del servidor pasaron de ser algo especializado a la opción por defecto. La tecnología aún está en sus inicios, pero su dirección es difícil de ignorar.

Ruta de adopción para aplicaciones existentes

Comience marcando un formulario o paso de pago de alto valor con la API declarativa, mida el éxito del agente en comparación con el scraper anterior y luego amplíe las herramientas imperativas para flujos que requieran validación personalizada. Mantenga una verificación humana en los pagos y los cambios destructivos en las cuentas hasta que la telemetría demuestre una idempotencia segura. Trate los esquemas de herramientas como APIs públicas: revise sus nombres, versionéelos y rechace las registraciones de scripts no confiables.