Si buscas "WebMCP" hoy vas a encontrar al menos dos cosas que se llaman igual y que no son lo mismo. Una es una librería open source que conecta páginas web con clientes de IA como Claude Desktop. La otra es una propuesta de estándar del W3C, impulsada por Google y Microsoft, que podría cambiar la forma en que los agentes de IA interactúan con tu web.
Este artículo desambigua ambos proyectos y explica qué es el WebMCP del W3C: qué hace, cómo funciona, en qué se diferencia del MCP server-side y qué puedes hacer hoy con él. Si te preguntas qué es la web agéntica, WebMCP es la pieza que convierte tu web de encontrable y citable a directamente operable por agentes.
Qué es WebMCP (y cuál de los dos)
WebMCP (Web Model Context Protocol) es una propuesta de estándar del W3C, desarrollada por Google y Microsoft, que permite a las páginas web declarar herramientas (tools) que los agentes de IA del navegador pueden descubrir y ejecutar directamente, sin necesidad de un servidor intermedio.
Si has intentado buscar información sobre WebMCP y has acabado más confundido que antes, no eres el único. Existen al menos tres proyectos que comparten el nombre o uno parecido, y cada artículo parece hablar de uno distinto sin decirte cuál.
El primero y más relevante es la spec oficial del W3C: el repositorio webmachinelearning/webmcp, desarrollado por ingenieros de Microsoft (Brandon Walderman, Leo Lee, Andrew Nolan) y Google (David Bokan, Khushal Sagar, Hannah Van Opstal) bajo el W3C Web Machine Learning Community Group. Los datos de su repositorio lo respaldan: 2.400 estrellas y 142 forks, con actualizaciones continuas desde su primer Draft Community Group Report del 10 de febrero de 2026 (W3C WebML CG, 2026).
El segundo es la librería JavaScript de Jason McGhee (@jason.today/webmcp, en webmcp.dev): un prototipo independiente que conecta páginas web a clientes MCP externos mediante un widget y un puente WebSocket. El propio McGhee redirige al esfuerzo oficial del W3C en su repositorio.
El tercero que puede confundir es «The Web MCP» de Bright Data: un producto de scraping (extracción automatizada de datos web) que no tiene relación con la spec. Este artículo habla exclusivamente de la spec W3C.
Si llevas tiempo en marketing digital, esto te sonará: ocurrió lo mismo con «MCP» cuando Anthropic lo lanzó y varios proyectos usaban las mismas siglas.
La definición canónica de la spec lo resume así: las páginas que usan WebMCP funcionan como servidores MCP que implementan tools en JavaScript del lado del cliente, en vez de en un backend. En la práctica, tu web le dice al agente exactamente qué puede hacer — solicitar un presupuesto, reservar una demo, filtrar productos — a través de una API del navegador llamada navigator.modelContext.
Para entender WebMCP conviene conocer tres términos de la spec. El Tool Contract es lo que tu página declara que puede hacer: un conjunto de herramientas con nombre, descripción en lenguaje natural y esquema de parámetros.
El Model Context Provider es cada página que registra esos tools. Y Actuation es el patrón anterior que WebMCP reemplaza: el agente simulando clics y pulsaciones sobre tu interfaz, como si fuera un humano.
Un detalle que la propia spec subraya: WebMCP no se limita a agentes de IA. Las tecnologías de accesibilidad (lectores de pantalla, asistentes de voz) también podrán consumir los tool contracts de tu página, lo que lo convierte en una mejora para todos los usuarios.
Una aclaración adicional: WebMCP no es lo mismo que las Chrome AI APIs (Translator, Writer, Detector). Esas APIs exponen capacidades de IA del navegador a las páginas web. WebMCP hace lo contrario: expone capacidades de tu página web al agente de IA del navegador.
Ahora que sabes qué es WebMCP, la pregunta es cómo se compara con el MCP que ya conoces.
MCP server-side vs WebMCP browser-side — complementarios, no sustitutos
MCP y WebMCP resuelven problemas distintos y se complementan. MCP (lanzado por Anthropic en noviembre de 2024) conecta agentes con datos y servicios en el servidor. WebMCP conecta agentes con la interfaz de tu web dentro de la pestaña del navegador, heredando la sesión del usuario.
Tres formas en que un agente puede operar tu web
La conversación sobre agentes e interacción web suele reducirse a «antes y después». En realidad hay tres aproximaciones. Search Engine Land (2026) lo desglosa bien.
La primera es la automatización por capturas de pantalla y DOM: el agente «ve» la página como píxeles, la procesa con un modelo de visión y simula clics. Funciona en cualquier sitio, pero es frágil, lenta y cara en tokens (las unidades de procesamiento que consumen los modelos de IA al analizar contenido).
La segunda son las APIs públicas tradicionales: robustas y rápidas, pero la mayoría de webs no tienen una API pública completa. La tercera es WebMCP: la web declara sus capacidades como herramientas estructuradas y el agente las ejecuta directamente.
Y ahora viene la parte que realmente importa: el coste. Un benchmark comunitario del repositorio WebMCP-org midió una tarea sencilla en 3.801 tokens vía capturas de pantalla frente a 433 vía WebMCP — una reducción del 89%, con una precisión del 97,9-98% (WebMCP-org, 2026).
Es un benchmark de demo, no un estudio auditado: hay que tratarlo como direccional. Pero la dirección es clara.
En el 60% de las webs que hemos auditado en InboundCycle, las IAs mencionan la marca pero citan a terceros (comparadores, agregadores) como fuente (InboundCycle, auditorías GEO, 2026). WebMCP ofrece una vía para que tu web sea no solo mencionable, sino directamente operable por el agente del comprador.
Tabla comparativa MCP vs WebMCP
| Dimensión | MCP (Anthropic, 2024) | WebMCP (W3C CG, 2026) |
|---|---|---|
| Dónde corre | Servidor backend (Python, Node.js) | Pestaña del navegador, JavaScript del cliente |
| Protocolo | JSON-RPC sobre HTTP/stdio | Nativo del navegador (sin protocolo de red) |
| Autenticación | OAuth 2.1 / tokens | Hereda la sesión del usuario (cookies, SSO) |
| Contexto visual | Ninguno — el agente renderiza su propia UI | Compartido — el agente opera dentro de la pestaña abierta |
| Ciclo de vida | El servidor corre continuamente | Los tools existen solo mientras la pestaña está abierta |
| ¿Funciona sin interfaz? | Sí (headless) | No — requiere pestaña o webview |
| Conceptos expuestos | Tools, Resources, Prompts | Solo Tools |
El Non-Goal explícito del repositorio W3C lo deja claro: WebMCP «no es un reemplazo de los protocolos existentes» (W3C WebML CG, 2026). Si quieres entender el Model Context Protocol server-side en profundidad, ese es territorio de otro artículo.
El concepto que vertebra la diferencia es la inversión de control: en lugar de que el agente descubra qué puede hacer tu web mirando la pantalla, tu web le dice al agente qué puede hacer.
La diferencia está clara, pero lo que importa es cómo funciona WebMCP por dentro.
Cómo funciona WebMCP — 4 actores, 2 capas, 1 ciclo
WebMCP funciona como una coreografía entre cuatro participantes que colaboran en tiempo real dentro de la pestaña del navegador. El usuario da la intención, el agente selecciona la herramienta correcta, el navegador media como guardián y la página web ejecuta la lógica y devuelve datos estructurados.
Coreografía de 4 actores + ciclo de vida
El modelo, formalizado por A B Vijay Kumar (2026), tiene cuatro participantes. El usuario da la intención en lenguaje natural («necesito un presupuesto de transporte desde Madrid»). El agente consulta al navegador qué tools hay disponibles, selecciona el correcto y extrae los parámetros.
El navegador actúa como mediador y guardián: no reenvía sin más, presenta al usuario una solicitud de permiso antes de ejecutar. La página web ejecuta el handler y devuelve un JSON estructurado.
Aquí es donde muchos se pierden: sin WebMCP, el agente intenta deducir lo que una web puede hacer a partir de su interfaz visual — como alguien que intenta entender el menú de un restaurante mirando una foto del interior. Con WebMCP, la web le entrega el menú directamente al agente, con nombres de platos, precios e ingredientes.
El ciclo de vida completo tiene cinco fases. En discovery, el agente detecta los tools registrados en la pestaña. En intent mapping, matchea la intención del usuario con la descripción del tool.
En la fase de consent, el navegador pide permiso al usuario si la acción no es de solo lectura. En execution, la página ejecuta la lógica. Y en structured return, devuelve datos en JSON y actualiza su interfaz.
La seguridad está embebida en el diseño, no es una capa aparte. El método requestUserInteraction pausa la ejecución ante acciones irreversibles (comprar, enviar, borrar).
El atributo toolautosubmit viene desactivado por defecto: si no lo activas, el agente rellena los campos pero espera a que el humano pulse «Enviar». Las pseudo-clases CSS :tool-form-active y :tool-submit-active resaltan visualmente un formulario que el agente ha rellenado.
Los tools heredan la sesión del usuario (cookies, SSO, credenciales activas). Esto elimina la necesidad del OAuth que MCP server-side requiere. Si tu usuario ya está logueado, el agente opera con sus credenciales, siempre mediado por el navegador.
Dos vías de implementación — imperativa y declarativa
La API imperativa usa JavaScript. Con navigator.modelContext.registerTool() registras una función que el agente puede invocar, gestionada con AbortSignal para su ciclo de vida.
Requiere HTTPS (SecureContext). Un ejemplo mínimo de Chrome for Developers (2026):
navigator.modelContext.registerTool({
name: "addTodo",
description: "Añade una tarea a la lista del usuario.",
inputSchema: {
type: "object",
properties: {
text: { type: "string", description: "Descripción de la tarea" }
},
required: ["text"]
},
execute: (params) => { /* lógica de la aplicación */ }
});La API declarativa es más sencilla: añades atributos HTML a formularios existentes. toolname define el nombre del tool, tooldescription lo describe en lenguaje natural, toolparamdescription describe cada campo y toolautosubmit (opcional) permite que el agente envíe el formulario sin clic humano.
El navegador construye automáticamente el JSON Schema a partir de los <input> del formulario. Un <form> HTML ya es conceptualmente una declaración de herramienta: la API declarativa solo lo hace explícito.
Codely (2026) captura la práctica emergente: «Todo formulario debería declararse como WebMCP. El coste es muy bajo. La alternativa no es que los agentes no usen tu web, sino que la usen peor.»
Mira este dato: el 94% de los comités de compra B2B ya usan modelos de lenguaje durante la evaluación de proveedores, y el proveedor que ocupa el primer lugar en el shortlist del comprador gana el contrato en el 80% de los casos (6sense, 2025 — estudio publicado por el propio vendor, con una muestra de más de 4.000 compradores). Si el agente de tu comprador no puede operar tu formulario de demo, no entras en ese shortlist.
Arquitectura de dos capas paralelas
WebMCP no cambia la web que tus usuarios ya ven. Añade una segunda capa paralela diseñada para máquinas.
La capa humana (HTML/CSS/JS) sigue exactamente igual: el usuario navega, lee, hace clic. La capa máquina (tool contracts en JSON Schema) aparece al lado, invisible para el humano pero legible para el agente. El navegador es la bisagra entre ambas.
Esto funciona como mejora progresiva: navigator.modelContext simplemente no existe en navegadores sin soporte. Tu sitio con WebMCP no se rompe para usuarios normales.
Conecta directamente con el marco de la web agéntica: una cosa es que el agente pueda leer tu web (agent-readable) y otra que pueda operar sobre ella (agent-actionable). WebMCP materializa la segunda.
Ahora la pregunta práctica: ¿en qué punto está esto hoy?
Estado actual — Chrome 146, Origin Trial 149 y lo que falta
WebMCP es hoy una propuesta experimental disponible solo en Chrome, con una evolución técnica rápida desde febrero de 2026 y un Origin Trial (programa de pruebas públicas de Chrome para funciones experimentales) anunciado en Google I/O 2026 para Chrome 149. No es un estándar W3C todavía — es un Draft Community Group Report, un paso previo al Standards Track.
La cronología relevante para tu decisión empieza en febrero de 2026. El 10 de febrero se publicó el primer Draft y Chrome 146 habilitó el flag (interruptor experimental que activa funciones en pruebas) chrome://flags/#enable-webmcp-testing (Chrome for Developers, 2026).
En abril, Chrome 148 estabilizó el ciclo de vida de los tools con AbortSignal. En mayo, Chrome 149 lanzó el Origin Trial público, anunciado en Google I/O 2026 (Chrome for Developers, 2026). Para mediados-finales de 2026 se espera el anuncio formal de Edge y la transición al W3C Standards Track.
La API ha cambiado varias veces en tres meses: se eliminaron provideContext y clearContext por vulnerabilidades de seguridad, se deprecó unregisterTool en favor de AbortSignal y se formalizó la Permissions Policy tools (por defecto self). Cada cambio endurece la spec — es señal de madurez, no de inestabilidad.
chrome://flags/#enable-webmcp-testingDraft publicado 10 feb 2026
provideContext y clearContext eliminados por vulnerabilidades de seguridadPermissions Policy tools formalizada
Estamos aquí
Las señales de adopción son claras. En Google I/O 2026, seis marcas globales aparecieron como partners comprometidos con WebMCP: Booking.com, Expedia, Instacart, Intuit, Shopify y Redfin (The New Stack, 2026).
Cloudflare (2026) integró soporte WebMCP en Browser Run para orquestación en la nube. Ya hay SDK emergentes (webmcp-react, webmcp-next, WordPress/WooCommerce vía cf-webmcp) y WebMCP funciona en sites estáticos y JAMstack sin infraestructura especial.
Para probar WebMCP hoy fuera de Chrome Canary, existe el polyfill (librería de compatibilidad) @mcp-b/global: un solo script tag que habilita las funcionalidades básicas en cualquier navegador (GitHub MCP-B, 2026).
Esto es justo lo que cambia la perspectiva: las limitaciones de WebMCP son decisiones de diseño conscientes, no defectos. Requiere una pestaña abierta (no funciona en modo headless) y las SPAs complejas pueden necesitar refactorización.
No hay discovery sin visitar la página — una hipótesis de manifiesto .well-known/webmcp existe pero no en la spec. Solo expone Tools, no Resources ni Prompts. Estas restricciones garantizan que el usuario humano siempre esté en el centro.
Ni Mozilla (Firefox) ni Apple (Safari) han anunciado implementación. Microsoft coautoría la spec pero no tiene timeline para Edge stable. Si tu audiencia usa Safari, el polyfill es la vía de momento.
Como matiz de seguridad, el escenario de un agente con acceso simultáneo a pestañas sensibles (banca + email) es un riesgo reconocido que WebMCP mitiga con aislamiento por dominio y consentimiento por invocación. Desde la perspectiva del RGPD, SubmitEvent.agentInvoked permite distinguir si una acción la inició un humano o un agente.
Y aquí viene lo interesante: según datos de InboundCycle obtenidos de 28 auditorías GEO a empresas en España, Chile y Brasil, solo el 27% de las webs tiene llms.txt implementado (InboundCycle, auditorías GEO, 2026). El 36% no tiene datos estructurados de ningún tipo.
Si el mercado no ha dado el paso más básico de discovery para agentes, WebMCP tardará — y eso es precisamente la ventana de oportunidad. Plataformas como Wix ya generan llms.txt automáticamente con endpoint MCP. Es cuestión de tiempo que integren soporte WebMCP nativo.
Ahora, es justo hacerse la pregunta contraria: ¿y si espero a que la spec madure antes de tocar nada? Esperar es razonable si hablamos de apostar el roadmap entero.
Pero anotar formularios con toolname y tooldescription cuesta horas, no semanas, y no rompe nada. El polyfill funciona hoy. El coste de no empezar es perder la ventana de early adopter, cuando los que ya están son Booking.com, Shopify y Expedia.
El horizonte realista: «mediados de 2027 como objetivo realista de adopción masiva» (DEV Community, 2026). Experimentar ahora, no apostar el roadmap todavía.
Todo lo anterior puede sonar a mucho, pero hay tres cosas que puedes hacer esta semana.
Qué puedes hacer hoy — 3 pasos que cuestan horas, no semanas
- Esta semana: pasa tus 5 formularios principales (demo, contacto, presupuesto, suscripción, descarga) por isitagentready.com — diagnóstico en minutos.
- Esta semana: añade
toolnameytooldescriptiona esos formularios. No activestoolautosubmittodavía. Coste: 1 hora por formulario. - Esta semana: incluye el polyfill
@mcp-b/globalcon un<script>tag para compatibilidad fuera de Chrome. - Este mes: instala la extensión Model Context Tool Inspector para verificar que los tools se registran correctamente.
- Próximo trimestre (opcional): regístrate en el Origin Trial de Chrome 149 e implementa 1-2 tools imperativos en tu página más visitada.
SEO te hizo encontrable. GEO y AEO te hicieron citable. WebMCP puede hacerte operable: que el agente de tu comprador no solo te encuentre y te cite, sino que reserve una demo, pida un presupuesto o filtre tu catálogo directamente desde tu web.
Si necesitas ayuda para implementar WebMCP, nuestro equipo monitoriza la evolución del estándar desde el primer día.
Preguntas frecuentes
¿Qué es WebMCP?
WebMCP (Web Model Context Protocol) es una propuesta de estándar del W3C, desarrollada por Google y Microsoft, que permite a las páginas web declarar herramientas que los agentes de IA del navegador pueden descubrir y ejecutar. Funciona con navigator.modelContext en Chrome 146+ y no requiere un servidor backend.
¿Cuál es la diferencia entre MCP y WebMCP?
MCP server-side requiere un servidor dedicado y autenticación OAuth. WebMCP funciona dentro de la pestaña del navegador y hereda la sesión del usuario. Son complementarios: MCP conecta agentes con datos internos; WebMCP permite que los agentes operen directamente sobre la interfaz de una web pública.
¿WebMCP funciona en todos los navegadores?
A mayo de 2026, WebMCP funciona nativamente solo en Chrome 146+ (flag) con Origin Trial en Chrome 149. Firefox y Safari no han anunciado soporte. Para otros navegadores existe el polyfill @mcp-b/global, que habilita las funcionalidades básicas en Chrome, Edge y Firefox.
¿Qué novedades trae Chrome 146 para WebMCP?
Chrome 146 introdujo el flag experimental chrome://flags/#enable-webmcp-testing que activa la API navigator.modelContext. Desde entonces, Chrome 148 añadió AbortSignal para gestionar el ciclo de vida de tools y Chrome 149 (mayo 2026) lanzó el Origin Trial público, anunciado en Google I/O 2026.
¿Cómo puedo preparar mi web para WebMCP hoy?
Tres pasos que cuestan horas: audita tus formularios en isitagentready.com, añade los atributos toolname y tooldescription a cada formulario sin activar toolautosubmit, e incluye el polyfill @mcp-b/global con un script tag. No rompe nada y te posiciona como early adopter.
