Tus agentes pilotan un navegador real.
No uno falso.
AgentsRoom integra un navegador Chromium real en cada proyecto, e incluye un servidor AgentsRoom Browser MCP que deja que tus agentes IA lo controlen. Tu agente QA abre tu sitio localhost, hace clic en los botones, rellena los formularios, toma capturas, lee la consola, y verifica que la feature realmente funciona antes de decir done. Automatización de navegador end-to-end para Claude Code, Codex, OpenCode, Gemini CLI y Aider, con cero configuración Playwright.
Combínalo con Agent Teams: un agente Dev entrega la feature, un agente QA carga el sitio localhost en el navegador integrado, ejecuta el escenario de verificación, captura el resultado, y firma. La automatización de navegador nativa también está en el roadmap, con futuros servidores MCP planeados para apps React Native y Electron para que los agentes también puedan testear apps móviles y desktop.
Demo de AgentsRoom Browser MCP: testing end-to-end de apps web dirigido por un agente QA Claude Code a través del navegador Chromium integrado.
Browser Automation en AgentsRoom son dos cosas en una. Primero, un navegador Chromium real integrado en cada room de proyecto, con barra de URL, atrás/adelante, reload, historial, captura al portapapeles, abrir-en-navegador-por-defecto, cookies persistentes y localStorage por proyecto. Segundo, un servidor AgentsRoom Browser MCP (agentsroom-browser) que expone ese navegador a tus agentes IA a través del Model Context Protocol. El agente recibe una interfaz limpia y scriptable: navigate, click, type, screenshot, evaluate JavaScript, wait for an element, get the page state, get the console logs, go back, go forward, reload.
¿Por qué importa esto? Porque toda la promesa de los agentes IA de código se desmorona cuando el agente dice 'feature entregada' pero nunca abre la página para comprobar. La mayoría de los agentes hoy se basan en correr unit tests, y luego cruzan los dedos. Con un Browser MCP real, el agente carga el servidor localhost, ejercita el flow del usuario, ve lo que vería el usuario humano, y solo entonces firma. El rol de agente QA Engineer por fin tiene los tools que necesita para hacer QA real, no solo análisis estático.
El setup técnico es invisible para ti. Cuando marcas 'Browser access' en un agente, AgentsRoom mergea la entrada agentsroom-browser en el .mcp.json de tu proyecto y el agente arranca con los tools de browser disponibles. Un puente WebSocket que corre en un puerto loopback (127.0.0.1, asignado por el OS, regenerado en cada arranque, autenticado con un token hex de 32 bytes) conecta el subproceso MCP a la WebContentsView Chromium en la app Electron. Cada clic, cada escritura, cada captura es una llamada JSON-RPC. El agente ve un navegador real, no un stub.
Panel Browser de AgentsRoom: barra de URL, historial, captura, y superficie de control MCP completa para que los agentes IA naveguen, hagan clic, escriban y verifiquen.
Un navegador real, no un stub Playwright
La mayoría de las demos de agentes IA que hablan de browser automation usan una instancia Playwright headless spawneada en cada llamada de tool. Eso funciona para benchmarks pero es un dolor en la vida real: no puedes ver lo que el agente está haciendo, cada navegación respawnea Chromium, las cookies se pierden, el localStorage está vacío, tu servidor de dev cree que cada visita es una sesión nueva. AgentsRoom toma un ángulo distinto. El navegador ya está abierto en tu room de proyecto (lo usas tú mismo, como un navegador normal), y el agente pilota ese navegador. Sesiones, cookies, localStorage, estado de login, todo preservado.
Cada clic y escritura del agente dispara un dispatch nativo real a través del WebContentsView de Electron, con eventos de teclado, eventos de ratón y mutaciones DOM reales. Las capturas son PNGs reales capturados de la página renderizada real (no un hack DOM-a-imagen). Los logs de consola se buferizan y son consultables, incluyendo warnings y errors. El agente ve lo mismo que verías tú con las DevTools abiertas: rendimiento real, comportamiento de red real, CORS real, auth real.
El aislamiento cross-room está aplicado. AgentsRoom crea una WebContentsView Chromium por proyecto, con su propia partición de sesión (persist:agentsroom-browser-<projectId>). Las cookies del proyecto A nunca se filtran al proyecto B. Cuando cambias de proyecto, el navegador anterior se oculta y el nuevo entra en línea con su propio estado. El agente siempre aterriza en el proyecto correcto, con las credenciales correctas.
La capa MCP es intencionadamente pequeña y sin dependencias. El subproceso browser-mcp-server.cjs habla el protocolo MCP 2024-11-05 sobre stdio (initialize, tools/list, tools/call) y lo traduce en llamadas JSON-RPC sobre el puente WebSocket loopback. Comparado con un servidor pesado basado en SDK, esto se mantiene rápido (primera llamada de tool por debajo de 100ms) y fácil de debuggear. Después de cada acción que cambia la página (click, type, navigate, reload, back, forward), la respuesta incluye una captura PNG en base64 con tope de 1.6 MB para que el agente siempre vea el resultado de lo que acaba de hacer. Esto resultó ser la mayor ganancia de fiabilidad: los agentes que ven la pantalla hacen lo correcto mucho más a menudo que los agentes que cruzan los dedos.
El toolkit Browser MCP que reciben tus agentes
Cada agente IA con browser access arranca con estos tools disponibles. Están expuestos a través de MCP estándar, así que cualquier CLI compatible los ve: Claude Code, Codex CLI, OpenCode, Gemini CLI, Aider.
browser_navigate
Abre una URL en el navegador integrado. Manejo inteligente de URL: localhost:3000 se vuelve http://localhost:3000 en lugar de disparar un diálogo 'cannot open application'. Devuelve la URL final y una captura de la página después de cargar.
browser_click
Hace clic en un elemento por selector o por texto visible. Evento de click nativo real, no un dispatch JavaScript. Devuelve la captura post-clic para que el agente vea el resultado de su acción.
browser_type
Escribe texto en un input o textarea. Soporta atajos de teclado y submit. Eventos de teclado reales, los handlers onChange de la página se disparan. Devuelve la captura después de escribir.
browser_screenshot
Captura el viewport actual como PNG. Útil para checks de regresión visual, design QA, comparaciones antes-y-después, o para compartir el estado de un bug con el resto del equipo.
browser_evaluate
Ejecuta una expresión JavaScript en el main world de la página. Recupera el resultado serializado. Usado por los agentes para leer el estado de la página, consultar el DOM, inspeccionar un store Redux, o disparar una acción que no tiene botón visible.
browser_wait_for
Espera a que aparezca un elemento, a que cambie la URL, a que termine una request de red, o a que JavaScript arbitrario devuelva true. Evita la clásica race 'el agente hace clic demasiado rápido'.
browser_get_state
Lee la URL actual, el título, el viewport, la posición de scroll, y un snapshot estructurado de los elementos accesibles de la página. El input principal del agente cuando necesita planear su próxima acción.
browser_get_logs
Recupera el buffer de consola (log, warn, error). El agente puede ver los mismos warnings React, errores de hidratación, fallos de red y excepciones de runtime que verías tú en las DevTools. Los bug reports se vuelven 'aquí está el error de la consola'.
browser_go_back / forward / reload
Navegación estándar de navegador, scriptable. Usada por los agentes para retroceder cuando un flow va mal, o para re-testear una página después de un hot reload de Vite, Next.js o Expo Metro.
Lo que los agentes hacen de verdad con el navegador
Workflows reales que puedes construir hoy, con el rol QA Engineer y Agent Teams.
Smoke test end-to-end en cada handoff
Conecta un equipo Dev a QA. El agente QA navega a tu servidor de dev localhost, hace clic por los caminos críticos (signup, checkout, dashboard), captura el resultado, y firma solo si nada falla. Atrapa regresiones antes de que un humano abra la página.
QA de regresión visual
Capturas antes-y-después en cambios de UI. El agente carga la página en el commit anterior, captura, cambia de rama, captura, le pide a Claude que compare. Diff visual barato para QA sin Percy ni Chromatic en el bucle.
Caza de errores de consola
El agente navega la app, llama browser_get_logs, encuentra warnings de hidratación React, warnings useEffect, 404s de red, errores CORS, notices de deprecación. Los reporta como una lista de riesgos en el payload de handoff del equipo, el siguiente agente Dev los arregla.
Tests de validación de formulario
El agente rellena el formulario con datos válidos, con campos vacíos, con casos límite (strings XSS, inputs muy largos, no-ASCII). Verifica los mensajes de validación, las requests de red, las redirecciones. QA real de formulario, no unit tests.
Auditoría de accesibilidad
El agente recorre la página, consulta el árbol de accesibilidad vía browser_get_state y browser_evaluate, comprueba alt textos, atributos ARIA, gestión de focus, navegación por teclado. Reporta problemas con capturas.
Design QA contra Figma
Combina con la feature Figma a agentes IA. El agente carga el frame Figma, captura, carga la página localhost, captura, compara espaciados, fuentes, colores, alineaciones. Presenta una lista de discrepancias.
Verificación de túnel de live preview
Combina con el túnel localhost de AgentsRoom. El agente navega a la URL HTTPS de preview pública (no localhost), verifica que el sitio es alcanzable desde fuera, captura, y confirma que un stakeholder puede de verdad abrir el link.
Reproducir un bug de cliente desde un ticket de backlog público
Un ticket de backlog público entra con una URL y pasos para reproducir. El agente QA abre la URL, sigue los pasos, captura el error de consola, adjunta la captura, hace handoff a Dev con una repro limpia. Se acabaron los bucles 'cannot reproduce'.
Cómo un agente consigue un navegador
Abre la pestaña Browser en tu room
En tu room de proyecto, el panel derecho expone tres pestañas: Files, Changes, Browser. Haz clic en Browser. El panel se ensancha, la sidebar se colapsa, y aparece una vista Chromium real. Escribe una URL o elige del historial del proyecto.
Marca 'Browser access' en el agente
Abre la modal Edit Agent, expande Capabilities, marca Browser access. AgentsRoom mergea la entrada agentsroom-browser en el .mcp.json de tu proyecto y el agente verá los tools de browser en el siguiente arranque.
<project>/.mcp.jsonEl agente arranca con el browser MCP
Al spawnear el agente, Claude (o Codex, Gemini, etc.) inicializa el servidor MCP agentsroom-browser, lista sus tools (browser_navigate, browser_click, browser_type, browser_screenshot, browser_evaluate, browser_wait_for, browser_get_state, browser_get_logs, browser_go_back, browser_go_forward, browser_reload), y a partir de ahí puede pilotar el navegador.
El agente usa el navegador
El agente navega, hace clic, escribe, captura, lee la consola. Cada acción pasa por un puente WebSocket loopback (127.0.0.1, puerto asignado por el OS, token hex de 32 bytes, regenerado en cada arranque de la app desktop). Después de cada acción que cambia la página, una captura se devuelve inline para que el agente verifique visualmente su movimiento.
Auto-targeting localhost o tu túnel
Si un túnel localhost está corriendo, la primera navegación aterriza en la URL del túnel. Si no, en el primer servidor de dev detectado. Si no, https://localhost:3000. Combinado con Dev Terminals, el agente literalmente arranca el servidor de dev, luego lo abre en el navegador, luego lo testea.
Verifica, captura, hace handoff
Cuando está conectado en Agent Teams, el node QA ejecuta sus escenarios, captura screenshots, pone flags.qaPassed en el payload de handoff. El siguiente agente hereda el veredicto. Pass va al PM, fail vuelve a Dev con las pistas de testing.
Bajo el capó
Para los curiosos. El stack de browser automation es pequeño a propósito.
Cada proyecto tiene una WebContentsView Chromium (la API moderna de Electron, no la BrowserView deprecada), superpuesta sobre la ventana principal con bounds streameados desde el renderer React. La partición de sesión por proyecto mantiene cookies, localStorage y autenticación aislados entre proyectos. Bounds offscreen por defecto dejan a los agentes llamar tools de browser incluso antes de que el humano abra la pestaña Browser, con un timeout de 5 segundos en las capturas para evitar cuelgues.
Un servidor WebSocket ligero (browser-bridge.ts) corre en un puerto loopback elegido por el OS, bound a 127.0.0.1 solamente. La autenticación usa un token hex de 32 bytes regenerado en cada arranque desktop. El archivo de puente ~/.agentsroom/browser-bridge.json contiene el puerto, el token y el PID actuales, reescrito atómicamente en cada arranque, para que el subproceso MCP siempre recoja credenciales frescos con retry automático.
El servidor MCP en sí es browser-mcp-server.cjs, un script Node sin dependencias que implementa el protocolo MCP 2024-11-05 sobre stdio (initialize, tools/list, tools/call). Habla JSON-RPC con el puente WebSocket a través de un cliente WebSocket hecho a mano (sin ws, sin @modelcontextprotocol/sdk). Pequeño, rápido, fácil de auditar. Empaquetado como archivo extraResources en la app desktop, así que cada install se entrega con él listo para arrancar.
El soporte de navegador nativo (una feature de browser de primera clase más allá del MCP) está en el roadmap de AgentsRoom. Más allá, el plan a largo plazo incluye MCPs adicionales para que los agentes piloten también targets no-web: un MCP React Native para apps móviles y un MCP Electron para apps desktop. Misma idea, misma UX: el agente no solo escribe código, ejercita de verdad la app que está corriendo.
FAQ
¿En qué se diferencia esto de Playwright MCP o herramientas de navegador basadas en Puppeteer?
Los MCPs basados en Playwright y Puppeteer spawnean un navegador headless fresco en cada sesión. Eso está bien para tareas sin estado, pero pierde cookies, localStorage y auth entre llamadas, y el humano no puede ver lo que el agente está haciendo. AgentsRoom Browser es el mismo navegador que el humano usa dentro de la app, con sesión persistente por proyecto, visible para el usuario en tiempo real. El agente pilota una ventana que puedes ver y tomar control en cualquier momento. Es una automatización de navegador más honesta y más debuggable.
¿Esto funciona con todos los providers IA, o solo con Claude Code?
Funciona con todos los providers que AgentsRoom soporta: Claude Code, Codex CLI, OpenCode, Gemini CLI y Aider. Los tools de browser están expuestos a través del Model Context Protocol estándar, que todos estos CLIs leen desde .mcp.json. El agente nunca sabe que está en AgentsRoom, simplemente ve un set de tools MCP y los usa como usaría cualquier otro tool.
¿El agente puede pilotar un sitio remoto, o solo localhost?
Ambos. Escribe cualquier URL y go. Las formas localhost (y host:port) son smart-detectadas, prefijadas con http://, y abiertas directamente. Los sitios públicos funcionan como en cualquier navegador normal, con cookies y estado de login preservados por proyecto. Combinado con el túnel localhost de AgentsRoom, el agente también puede pilotar tu servidor de dev local a través de una URL HTTPS pública, lo que es útil para QA cross-network y móvil.
¿El browser MCP es seguro? ¿Qué impide que se abuse de él?
El puente bindea solo a 127.0.0.1, nunca a 0.0.0.0. El puerto es asignado por el OS (sin puerto fijo propenso a scanning de colisión). Un token hex de 32 bytes es requerido en cada conexión, regenerado en cada arranque desktop. El subproceso MCP recibe los credenciales solo vía variables de entorno, nunca en un archivo commiteado. El acceso a navegador es opt-in por agente en la modal Edit Agent. Si lo quitas, la entrada .mcp.json se quita y el agente ya no puede usar los tools.
¿El agente ve la consola del navegador (errores, warnings, network)?
Sí, vía browser_get_logs. El buffer contiene mensajes console.log, console.warn y console.error del main world de la página. Muchos bugs reales (errores de hidratación React, warnings useEffect, fallos CORS) solo emergen en la consola, nunca en unit tests, así que esto resulta ser uno de los tools de mayor señal para el agente QA.
¿Qué pasa con las capturas devueltas al agente? ¿Cuestan muchos tokens?
Después de cada acción que cambia la página, una captura PNG en base64 se añade a la respuesta del tool, con tope de 1.6 MB. Por encima, se envía un marcador de texto en su lugar. Las capturas son críticas para la fiabilidad (un agente que ve la pantalla comete bastantes menos errores), así que el trade-off vale la pena. Si quieres desactivar las capturas por razones de presupuesto, las llamadas browser_evaluate simples devuelven solo texto.
¿El agente puede rellenar un formulario de login? ¿Persistir su sesión?
Sí. Cookies y localStorage se persisten por proyecto bajo la partición de sesión persist:agentsroom-browser-<projectId>. El agente puede loguearse una vez con browser_type y browser_click, y mantenerse logueado durante el resto del run. Cuando cambias de proyecto, la sesión cambia, así que los credenciales nunca se filtran entre proyectos.
¿Se rompe el agente si el servidor de dev no está corriendo?
Navegará a la URL y verá una página de error de Chromium. Puede leer ese error vía browser_get_state y browser_get_logs y reaccionar en consecuencia: pedirte que arranques el servidor, o llamar a un comando Dev Terminals para arrancarlo. Con Agent Teams y Dev Terminals, puedes conectar un workflow que arranque el servidor, espere, luego abra el navegador, todo sin intervención humana.
¿Las apps móviles y desktop también están soportadas?
La web está entregada hoy, a través del Chromium integrado y el AgentsRoom Browser MCP. El roadmap incluye un AgentsRoom Browser nativo como feature de browser de primera clase. Más allá, hay servidores MCP adicionales planeados: un MCP React Native para que los agentes piloten bundles iOS y Android Expo, y un MCP Electron para que los agentes piloten apps desktop que no son web. La misma lógica de agente, aplicada a targets no-web.
¿El humano puede pausar al agente y tomar control del navegador?
Sí. El navegador es la misma vista Chromium que usa el humano. En cualquier momento, haz clic en el panel Browser y tienes el control. Una vez que dejas de interactuar, el agente puede reanudar sus tool calls. No hay concepto de 'navegador bloqueado por el agente', es una superficie compartida, exactamente como una sesión de pair programming.
Dale a tus agentes ojos de navegador reales
Marca Browser access en cualquier agente en AgentsRoom. El Browser MCP arranca automáticamente. Tu agente QA por fin testea lo que entrega.
App complementaria: supervisa tus agentes en movimiento
Compatible con Claude, Codex, OpenCode, Gemini CLI y Aider
Envía bugs y peticiones directamente a tu backlog público.