Explicación de WebMCP: Permitiendo que los sitios web publiquen herramientas en lugar de que los agentes hagan clic en las interfaces de usuario.

Imagínese un pequeño proyecto secundario en el que un agente de IA debe operar una aplicación web por sí solo. La primera versión funciona como lo hacen la mayoría de los agentes de navegador: el agente obtiene acceso a la aplicación y procesa la información a partir de lo que muestra la página. En el caso de una aplicación básica de tareas, la solicitud podría ser “Añadir ‘Comprar huevos’ a mi lista”. Para llevarla a cabo, el agente debe inspeccionar la página, encontrar el cuadro de entrada, determinar qué botón envía el formulario, hacer clic en él y luego verificar el resultado.

Funciona, pero parece requerir un esfuerzo excesivo. La aplicación ya sabe con precisión qué debe suceder. Hay una función detrás de ese botón, una API detrás de esa función, y la operación en sí consiste en una sola llamada clara:

add_todo(title)

Entonces, ¿por qué debería el agente mirar fijamente la interfaz e intentar adivinar cómo hacer algo que la aplicación ya puede describir? Ahí es donde WebMCP comienza a tener sentido. El flujo se vuelve algo así:

User request
     ↓
AI agent
     ↓
WebMCP tool
     ↓
Application logic
     ↓
UI updates

La interfaz sigue estando presente para los visitantes humanos. El agente simplemente no necesita decodificarla para llevar a cabo una acción. Eso cambia la forma en que se aborda todo el problema. La pregunta podría no ser cómo hacer que la IA sea mejor para usar sitios web, sino cómo hacer que los sitios web sean mejores para indicarle a la IA qué pueden hacer.

Dos formas en que los agentes utilizan la web hoy en día, y dónde falla cada una

Un agente que necesita actuar en un sitio actualmente cuenta con dos métodos comunes.

El primero es la automatización del navegador. El agente toma capturas de pantalla, determina qué elementos son interactivos, mueve el cursor, rellena campos, hace clics, verifica qué ocurrió y repite el proceso. Es similar a observar a alguien usar un navegador, y presenta las mismas debilidades: es lento, consume muchos recursos y se rompe fácilmente. Un pequeño cambio en el diseño, un menú oculto, una interacción que solo funciona al pasar el cursor o un flujo con un paso adicional pueden desviar al agente de su objetivo.

La segunda opción es un servidor MCP personalizado creado para su aplicación. Para las herramientas, eso ofrece una experiencia mucho mejor. El costo se manifiesta en otro aspecto, ya que el agente debe saber que el servidor existe y conectarse a él primero. Cuando cada sitio web incluye su propia integración a medida, esto no es escalable. Este es el límite práctico del enfoque MCP personalizado.

Eso deja un vacío: la automatización del navegador es demasiado indirecta, y las integraciones personalizadas son demasiado manuales. WebMCP busca llenar ese espacio intermedio.

Qué es realmente WebMCP

En términos sencillos, WebMCP permite que un sitio web le indique a un agente de IA: “Estas son las acciones que puede realizar en esta página”. En lugar de que el agente se pregunte qué botón presionar, el sitio le proporciona una lista de acciones disponibles.

Una tienda en línea, por ejemplo, podría publicar herramientas como estas:

search_products()
get_product_details()
add_to_cart()

Un agente que navega por el sitio encuentra las herramientas por sí mismo y las llama con los datos estructurados que cada una indica. No es necesario registrar nada dentro del agente con antelación. Las herramientas se descubren dinámicamente desde el sitio web, y ese es el aspecto que merece atención. Un sitio deja de ser simplemente un conjunto de páginas y comienza a ofrecer funcionalidades.

Un ejemplo concreto: la aplicación Todo

Tomemos una aplicación Todo sencilla. Sin WebMCP, un agente tendría que inspeccionar la página, encontrar el campo de entrada, escribir el texto, localizar el botón Añadir, hacer clic en él y volver a leer la interfaz actualizada.

Con WebMCP, la aplicación puede publicar cuatro herramientas:

add_todo(title)
list_todos()
toggle_todo(id)
delete_todo(id)

El agente ya no necesita conocer el diseño visual. Sabe qué puede hacer la aplicación. Una demostración construida exactamente de esta manera mostró una aplicación de tareas que expuso cuatro herramientas, con un agente conectado que leyó sus esquemas e invocó inmediatamente add_TODO. Al indicarle al agente que agregara “Tengo que comprar huevos” a la lista, se activó la llamada a la herramienta y el nuevo elemento apareció en la aplicación.

El modelo mental es mucho más claro: la interfaz de usuario está destinada a los humanos, las herramientas a los agentes, y ambos operan en la misma aplicación.

Así es la definición de una herramienta

