Alex Nahas construyó MCP dentro de un navegador en Amazon. Ahora Microsoft y Google lo están convirtiendo en un estándar W3C.

Este artículo está adaptado de la entrevista de Alex en nuestra serie de videos MCP MVP*.

El episodio 1 presenta a Alex Nahas, creador de MCP-B y uno de los principales impulsores de la especificación WebMCP.

¿Tienes opinión sobre WebMCP? Compártela en los comentarios del video de arriba ↑*

Imagina que tu sitio le dice al agente ChatGPT de un visitante: “Esto es lo que puedo hacer. Así es como pedirme que lo haga”.

Hasta el 10 de febrero de 2026, solo había dos formas en que un agente de AI podía interactuar con un sitio web:

  • Visualmente El agente evalúa capturas de pantalla, lee texto e infiere dónde mover el cursor en la pantalla.
  • Semánticamente El agente analiza grandes volúmenes de XML subyacente (DOM, árbol de accesibilidad) para extraer datos y llamar eventos en elementos.

Estas pueden ejecutarse a nivel de navegador o sistemáticamente, con el agente controlando el sistema de la computadora, sintetizando entradas. Requieren más roundtrips, inferencia y modelos multimodales, lo que afecta el rendimiento, el costo y la confiabilidad, consumiendo tokens y tiempo mientras los agentes intentan orientarse por su cuenta.

WebMCP busca ser una tercera opción eficiente y confiable. Los sitios pueden exponer herramientas estructuradas como funciones de JavaScript con descripciones y esquemas que los agentes pueden invocar directamente. Actualmente está siendo incubado por el W3C Web Machine Learning Community Group y acaba de llegar a Chrome.

Si desarrollas para la web, WebMCP merece tu atención. Podría cambiar lo que significa “construir un sitio web”.

El origen en Amazon

Alex Nahas era ingeniero backend en Amazon cuando MCP llegó a principios de 2025. Amazon, con sus miles de servicios internos, montó lo que equivalía a un enorme servidor MCP que ofrecía miles de herramientas, todas apretadas en una sola ventana de contexto.

“Tenías que deshabilitarlas con comandos de proceso en la cadena de conexión”, explicó Alex. Era, siendo generosos, un desastre.

Pero el problema real era la autorización. La especificación MCP había adoptado OAuth 2.1, que prácticamente nadie en Amazon había implementado internamente. Cada servicio interno tenía su propio esquema de autenticación, y ninguno hablaba OAuth 2.1.

En Amazon, toda la autorización se gestiona mediante una experiencia de navegador federada que autentica a los usuarios en cada servicio, dashboard y recurso disponible para los empleados. Alex tuvo la idea de ejecutar MCP en el navegador y aprovechar su SSO, cookies de sesión y proveedores de identidad existentes.

Eso es lo que MCP-B es (la “B” es de “browser”). Alex integró el SDK de TypeScript de MCP en una aplicación JavaScript del lado del cliente y construyó un transporte personalizado usando postMessage para comunicarse con una extensión de Chrome. Y funcionó tan bien que no pudo quedarse dentro de Amazon.

De proyecto personal a estándar W3C

Los equipos de Chrome de Google y Edge de Microsoft venían trabajando en ideas paralelas. Chrome estaba prototipando “script tools,” y Edge rondaba la misma pregunta: ¿cómo permitimos que los agentes interactúen con aplicaciones web de forma estructurada?

Cuando llegó MCP-B, se unieron con Alex a través del W3C y lo llamaron WebMCP.

Pero el nombre puede confundir: WebMCP no es MCP. No sigue la especificación JSON-RPC. Alex insistió desde el principio en portar el protocolo MCP completo al navegador, pero el grupo de trabajo no quiso acoplarse demasiado a la especificación. Comparte la superficie de API y el modelo conceptual de MCP: herramientas con esquemas que los agentes pueden invocar.

Está diseñado específicamente para el navegador. Corre completamente del lado del cliente, sin la dinámica cliente-servidor del MCP de Anthropic, donde los proveedores alojan servidores MCP y los agentes consumen a través de clientes MCP. Aquí, la página web es el “servidor” que arranca cuando un agente llega a ella. Las mismas funciones que se usan para enviar formularios o consultar bases de datos en componentes de React ahora pueden exponerse directamente a los agentes, sin necesidad de que sinteticen clics ni entradas de texto.

Si ahora estás pensando en “Java y JavaScript”, no eres el único. El nombre generará confusión, ya que WebMCP por ahora no tiene planes de implementar prompts ni resources, solo la parte de “tools” del estándar MCP. Por suerte, Alex creó un polyfill que implementa la API de WebMCP y la convierte a JSON-RPC, así obtienes un SDK de MCP compatible con la especificación corriendo en tu navegador.

La trifecta letal

Hay un problema de seguridad sin resolver que enfrentan los agentes que acceden a la web: la trifecta letal.

Imagina esto: tienes dos pestañas abiertas. La pestaña A es tu banco. La pestaña B es un sitio malicioso. Un agente de navegador está en medio con contexto de ambas. Este agente trata ambas fuentes de contexto como iguales.

