- MCP-B: protocolo nativo de automatización con IA para navegadores
- En lugar del método tradicional de capturas de pantalla y clics, es un protocolo de contexto para navegadores que permite a la IA automatizar de forma 1,000 veces más rápida y precisa al acceder directamente a la API del sitio web
- Con solo unas 50 líneas de código adicionales, es posible integrar IA de inmediato usando las credenciales de autenticación del sitio, sin OAuth, claves API ni configuraciones complejas
- Aprovecha la sesión del navegador y los sistemas de autenticación existentes, por lo que funciona al instante sin nuevas configuraciones de autenticación o permisos, y respeta tal cual las políticas de seguridad de API de cada aplicación web
- Mediante una extensión, un asistente de IA puede consultar datos y ejecutar tareas directamente entre múltiples pestañas y aplicaciones, con una mejora abrumadora en rendimiento (ejecución en pocos ms) y confiabilidad frente a la automatización tradicional
- Como se basa en acceso estructurado a APIs, evita problemas por cambios de UI, errores de capturas de pantalla y la compleja gestión de selectores. Tanto la instalación como el uso son muy simples
Resumen de MCP-B
- MCP-B (Machine Context Protocol for Browsers) es un protocolo de contexto de modelo para navegadores que ofrece un estándar para controlar e interactuar con el entorno del navegador de forma similar a la automatización de terminales basada en IA
- Este protocolo define claramente la comunicación entre el navegador y el motor de IA, estructurando diversas automatizaciones e interacciones con modelos
Diferencias frente a los métodos existentes
- Automatización tradicional de navegadores: análisis de capturas de pantalla, clics en elementos, vulnerable a cambios de UI, lenta e inestable (10 a 20 segundos por tarea, costo de $4 a $5)
- Método MCP existente: requiere claves API y autenticación compleja, con una barrera de entrada alta en la configuración inicial
- MCP-B: aprovecha la sesión del navegador, acceso directo a APIs y funcionamiento inmediato sin autenticación ni configuración complejas
Principios y arquitectura clave
- Servidor MCP por pestaña: cada app web ejecuta su propio servidor MCP basado en TypeScript (transporte en memoria, reutilización de autenticación existente con cookies/JWT)
- Extensión MCP-B: extensión para Chrome/Edge/Firefox (el script de contenido se comunica con el servidor de la pestaña mediante
postMessage), integrando en un solo lugar todas las herramientas y APIs de todas las pestañas - Integración con asistentes de IA: la automatización del navegador es posible mediante MCP-B desde Native Bridge y varios clientes (Claude Desktop, Cursor IDE, etc.)
Uso y despliegue
- Desarrolladores: 1) instalar el paquete 2) agregar el código del servidor MCP 3) desplegar → no se requieren claves API, OAuth ni configuraciones complejas
- Usuarios: pueden usarlo de inmediato tras instalar la extensión; basta con la configuración de IA para automatizar al instante
Ventajas reales
- Autenticación: usa tal cual el inicio de sesión y la información de sesión existentes del sitio web; no requiere OAuth 2.1 ni autenticación adicional
- Rendimiento: las tareas se completan en milisegundos mediante llamadas directas a la API (mejora de 10,000 veces frente al método anterior)
- Seguridad: funciona dentro de la aplicación y respeta los controles de acceso y políticas de permisos existentes
- Escalabilidad: múltiples aplicaciones web, pestañas y herramientas de IA pueden gestionarse de forma unificada mediante MCP-B
- Configuración: con unas 50 líneas de código, la automatización queda lista
Resumen comparativo
| Método | Autenticación y configuración | Forma de funcionamiento | Rendimiento y confiabilidad |
|---|---|---|---|
| Automatización tradicional | Autenticación compleja, claves API | Scraping de pantalla, clics | Lenta e inestable (10 a 20 s) |
| MCP existente | Requiere clave API y OAuth | Acceso a API | Barrera de entrada alta |
| MCP-B | Sin configuración, usa la sesión del navegador | Llamadas directas a API | En ms, muy rápido/estable |
Conclusión: automatización con IA de nueva generación basada en navegador
- MCP-B es un protocolo de automatización con IA optimizado para el entorno del navegador, innovador en autenticación, seguridad, escalabilidad y rendimiento
- Permite implementar automatización de IA a gran escala únicamente con llamadas directas a APIs desde el navegador, sin autenticación adicional ni configuraciones complejas
- Licencia MIT, centrado en la comunidad y compatible con todos los navegadores principales
2 comentarios
La visión central de la tecnología MCP-B puede entenderse así.
"A través del medio confiable que representa una extensión de Chrome (Extension), se aprovechará la información del usuario que el navegador ya gestiona de forma segura (cookies, sesiones, autenticación, etc.) para invocar y controlar con comandos en lenguaje natural, desde una ventana de chat de IA, las 'herramientas (Tools)' que los desarrolladores hayan definido previamente en la página web."
Sin embargo, yo siento que "no parece tener margen para escalar", y creo que las razones son las siguientes.
En conclusión,
aunque la idea de MCP-B en sí es técnicamente muy interesante e innovadora, parece que no logra dar una respuesta clara a la pregunta fundamental de "¿por qué habría que usar precisamente este método?" tanto para usuarios como para desarrolladores. En comparación con el enfoque tradicional basado en API, los beneficios obtenidos no están claros, mientras que las desventajas, como las preocupaciones de seguridad y la complejidad del desarrollo, sí lo están.
Por lo tanto, por ahora parece que esta tecnología podría usarse de forma experimental entre algunos entusiastas o desarrolladores con objetivos específicos, pero da la impresión de que enfrenta muchas dificultades para expandirse al ecosistema web en general.
Opiniones en Hacker News
Predicción: esto seguirá un camino similar al de RSS. Las empresas tienden a sentirse incómodas con que los usuarios controlen por sí mismos cómo se usan sus datos
Con las API REST pasó algo parecido: en algún momento se esperaba que, junto con la moda del diseño "API-first", fueran el futuro de la automatización e integración de servicios. Pero las empresas se dieron cuenta rápidamente de que ofrecer esa capacidad amenazaba su modelo de ingresos, así que cambiaron de rumbo enseguida. Al final volvieron a concluir que todo su negocio depende de impedir que los usuarios tengan ese tipo de poder
Yo diría que RSS no fracasó; al contrario, fue un éxito enorme. Después de que desapareció Google Reader, me cambié a otros lectores y los feeds RSS han seguido funcionando sin problemas por más de 20 años. Casi nunca me topo con sitios que no soporten RSS
La mayoría de los sitios web todavía soportan RSS, y algunos incluso tienen feeds por defecto aunque no los muestren en la página. Aunque algunos no publiquen el texto completo, sigue siendo muy valioso para avisos de actualizaciones o como disparador de automatizaciones. RSS sigue vivo y siendo muy útil, como un microondas: simplemente das por hecho que está ahí
La estructura del mercado cambió, y ahora las grandes empresas se enfocan más en la "capa de inteligencia" que en el contenido mismo. El contenido se está volviendo cada vez más un commodity. Google necesita quedarse con los ojos y la atención de los usuarios, además de la tecnología inteligente que los atrapa, para poder seguir vendiendo anuncios. Google no quería RSS porque RSS podía saltarse Google Search
Cuando la IA pueda hacer clic y scroll como una persona, vamos a ver otra ronda de competencia infinita
El historial de contribuciones del proyecto en GitHub es muy interesante (citando este enlace). MiguelsPizza hizo 3 commits y Claude 2, pero el volumen de cambios de código de Claude es casi abrumador
Hubo una diferencia menor con el historial real porque el autor puso temporalmente la extensión en privado y ajustó el historial de git. Aun así, es cierto que Claude escribió alrededor del 85% del código total
Parece probable que este patrón —contribuciones masivas de código impulsadas por IA— se vuelva cada vez más común
El gráfico de commits de Claude es muy peculiar. Parece como si Claude Code hiciera commits directamente, pero en realidad casi no ocurre. También recomiendan ver el perfil de claude
Si revisas la lista real de commits, todos aparecen a nombre de MiguelsPizza / Alex Nahas (enlace). Se ve raro
Citando un fragmento del blog, hablan del problema de autenticación en MCP. OAuth2.1 parece razonable a largo plazo, pero estamos en una situación donde hay que reinventar la autenticación para agentes que actúan en nombre del usuario. El riesgo de fuga de datos dentro de apps multi-tenant todavía no está resuelto
Limitar el alcance del daño y los datos a los que puede acceder el modelo podría ser una gran ventaja de MCP. Se esperaría que la API del lado del cliente de una app multi-tenant ya estuviera restringida al ámbito del usuario, así que si solo se le da eso al modelo, el daño no debería ser tan grande. También se menciona el problema de compatibilidad entre el sistema interno de autenticación de Amazon y OAuth2.1 (en Amazon la autenticación es distinta)
Alguien se pregunta si parte de lo que hace OAuth2.1 ya está cubierto en RFC 8693 sobre delegación e impersonación
El alcance al que puede acceder el modelo al final es el mismo que el del usuario, así que la implementación segura es responsabilidad del administrador del sitio web
No creo que el ejemplo de Amazon, donde OAuth no está bien aplicado, sea el problema principal. Un acceso tipo puerta trasera que exceda el alcance de permisos del usuario sería muy peligroso. Si todas las acciones de una app MCP quedan registradas dentro de la misma categoría que el acceso del usuario, podría haber muchos problemas de compliance. Es muy interesante desde esa perspectiva, pero en seguridad parece que podría prestarse a abusos como vía de evasión
Se plantea la idea de que, si se publica una especificación Swagger (OpenAPI) y existe un cliente genérico de swagger mcp, casi todo esto podría reemplazarse. El usuario podría abrir manualmente su propia sesión autenticada. También sugieren que, si Claude identifica bien la API key desde el prompt o la configuración y usa un cliente de API basado en swagger, en esencia sería lo mismo
Fue lo primero que a todos se les ocurrió cuando apareció MCP. Pero en la práctica quedó claro que no funciona tan bien porque hay demasiadas herramientas. Aun así, siguen apareciendo intentos interesantes en este espacio
También hay una advertencia: no pongas API keys en el prompt
Claude Code se vuelve realmente cómodo para probar APIs si en
CLAUDE.mdsolo le das el enlace aswagger.jsonAniman a probarlo por cuenta propia
No me queda claro quién es el usuario objetivo. En pruebas de frontend, que los tests se rompan cuando cambia mucho la UI hasta puede ser útil. Para otros fines de automatización, me parece mejor ofrecer una API real
Ante la analogía de que "sería todavía más difícil construir una mesa en Home Depot", alguien cuestiona la idea diciendo que Home Depot está lleno de madera
En Home Depot también venden mesas ya hechas
Home Depot incluso podría facilitar más el trabajo porque tiene mejores herramientas de precisión y hasta expertos
Bromean con el matiz de que "la madera tienes que imaginarla y crearla tú"
Luego aclaran que ajustaron la frase tomando en cuenta esa observación
No he usado MCP directamente, pero desde la perspectiva de una persona con discapacidad, parece tener muchísimo potencial para accesibilidad en automatización de navegador y smartphone. Aun así, me pregunto si los principales sitios y apps realmente lo adoptarían, porque este tipo de tecnología puede ser abusada por actores maliciosos. También preguntan si existe algún caso real donde ya se esté usando para mejorar accesibilidad
Agradecen que MCP-B haya sido liberado como open source. Muchas cosas pasan dentro del navegador, pero con MCP hay una diferencia en la premisa: que un cliente de IA realiza la tarea. La duda es en qué se diferencia fundamentalmente MCP-B de conectar directamente la API JS de una web app con un servidor LLM para usarla así. Preguntan si al final es lo mismo o si hay una visión más amplia detrás
Solo con lo que dice la página principal no se entiende muy bien, y alguien pregunta si es como una versión para navegador de Selenium
Predicen que, si empieza la automatización de navegador vía MCP para usuarios de LLM gratuitos, llegará un mundo donde incluso a los modelos gratis se les pida captcha. El problema es que los captchas no son muy efectivos contra los LLM, así que podríamos terminar en una extraña era de guerras entre robots, donde los LLM pelean entre sí para bloquear el acceso de otros LLM de automatización