OpenChrome - servidor MCP de automatización paralela para el navegador Chrome
(github.com/shaun0927)Playwright es una herramienta útil de automatización web que manipula acciones como clics en el navegador cuando quieres hacer crawling de alguna forma o ejecutar pruebas E2E en un entorno de producción.
Aunque se lanzó en 2020,
sigue siendo una herramienta que usa la mayoría de los desarrolladores.
Pero incluso con una sola sesión encendida consume más de 2 GB de RAM; es pesada, lenta y se rompe con facilidad.
En la era de la IA, esta herramienta necesita una innovación,
y en especial hace falta una herramienta de automatización de navegador que funcione de forma estable incluso en trabajos en paralelo.
Ya no queremos hacer QA manualmente ni andar recorriendo sitios web.
OpenChrome es un proyecto que nace de la intención de resolver este problema.
Es un servidor MCP que logra automatización paralela del navegador de forma rápida e inteligente.
También es la herramienta que más uso últimamente en mi trabajo personal.
Usa el inicio de sesión del navegador Chrome,
y si vas a usar varias cuentas, solo tienes que indicar durante la tarea el nombre de la cuenta que quieres usar.
Por defecto funciona tomando como base el navegador Chrome que ya tiene la sesión iniciada.
Permite trabajo en paralelo en más de 20 navegadores y redujo el uso de RAM a unos 300 MB. Trabaja con Chrome ya autenticado y, en la práctica, neutraliza por completo la detección de bots. También puede integrarse con Openclaw.
Un ejemplo de uso es el siguiente.
"Haz crawling con oc de las publicaciones más recientes de 20 celebridades de Twitter."
(benchmark basado en claude code: 3 minutos 30 segundos; la mayor parte es tiempo de inferencia del LLM)
En realidad, el problema crónico de Playwright es el "deambular del LLM", cuando empieza a dar pasos en falso.
Aunque le indiques tareas como iniciar sesión, se pone a hurgar el sitio durante mucho tiempo probando una cosa y otra,
y al final suele llegar una notificación diciendo que falló después de tardar más de 30 minutos.
Openchrome resuelve esto no con un enfoque de suposición, sino con uno guiado.
Inicia sesión directamente en Chrome y, si le das un enlace, accede de inmediato a ese enlace.
Toma la mínima cantidad de capturas de pantalla y detecta rápido la posición de botones y otros elementos.
Si surge un problema durante la tarea, revisa su memoria y no repite el mismo error.
Como es un servidor MCP, puede usarse de inmediato en cualquier entorno en lugar de Playwright.
Funciona no solo para desarrollo en MAC-claude code o en otros sistemas operativos como Windows y Linux,
sino también en codex cli, cursor y más.
Instalación:
npx openchrome-mcp setup
La estabilidad en producción a gran escala, especialmente en casos muy complejos y de alto consumo de recursos, todavía necesita validación adicional.
Si tienes comentarios o sugerencias, súbelos a GitHub Issues y los reflejaré de inmediato.
Gracias.
13 comentarios
¿Eso significa que, en lugar de usar una solución E2E existente, la propia IA va a gestionar y ejecutar directamente el código de pruebas?
Si antes
playwrightaccedía a los sitios web con una metodología estructurada y por eso consumía muchos tokens,creo que
openchromepuede verse como un concepto que aborda esto de una forma amigable para los LLM, permitiendo que el LLM intervenga rápidamente y controle directamente el comportamiento del sitio web. Puede ejecutar directamente soluciones e2e.Por ejemplo, en un entorno de producción donde se requiere inicio de sesión con Google, se le puede pedir que realice tareas de QA mientras ya está conectado con una cuenta de administrador. Puede desplazarse, hacer clic por su cuenta en casos límite y, en general, es posible realizar casi cualquier tarea que uno imagine. Esto se debe a que, en lugar de dejar que
playwrighthaga de forma autónoma tareas tontas, el LLM interviene de inmediato para controlar el comportamiento.Si solo vemos el uso de tokens, ¿no termina siendo menor en un método más estructurado ejecutar los casos de prueba E2E sin intervención del LLM?
En la metodología de pruebas también se incluye que, además de los TC, QA pruebe de forma autónoma,
si se considera que esa parte es eficiente, ¿estaría bien evaluarlo así?
Para responderte de forma más técnica,
el MCP de Playwright existente funciona con las siguientes 3 capas de abstracción:
LLM → servidor MCP → servidor Playwright Node.js → CDP/Juggler → navegador
En cambio, OpenChrome funciona con la siguiente abstracción de 1 capa:
LLM → servidor MCP → CDP → navegador
Cuantas menos capas de abstracción haya, más rápido es y más preciso es el control;
Playwright es una herramienta de propósito general, mientras que OpenChrome usa herramientas especializadas.
Si lo comparas con un problema de matemáticas, sería como comprimir una solución de 20 líneas en 4 líneas.
Como Playwright recibe retroalimentación mediante un método basado en texto llamado árbol de accesibilidad,
(esa es la razón por la que, aunque en teoría es excelente, se rompe en la mayoría de los sitios)
su capacidad para entender el contexto también es bastante limitada.
Por eso, en sitios con una accesibilidad bien implementada (Google y otros dominios conocidos), Playwright sigue siendo útil, pero
en la mayoría de los sitios o en producción, OpenChrome es abrumadoramente mejor.
Además, como la "densidad del diseño de herramientas" y "reducir las oportunidades de que el LLM cometa errores" terminan determinando el rendimiento real en la práctica,
creo que lo correcto es medirlo con tareas del mundo real, no con rendimiento teórico.
Gracias. Parece que no había leído el artículo completo con suficiente atención.
Pasé por alto la parte en la que decía que estaba orientado a entornos de producción.
Yo también me aseguraré de probarlo.
Gracias por responder con tanta dedicación a una pregunta equivocada~
No, para nada; gracias por la buena pregunta. A mí también me sirvió para aclarar las ideas mientras lo explicaba.
Definitivamente es rápido y bueno.
Pero si aparece una alerta, se queda detenido.
Vamos a mejorar este contenido rápidamente.
¡También me da curiosidad la comparación con Chrome DevTools MCP!
Cuando lo probé, recuerdo que Playwright resultó incluso mejor que chrome devtools mcp; más adelante intentaré agregar benchmarks.
Con
chrome devtools mcpno aparece la advertencia de contexto grande, pero sentía que el rendimiento era más o menos similar, así que yo estaba usando este. ¡Tengo ganas de ver los resultados del benchmark! :DOh, ¿también se reduce el uso de tokens? ¡Gracias!
Se puede decir que, en la medida en que reduce esos movimientos en falso, también disminuye el consumo de tokens.