La pestaña maliciosa podría ordenarle al agente que extraiga números de cuenta de la pestaña bancaria. O empujar instrucciones en sentido contrario y hacer que el agente transfiera fondos. Esto no es teórico; es arquitectónicamente inevitable con la forma en que funcionan los agentes de navegador hoy. Como dijo Alex: “Si vas a usar Comet, si vas a usar Atlas, simplemente tienes que decir: okay, este es un riesgo que estoy dispuesto a asumir.”

WebMCP no elimina este problema, pero reduce significativamente la superficie de ataque. En lugar de que el agente opere sobre capturas de pantalla y el DOM en crudo, donde puede ver todo, incluyendo elementos ocultos, opera sobre llamadas a herramientas explícitas. Acciones discretas. Cosas que el sitio web ha elegido específicamente exponer. Puedes hacer hash de las herramientas, configurar flujos de elicitación para primeras conexiones y limitar la confianza a dominios específicos con un TTL.

¿Es infalible? No. La inyección de prompts sigue existiendo donde haya herramientas dinámicas de terceros. Pero pasar de “el modelo puede ver y hacer todo lo que puede un usuario, más leer el DOM” a “el modelo puede llamar estas funciones específicas” es una reducción significativa del alcance que podría cambiar la forma en que se construyen los navegadores en el futuro.

Tres patrones de herramientas en WebMCP

Alex ha construido varios sitios con WebMCP habilitado y encontró que las herramientas WebMCP caen en estas categorías:

Herramientas de solo lectura deben exponerse como una lista plana, siempre disponible en el contexto del agente. Son tus operaciones GET: obtener datos, leer estado. No quieres que el agente navegue por tu interfaz solo para leer información. Expón todo; deja que el agente consulte lo que necesite.

Herramientas de navegación son el system prompt de tu sitio web. Le dicen al agente qué hace tu sitio y dónde vive la información. “Aquí están los enlaces. Se revelarán más herramientas conforme los visites.” Es el plano. Las marcas como destructivas porque causan cambios visibles: la página navega de verdad, y un agente que respeta las señales de destructividad se lo notificará al usuario.

Herramientas de escritura toman acción. Llenan formularios, envían datos, hacen cambios. Aquí es donde la elicitación de MCP brilla: el agente puede llenar un formulario y luego mostrárselo al usuario, “Esto es lo que estoy a punto de enviar. ¿Sí o no?” El humano se mantiene en el ciclo.

Con estos tres primitivos, argumenta Alex, hasta un sitio viejo de WordPress se convierte en “básicamente una empresa de AI”. Todo puede ser JavaScript vainilla, sin necesidad de ningún framework.

Por qué la web no va a ningún lado

Alex no cree que MCP y los agentes vayan a reemplazar la web.

Piensa en los casos de uso: muchas aplicaciones ofrecen más que texto. Los lienzos (Figma) y los dashboards complejos (Quickbooks, Shopify) requieren una interfaz visual donde el humano es el actor principal y un agente ayudaría desde el lado. Otras aplicaciones hacen búsquedas de datos y transacciones simples, que se sirven mejor llevando la aplicación al agente. WebMCP sirve al primer grupo: el agente va al sitio web, no al revés.

Sin importar cómo naveguemos la web en el futuro, HTML, CSS y JavaScript seguirán siendo los bloques fundamentales para aplicaciones universalmente compatibles que cualquier plataforma puede renderizar. El modelo de interacción puede cambiar de navegadores a agentes para muchos usuarios y casos de uso, pero el sustrato subyacente no va a desaparecer.

WebMCP es una mejora progresiva para la web que permite a los sitios servir tanto a humanos como a agentes. Los sitios persisten. Los agentes necesitan una mejor forma de interactuar con ellos. Un estándar web es el vehículo adecuado para eso.

Estamos al inicio

WebMCP está en sus inicios. La especificación está pasando de la incubación comunitaria a un borrador formal. Chrome tiene una implementación experimental detrás de un flag en Chromium. Alex espera anuncios oficiales de los navegadores para mediados o finales de 2026.

Si quieres probarlo ahora:

Qué significa esto para ti

Si construyes aplicaciones web, WebMCP vale la pena explorarlo porque te permite definir cómo los agentes interactúan con tu sitio en lugar de dejar que el agente lo descifre por su cuenta. Es una mejora proactiva y progresiva, muy parecida a agregar funciones de accesibilidad a tu sitio.

No necesitas rediseñar nada. El punto es que estás envolviendo lógica del lado del cliente que ya existe. Tu función add-to-cart(), tu búsqueda y el envío de formularios ya funcionan. WebMCP solo los hace descubribles e invocables por los agentes.

Ya sea que esto se convierta en el estándar o en un punto intermedio hacia algo más, la dirección es clara: los dueños de sitios que quieran atraer usuarios que operan a través de agentes como Claude y ChatGPT querrán una capa orientada a agentes para ofrecer la mejor experiencia posible.

WebMCP es el intento más serio de hacer de eso un primitivo de plataforma, no un añadido de último momento.

MCP MVP es una serie de videos de Arcade.dev que destaca a los creadores que dan forma al ecosistema agéntico. Mira el video completo →

agenticweb.nearestnabors.com.

WebMCP lleva MCP al navegador. Arcade es el runtime que lleva MCP a producción. Prueba gratis →