Aquí los ingenieros front-end lo encontrarán interesante. La implementación en esa demostración registra las herramientas a través de navigator.modelContext. Cada herramienta consta de un par de componentes:

{
  name: "add_todo",
  description: "Add a todo item",
  inputSchema: {
    // structured inputs
  },
  execute: async (input) => {
    // application logic
  }
}

La estructura es constante: un nombre, una descripción, un esquema de entrada y una función ejecutora que realiza el trabajo, generalmente llamando a las APIs de backend que ya tiene la aplicación. Este último punto es importante. WebMCP no exige que se reescriba la lógica de negocio para la IA. La aplicación existente sigue siendo el sistema que lleva a cabo la operación, y el agente simplemente obtiene una forma estructurada de activarla.

El problema de la autenticación

Las cosas se vuelven serias cuando la aplicación deja de ser un juguete. Imagine herramientas como estas:

get_profile()
update_profile()
create_order()
cancel_order()
transfer_money()

Un agente desconocido no debería poder invocar esas funciones libremente. Una segunda demostración en el mismo material aborda exactamente este problema mediante OAuth. Las herramientas WebMCP operan sobre una aplicación autenticada, y los usuarios que no se hayan conectado no pueden ejecutar las acciones protegidas.

Esto es importante porque los agentes provienen de todo tipo de clientes: un navegador con funcionalidades de IA, un agente de escritorio o otra aplicación agente. Un mecanismo estándar como OAuth hace que la capa de capacidades sea mucho más fácil de proteger en todos ellos, en comparación con tener que crear un proceso de inicio de sesión para cada integración. Una vez que los sitios exponen capacidades a los agentes, la autenticación se convierte en parte de la experiencia del agente desde el primer día y no en un parche añadido posteriormente.

Una nueva pregunta para el diseño frontend

Durante años, la arquitectura frontend ha girado en torno a una cadena: interfaz, estado, API, backend. WebMCP añade otra pregunta: ¿qué capacidades debería exponer esta aplicación a un agente?

Parece algo menor, pero podría cambiar la forma en que se diseñan las funcionalidades. Un botón de “Añadir al carrito” es una interacción humana. Esta llamada, en cambio, representa una capacidad de la aplicación:

add_to_cart(productId, quantity)

Tanto uno como el otro podrían diseñarse juntos eventualmente. Las personas obtienen una interfaz pulida, los agentes cuentan con una interfaz de capacidades estructurada, y ambos terminan dentro de la misma lógica de negocio.

No se trata solo de velocidad

Hay una razón más profunda por la que esto es importante que la simple rapidez de los agentes. Cuando un agente funciona a través de capturas de pantalla y clics, la propia interfaz constituye el contrato, y cualquier cambio en ella puede dañar al agente. Con WebMCP, la definición de la herramienta pasa a formar parte del contrato.

Esto introduce un nuevo conjunto de elementos dentro del ámbito de trabajo del desarrollador frontend: nombres de herramientas, descripciones, esquemas de entrada, comportamiento de ejecución y límites de autenticación. El trabajo deja de centrarse únicamente en el diseño de pantallas para incluir también el diseño de cómo el software se presenta ante los sistemas inteligentes.

Todavía en sus inicios

Hay una advertencia importante que merece ser destacada. WebMCP sigue siendo una propuesta en fase de prueba preliminar y no un estándar web establecido. La demostración se realizó en Chrome Beta con WebMCP activado a través de las opciones del navegador, y el presentador afirmó claramente que la API aún podría cambiar. Reconstruir la arquitectura de producción en torno a ella ahora sería prematuro. Experimentar con ella es otra cuestión, ya que la idea subyacente es más amplia que la API actual.

Durante décadas, los sitios web se han construido sobre una única premisa: existe una persona al otro lado. WebMCP es uno de los primeros experimentos que desafían esa premisa. Las aplicaciones web pronto podrían tener que responder a dos preguntas: ¿cómo debería usarlo una persona? ¿Y cómo debería usarlo un agente de IA? La primera pregunta dio origen a la ingeniería moderna de interfaces de usuario. La segunda podría determinar qué vendrá a continuación.

Leer más

• Explicación de WebMCP: Proporcionar herramientas a los agentes de IA del navegador en lugar de conjeturas — WebMCP permite a una página web declarar herramientas para los agentes de IA. Cómo registrarlas, anotar los riesgos, probarlas en Chrome y gestionar la seguridad, además del estado del soporte en los navegadores en 2026.
• Playwright o agentes de navegador? Donde la automatización por scripts sigue siendo la mejor opción — Una comparación entre los scripts de Playwright y los agentes de navegador impulsados por MCP: fragilidad, determinismo, costo, una tarea de facturación realizada, herramientas a vigilar, riesgos de seguridad y un marco de toma de decisiones.