Google está probando WebMCP (Web Model Context Protocol), una propuesta de estándar web que permite a una página publicar herramientas estructuradas para que los agentes de inteligencia artificial sepan qué pueden hacer y cómo hacerlo. En vez de obligar a un agente a interpretar botones, recorrer el DOM o simular clics, una web puede declarar acciones como buscar productos, rellenar formularios, consultar pedidos o iniciar una reserva mediante interfaces diseñadas para ser entendidas por máquinas. La propuesta está todavía en fase experimental y no debe confundirse con el Model Context Protocol (MCP) convencional.
Las claves de WebMCP en 30 segundos
- Google presentó WebMCP en 2026 como una propuesta de estándar abierto para agentes que operan dentro del navegador.
- Las webs pueden exponer herramientas mediante JavaScript o anotando formularios HTML existentes.
- La API imperativa utiliza actualmente
document.modelContext.registerTool(). - La declarativa convierte formularios en herramientas con atributos como
toolnameytooldescription. - WebMCP no sustituye a MCP: el primero está pensado para el frontend y el segundo conecta agentes con sistemas y herramientas externas.
La idea parte de un problema que empieza a ser habitual. Los sitios web llevan décadas diseñándose para que una persona vea una interfaz, interprete sus controles y actúe sobre ella. Un agente puede intentar hacer lo mismo mediante visión artificial, accesibilidad, análisis del HTML o automatización del navegador, pero cada paso añade una oportunidad para equivocarse.
Supóngase que alguien pide a un agente:
Busca un hotel en Tokio para dos personas, compara las opciones y enséñame las tres mejores antes de reservar.
Sin una interfaz específica para agentes, el sistema tendría que localizar el buscador, comprender cada campo, introducir las fechas, seleccionar el número de huéspedes, ejecutar la consulta e interpretar posteriormente los resultados.
WebMCP propone que la propia página declare algo equivalente a:
search_hotels
location: Tokyo
check_in: ...
check_out: ...guests: 2
El agente ya no necesita deducir primero qué hace cada elemento de la interfaz. La web le ofrece explícitamente sus capacidades.
El frontend empieza a tener una segunda interfaz: la que utilizan las máquinas
WebMCP introduce dos formas de exponer esas herramientas.
La primera es una API imperativa, basada en JavaScript, pensada para operaciones más dinámicas o complejas.
La documentación actual de Chrome utiliza document.modelContext. Esto es importante porque algunos ejemplos que circulan todavía muestran navigator.modelContext, una interfaz que Chrome ha deprecado a partir de Chrome 150.
Un ejemplo simplificado sería:
await document.modelContext.registerTool({
name: "get_order_status",
description: "Consulta el estado de un pedido",
inputSchema: {
type: "object",
properties: {
orderId: { type: "string" }
},
required: ["orderId"]
},
execute: async ({ orderId }) => {
return await getOrderStatus(orderId);
}
});
La herramienta tiene un nombre, una descripción, un esquema de entrada y una función que realmente ejecuta el trabajo.
Un agente compatible puede descubrirla y saber que existe sin inspeccionar cada botón de la página.
La API también permite obtener las herramientas disponibles mediante:
document.modelContext.getTools()
y ejecutarlas manualmente con:
document.modelContext.executeTool()
Además pueden registrarse y retirarse dinámicamente dependiendo del estado de la aplicación.
Un formulario HTML también puede convertirse en una herramienta
La segunda opción es posiblemente más interesante para webs existentes porque requiere menos JavaScript.
La API declarativa permite anotar formularios HTML convencionales.
La sintaxis actual utiliza toolname y tooldescription:
<form
toolname="createSupportRequest"
tooldescription="Envía una solicitud al servicio de soporte"
>
<label for="email">Email</label>
<input id="email" name="email" type="email">
<label for="message">Problema</label>
<textarea id="message" name="message"></textarea>
<button type="submit">Enviar</button>
</form>
El navegador transforma ese formulario en una representación estructurada que un agente puede descubrir y utilizar.
Los campos pueden incorporar además toolparamdescription para explicar con mayor precisión qué representa cada parámetro.
Esto significa que una web no necesita desarrollar necesariamente una nueva API paralela para que un agente pueda interactuar con una parte de la interfaz.
Puede convertir determinados formularios existentes en herramientas.
Google plantea precisamente WebMCP como una mejora progresiva: la web sigue funcionando para humanos, pero adquiere una capa adicional que los agentes pueden interpretar de forma más fiable.
WebMCP no es MCP ejecutándose en el navegador
El nombre puede llevar fácilmente a confusión.
MCP, Model Context Protocol, se ha extendido como mecanismo para conectar modelos y agentes con herramientas, bases de datos, repositorios, servicios empresariales y API.
WebMCP comparte parte de esa filosofía, pero no es una implementación del servidor MCP dentro de JavaScript.
Google establece una separación bastante clara. MCP está orientado a sistemas y herramientas que pueden existir independientemente de una página web. WebMCP funciona dentro de la propia página y proporciona capacidades al agente integrado en el navegador.
Puede visualizarse aproximadamente así:
MCP
Agente
↓Servidor MCP
↓CRM / base de datos / GitHub / ERP / API
Frente a:
WebMCP
Agente del navegador
↓Web abierta actualmente
↓Herramientas registradas por esa página
WebMCP tampoco reproduce todos los conceptos de MCP. La documentación de Google lo describe como un conjunto de API inspirado en MCP y centrado actualmente en herramientas, sin elementos equivalentes a todos los recursos o prompts disponibles en el protocolo de backend.
Ambos pueden utilizarse juntos.
Una tienda podría emplear WebMCP para que el agente controle su interfaz y MCP internamente para acceder al inventario, CRM o sistemas empresariales.
Un comercio electrónico podría dejar de depender de los clics
El comercio electrónico es uno de los ejemplos más evidentes.
Una tienda podría declarar herramientas como:
search_products()
get_product_details()
add_to_cart()
apply_coupon()
checkout()
El usuario podría pedir:
Encuentra unas zapatillas de running por menos de 120 euros, talla 43, que puedan llegar antes del viernes.
Actualmente un agente tiene que navegar por la interfaz e interpretar cada paso.
Con herramientas estructuradas podría consultar directamente las funciones que la propia tienda ofrece.
Eso no significa necesariamente que el usuario desaparezca de la ecuación. Especialmente en una compra, sería razonable mantener confirmaciones antes de ejecutar acciones con consecuencias económicas.
Google insiste precisamente en que las herramientas WebMCP funcionan dentro de un contexto visible de navegador. La propuesta no está diseñada para que un agente opere de forma completamente invisible como un servicio backend.
Las aplicaciones SaaS son otro candidato evidente
Un panel empresarial puede acumular decenas de pantallas para realizar tareas relativamente simples.
Por ejemplo:
generate_report()
invite_member()
export_csv()
create_invoice()
change_subscription()
En vez de enseñar al agente dónde está cada menú, el desarrollador podría ofrecer esas capacidades como herramientas.
Lo mismo puede aplicarse a CRM:
create_lead()
assign_sales_rep()
schedule_follow_up()
o soporte:
find_order()
open_ticket()
request_refund()
El cambio conceptual para los desarrolladores frontend es importante.
Hasta ahora una gran parte del trabajo consistía en construir una interfaz para humanos.
WebMCP añade otra audiencia:
humanos y agentes.
Eso puede hacer que nombres, esquemas, semántica y comportamiento de las herramientas sean tan importantes como la experiencia visual.
No basta con exponer cada botón como una herramienta
Google recomienda evitar traducir literalmente toda la interfaz en cientos de funciones.
Una herramienta debería corresponder a una acción clara y suficientemente diferenciada. Los nombres deben indicar qué hace y las descripciones tienen que permitir al agente decidir cuándo utilizarla.
Por ejemplo:
doTask()
es una mala herramienta.
submit_expense_claim()
da bastante más información.
También importa evitar solapamientos. Si existen cuatro herramientas que aparentemente hacen casi lo mismo, el agente tendrá más posibilidades de seleccionar la equivocada.
Google recomienda además controlar cuándo se registra cada herramienta. Una función que únicamente tiene sentido después de iniciar sesión o seleccionar un producto no tiene por qué estar disponible durante toda la navegación.
Los esquemas de entrada son otro elemento importante.
Cuanto más pueda encargarse la aplicación de normalizar los datos, menos razonamiento innecesario se obliga a hacer al modelo.
El ahorro no es solo de clics, también puede ser de tokens
Existe otra consecuencia potencial.
Cuando un agente debe analizar una página completa para descubrir cómo actuar, necesita procesar información sobre HTML, árbol de accesibilidad, texto visible, estructura y estado.
Una herramienta estructurada puede ofrecer una representación mucho más compacta:
search_products(query, max_price, size)
en lugar de obligar al modelo a interpretar centenares de elementos.
Google presenta entre las ventajas de WebMCP una mayor velocidad, fiabilidad y precisión respecto a la actuación directa sobre el DOM. Todavía es pronto para convertir esa mejora en porcentajes universales porque dependerá del agente, la web y la tarea.
Pero la dirección es relevante: menos interpretación visual y más contratos explícitos entre la aplicación y el agente.
La seguridad es probablemente el problema más importante
Dar a un agente una lista estructurada de herramientas también amplía su capacidad para actuar.
Y eso convierte la seguridad en una parte esencial del diseño.
Google identifica dos riesgos particularmente relevantes: manifiestos maliciosos y resultados contaminados.
Una web podría intentar registrar una herramienta cuya descripción contenga instrucciones diseñadas para manipular al agente.
También una herramienta aparentemente legítima podría devolver contenido generado por usuarios que incluya una prompt injection.
El problema se agrava porque el agente puede estar actuando dentro de una sesión autenticada.
No es lo mismo que un chatbot lea una página maliciosa a que un agente conectado a la cuenta del usuario pueda además comprar, eliminar, publicar o transferir información.
La documentación de Chrome recomienda limitar interacciones entre orígenes, tratar el contenido externo como no confiable y solicitar confirmación humana cuando la herramienta modifica estado.
WebMCP incluye además anotaciones como:
readOnlyHint
untrustedContentHint
La primera ayuda a indicar que una herramienta solo consulta información. La segunda señala que la respuesta puede contener contenido externo que debería tratarse con mayor precaución.
La API también está sujeta a aislamiento de origen y a una Permissions Policy específica para tools. Por defecto, los iframes de origen cruzado no pueden acceder automáticamente a estas capacidades.
WebMCP sigue siendo experimental
El entusiasmo alrededor de la propuesta no debería ocultar su estado real.
WebMCP no es actualmente un estándar web consolidado y desplegado universalmente.
Google lo define como una propuesta de estándar en discusión activa. Chrome abrió una prueba de origen a partir de Chrome 149 y permite probarlo localmente mediante una flag experimental.
Para desarrollo local puede activarse en:
chrome://flags/#enable-webmcp-testing
y reiniciar posteriormente Chrome.
Chrome DevTools 149 incorporó además herramientas experimentales para inspeccionar los WebMCP registrados, revisar sus esquemas, ejecutar llamadas manuales y comprobar resultados.
Google ha empezado también a incluir comprobaciones relacionadas con WebMCP dentro de sus herramientas para evaluar la preparación de una web para navegación agéntica.
Eso muestra que la compañía está dedicando recursos reales al proyecto, pero la API todavía puede cambiar.
De hecho, ya lo ha hecho: ejemplos tempranos utilizaban navigator.modelContext; la documentación actual exige document.modelContext.
Es precisamente el tipo de cambio que cabe esperar de una tecnología todavía experimental.
La web para agentes no sustituirá necesariamente a la web para humanos
La interpretación más extrema sería imaginar páginas sin botones porque los agentes harán todo.
WebMCP apunta a algo menos radical y probablemente más realista.
Las interfaces humanas seguirán existiendo. La propia especificación busca que las herramientas actúen sobre una página visible y mantengan al usuario dentro de la experiencia del sitio.
La diferencia es que la misma aplicación podría ofrecer simultáneamente:
Interfaz visual
para personas
y:
Interfaz estructurada
para agentes
Algo parecido ocurrió con la accesibilidad o los datos estructurados: una parte de la semántica de una página empezó a tener valor más allá de lo que se veía en pantalla.
Si los agentes de navegador ganan adopción, WebMCP puede llevar esa idea bastante más lejos.
Los desarrolladores ya no diseñarían únicamente cómo debe verse una tarea.
También tendrían que decidir cómo debe ser entendida y ejecutada por una máquina.
WebMCP todavía puede cambiar de forma, encontrar alternativas o no terminar convertido en el estándar dominante. Pero el problema que intenta resolver difícilmente va a desaparecer.
Si cada vez más usuarios delegan tareas en agentes, las webs tendrán que elegir entre dejar que esos agentes interpreten interfaces creadas para personas o proporcionarles una forma estructurada de descubrir qué pueden hacer.
WebMCP es uno de los primeros intentos serios de convertir esa segunda opción en una capacidad nativa del navegador.
Preguntas frecuentes
¿Qué es WebMCP?
WebMCP es una propuesta de estándar web impulsada en Chrome para que las páginas puedan exponer herramientas estructuradas a agentes de IA que operan dentro del navegador.
¿WebMCP sustituirá a MCP?
No. Google los presenta como tecnologías complementarias. MCP conecta agentes con sistemas y herramientas externas, mientras WebMCP está diseñado específicamente para que un agente comprenda y utilice funciones de la página web abierta.
¿Cómo se crea una herramienta WebMCP?
Puede registrarse mediante JavaScript con document.modelContext.registerTool() o declarativamente anotando formularios HTML mediante atributos como toolname y tooldescription.
¿WebMCP ya puede utilizarse en producción?
La tecnología sigue siendo experimental. Chrome abrió una prueba de origen a partir de Chrome 149 y ofrece opciones de desarrollo local, pero Google advierte de que la propuesta continúa en discusión y puede cambiar.
