Playwright MCP: configura tu agente y prueba tu web

El servidor Playwright MCP de Microsoft conecta agentes como Claude Code, Codex, Cursor y el agente Copilot de VS Code con Playwright, el framework de automatización de navegadores. Mi recomendación: úsalo para hacer comprobaciones exploratorias e investigar fallos; después, convierte los hallazgos importantes en pruebas revisadas y repetibles.

¿Qué permite hacer Playwright MCP?

El agente recibe controles para manejar el navegador y una descripción estructurada de la página. MCP, siglas de Model Context Protocol, es la conexión que le permite invocar esas herramientas. El servidor ejecuta las acciones en el navegador; el agente decide qué acción solicitar a continuación.

Una instantánea de accesibilidad funciona como el directorio de un edificio: identifica las salas y las puertas por su función y su nombre. Del mismo modo, una instantánea de la página describe botones, enlaces, campos de texto y sus nombres accesibles. Así, el agente puede elegir un elemento a partir de esa estructura, sin tener que adivinar dónde hacer clic en una imagen. El flujo predeterminado no requiere un modelo de visión. Descripción general de Microsoft

Antes de instalar, conviene elegir el enfoque. Microsoft ahora también propone Playwright CLI con skills a quienes usan agentes de programación, mientras presenta MCP como una opción útil para mantener el estado del navegador e inspeccionar repetidamente la estructura de la página. Elige MCP cuando esa interacción continua encaje en tu flujo de trabajo; considera la alternativa CLI si tu agente ya se desenvuelve bien con comandos de shell. Ninguna de las dos opciones demuestra por sí sola que el recorrido del cliente haya superado la prueba. Comparación de Microsoft entre MCP y CLI

Para conocer otras herramientas que pueden acompañarlo, consulta nuestra selección de los mejores servidores MCP para 2026.

Cómo instalarlo en Claude Code, Codex, Cursor o VS Code

Necesitas Node.js 18 o posterior y un cliente compatible con MCP. Los comandos y la configuración siguientes reproducen los ejemplos del README de Microsoft. Elige los de tu cliente: son alternativas de instalación, no una secuencia que debas ejecutar en todos los editores. Requisitos e instalación

Claude Code

Ejecuta este comando tal como aparece:

claude mcp add playwright npx @playwright/mcp@latest

Codex

Ejecuta este comando tal como aparece:

codex mcp add playwright npx "@playwright/mcp@latest"

También puedes añadir lo siguiente a ~/.codex/config.toml:

[mcp_servers.playwright]
command = "npx"
args = ["@playwright/mcp@latest"]

Cursor

Sigue la ruta manual del README: Cursor Settings -> MCP -> Add new MCP Server. Elige un nombre, selecciona el tipo command e introduce:

npx @playwright/mcp@latest

Usa Edit para revisar la configuración o añadir argumentos. El README también incluye un botón de instalación en Cursor.

VS Code

Utiliza el comando de la CLI de VS Code exactamente como se muestra:

code --add-mcp '{"name":"playwright","command":"npx","args":["@playwright/mcp@latest"]}'

El servidor quedará disponible para tu agente de GitHub Copilot en VS Code. El README de Microsoft también enlaza los botones de instalación y la guía de configuración de MCP para VS Code.

Configuración JSON común

Para los clientes que utilizan la configuración JSON estándar del README, este es el ejemplo exacto:

{
  "mcpServers": {
    "playwright": {
      "command": "npx",
      "args": [
        "@playwright/mcp@latest"
      ]
    }
  }
}

Sigue las indicaciones de tu cliente que aparecen arriba para colocarla donde corresponda. La alternativa para Codex usa TOML, no este JSON. Si también necesitas elegir el agente, consulta nuestra guía de agentes de programación con IA y pruebas en navegador.

Elige el navegador y cómo lo verá el agente

Empieza con una ventana de navegador visible, un perfil aislado e instantáneas. Añade las opciones a la lista de argumentos del servidor, después de @playwright/mcp@latest. Estas opciones proceden de la referencia de configuración de Microsoft.

Elegir entre instantáneas y visión es elegir el método de interacción. En el flujo predeterminado, utiliza browser_snapshot para identificar los elementos. browser_take_screenshot captura evidencia visual, pero tomar una captura no habilita por sí mismo los clics por coordenadas. Con --caps=vision, el README enumera browser_mouse_click_xy, browser_mouse_down, browser_mouse_drag_xy, browser_mouse_move_xy, browser_mouse_up y browser_mouse_wheel. El cliente y el modelo deben poder utilizar las imágenes recibidas para el razonamiento visual. Referencia de herramientas

Yo empezaría con instantáneas para los formularios y la navegación habituales. Recurre a la inspección visual cuando importe la apariencia o la estructura de la página no describa adecuadamente el control. Una instantánea de accesibilidad aporta información útil sobre la estructura; no permite determinar si la página se ve bien.

Herramientas clave para las pruebas automatizadas web

El conjunto básico de herramientas cubre navegación, interacción y recopilación de evidencias. Esta tabla agrupa las herramientas básicas de automatización y gestión de pestañas del README según la tarea que le encargues al agente. Lista de herramientas de Microsoft

Las acciones basadas en instantáneas utilizan una referencia al elemento de la instantánea o un selector único. Un selector sirve para identificar un elemento de la página. Actualiza la instantánea después de un cambio significativo en la página, en lugar de dar por hecho que la referencia anterior sigue siendo válida.

Las capacidades adicionales se activan de forma opcional. La tabla de opciones incluye vision, pdf y devtools; las secciones de herramientas también documentan expresamente config, network, storage y testing:

• PDF: --caps=pdf añade browser_pdf_save.
• Evidencias para depuración: --caps=devtools incluye trazas, video, grabación de acciones, anotaciones, resaltado y reanudación de la ejecución pausada. Por ejemplo, browser_start_tracing y browser_stop_tracing delimitan la captura de una traza.
• Aserciones: --caps=testing añade browser_generate_locator, browser_verify_element_visible, browser_verify_list_visible, browser_verify_text_visible y browser_verify_value. Una aserción expresa qué condición debe cumplirse.
• Simulación de red: --caps=network añade browser_network_state_set, browser_route, browser_route_list y browser_unroute para probar el comportamiento sin conexión y simular solicitudes.
• Almacenamiento: --caps=storage añade funciones para inspeccionar y editar cookies, almacenamiento local y almacenamiento de sesión, además de browser_storage_state y browser_set_storage_state.
• Configuración efectiva: --caps=config añade browser_get_config.

Estos son los grupos documentados en el README; eso no garantiza que todos los clientes muestren de inmediato todas las herramientas. Si falta alguna, compara la lista de herramientas del paquete instalado y las capacidades habilitadas con lo que indica el README. Descripción completa de las herramientas

Tres tareas útiles para un negocio

Da prioridad a los recorridos en los que un fallo impide vender o evita que un cliente se comunique contigo. Los siguientes son flujos de trabajo propuestos, no afirmaciones sobre ahorros medidos.

Comprueba el recorrido hasta el pago

Quien desarrolla una tienda podría pedirle al agente que recorra la compra como invitado en un entorno de pruebas, compruebe que el artículo elegido llega al carrito, rellene datos de envío ficticios y se detenga antes de efectuar un pago real. El beneficio es detectar un error que bloquea la compra antes de que lo encuentre un cliente.

Otra tarea útil para el mismo equipo es comprobar la recuperación tras un error: enviar datos de envío incompletos, verificar que el mensaje de error se entienda, corregirlos y comprobar que el cliente pueda continuar. Probar solo el recorrido sin errores deja fuera a quien se equivoca al rellenar un campo.

Revisa el sitio después de un despliegue

Si acabas de publicar un cambio en una landing page de tu negocio, puedes pedirle al agente que abra la versión desplegada, siga la llamada a la acción principal y compruebe que llega a la página de registro o contacto prevista. Pídele evidencias de la página y cualquier salida relevante de la consola o de las solicitudes fallidas.

Después, un desarrollador de una agencia podría probar un área visible más estrecha y repetir la navegación. Así podría descubrir un menú oculto o un botón inaccesible. La captura de pantalla es material para revisar, no un certificado automático de calidad visual.

Prueba los formularios con datos ficticios

Un desarrollador de SaaS podría comprobar los campos obligatorios, los mensajes de validación y la corrección de errores de un formulario de registro sin inicio de sesión, en un entorno local o de pruebas. Debe detenerse antes de crear una cuenta real, o utilizar un destino diseñado exclusivamente para recibir envíos de prueba.

Un desarrollador de operaciones podría rellenar un formulario largo en un entorno de pruebas con datos sintéticos, comprobar las listas desplegables, los campos condicionales y la carga de un archivo de prueba antes de enviarlo a un endpoint simulado. Esto ayuda a descubrir errores en la correspondencia de campos sin transmitir datos de clientes ni activar un proceso real.

Ejemplo completo: una compra como invitado que no llega al pago

Encarga al agente una tarea acotada y exige evidencias que respalden su conclusión. Este es un ejemplo ilustrativo de principio a fin, con un defecto supuesto de forma deliberada. No es el informe de una prueba realizada en una tienda real.

La aplicación del ejemplo tiene un carrito para invitados, un formulario de envío y una página de pago. Por error, el formulario envía el campo de código postal como postal, mientras que el backend espera postalCode. Utiliza una aplicación de prueba local o en staging, sin inicio de sesión, con datos ficticios y sin conexión a un sistema de pagos real.

Dale al agente estas instrucciones y sustituye la URL entre corchetes por la de tu propia aplicación de prueba:

El aislamiento debe configurarse en el servidor mediante --isolated; mencionarlo solo en el prompt no configura el servidor.

En este ejemplo, el cuerpo de la solicitud contiene postal y la respuesta señala que falta postalCode. Eso respalda la hipótesis de un error en la correspondencia de campos. Aun así, el desarrollador debe revisar la serialización del formulario y el contrato del backend antes de dar por corregida la causa raíz.

Ejemplo de informe del agente:

El siguiente paso es corregir la correspondencia de campos y repetir tanto el recorrido con datos no válidos como el que utiliza datos válidos. Una vez confirmado el comportamiento, pide al agente que prepare una prueba de regresión en Playwright, revisa sus aserciones y añádela al ejecutor de pruebas que ya utilizas. Ese último paso forma parte de tu proceso de ingeniería; la conversación con MCP, por sí sola, no constituye una batería de pruebas de regresión.

Dónde puede fallar y a qué tiene acceso el agente

Las comprobaciones menos fiables son las que parten de un objetivo impreciso o de un entorno inseguro. «Revisa el proceso de compra» deja que el agente invente los criterios de éxito. «Comprueba que unos datos de envío válidos permitan llegar a la página de pago, sin efectuar el pago» sí permite evaluar el resultado.

Ten en cuenta estos límites prácticos:

• Estructura de página ambigua: Los controles sin nombre y las interfaces basadas en gran medida en canvas hacen que el directorio estructural resulte menos útil. Recomiendo corregir las etiquetas accesibles cuando la aplicación sea tuya y recurrir a evidencias visuales cuando la estructura no baste.
• Cambios de estado: Un nuevo renderizado, una ventana emergente o una transición con retraso pueden invalidar lo que el agente espera encontrar a continuación. Inspecciona el estado resultante y espera al texto o la transición previstos antes de continuar.
• Conflictos entre perfiles: Un perfil persistente solo puede utilizarse en una instancia de navegador a la vez. Microsoft recomienda sesiones aisladas o valores distintos de --user-data-dir para clientes simultáneos que compartan un espacio de trabajo.
• Diferencias entre entornos: La implementación de Docker del README solo admite Chromium en modo headless. No des por hecho que todas las opciones de navegador de la tabla general de la CLI funcionan en ese contenedor.
• Cobertura incompleta: Llegar a una página no demuestra que funcionen todas las validaciones, los navegadores, los dispositivos o los resultados del backend. Una captura de pantalla tampoco puede demostrar que un pedido se haya guardado correctamente. Son límites del flujo de comprobación propuesto.

Las restricciones de perfiles y Docker están documentadas en el README de Microsoft.

El acceso al navegador es acceso real. Microsoft afirma expresamente que Playwright MCP no constituye una barrera de seguridad. El perfil predeterminado conserva el estado del navegador; la extensión opcional de Chrome/Edge puede conectarse a pestañas existentes y a sesiones con cuentas abiertas. Para las tareas de este artículo, utiliza una sesión aislada, sin cookies importadas ni conexión con tu navegador de uso diario. Comportamiento de los perfiles y la extensión

El agente puede solicitar páginas accesibles desde el entorno del navegador. Según tu red, eso puede incluir servidores de desarrollo o servicios internos, además de sitios públicos. Las reglas de origen no sustituyen al aislamiento de red: --allowed-origins y --blocked-origins no restringen las redirecciones y se indica expresamente que no constituyen una barrera de seguridad. --allowed-hosts se refiere a la validación del host en las solicitudes entrantes al servidor MCP; no es una lista de los sitios web que puede visitar el navegador. Configuración y seguridad

El acceso a archivos exige el mismo cuidado. La configuración predeterminada documentada restringe los archivos a las raíces del espacio de trabajo y bloquea la navegación a file://, mientras que --allow-unrestricted-file-access relaja esas reglas. Microsoft describe las comprobaciones de archivos como medidas preventivas, no como un aislamiento seguro. Más delicado aún: browser_run_code_unsafe ejecuta JavaScript en el proceso del servidor, con el alcance de ese proceso. Controla esa herramienta mediante los permisos del cliente y restringe el entorno del servidor. Esquema de configuración y herramientas

Las capturas de pantalla, el texto de las páginas, la salida de la consola y los cuerpos de las solicitudes pueden exponer datos al agente. Utiliza registros ficticios y endpoints exclusivos para pruebas. Detente antes de efectuar un cobro real, enviar un mensaje, crear una cuenta o realizar cualquier otro envío con consecuencias, salvo que esa acción concreta esté autorizada expresamente.

¿Playwright MCP, Chrome DevTools MCP o Browserbase?

Elige según la tarea y el lugar donde deba ejecutarse el navegador. Estos productos tienen funciones en común, pero no son componentes intercambiables.

Microsoft también ofrece --cdp-endpoint para conectarse a un endpoint de navegador. Por eso, la interfaz que utiliza tu agente y el lugar donde se ejecuta el navegador son decisiones independientes. Browserbase no es otro nombre para el servidor de Microsoft. Nuestra guía de los mejores navegadores para agentes de IA aborda esa elección más amplia.

Cuánto cuesta la automatización de pruebas y qué podrías crear

La comparación de costes útil es la que enfrenta tu proceso de comprobación actual con el flujo automatizado completo. El repositorio de Playwright MCP tiene licencia Apache; instalarlo no te proporciona el modelo del agente, los recursos de cómputo, los escenarios de prueba ni la revisión humana.

Haz el cálculo con tus propias cifras:

• Antes: horas de comprobación manual × tu coste total por hora, más las suscripciones de pruebas que ya utilices.
• Después: uso del agente + infraestructura del navegador + revisión humana + mantenimiento de los escenarios y las pruebas.

Como referencia concreta de alojamiento, Browserbase anuncia su plan Developer a $20/mes con 100 horas de navegador y, después, $0.12 por hora de navegador. Son cargos de infraestructura del navegador, no el precio completo de una prueba de compra realizada por un agente. Precios de Browserbase

La oportunidad más sólida: un servicio de pruebas de aceptación tras cada despliegue

Una agencia pequeña podría ofrecer la revisión de recorridos de cliente acordados después de cada despliegue del cliente. La versión mínima útil recibe una URL del entorno de pruebas y una lista de criterios de aceptación, ejecuta los recorridos permitidos sin inicio de sesión y entrega un informe revisado, con evidencias y lagunas de cobertura explícitas. El cliente paga por que alguien se responsabilice de comprobar la nueva versión.

La señal de demanda es modesta: las estimaciones de palabras clave en inglés para Estados Unidos de DataForSEO, consultadas en octubre de 2026, muestran 110 búsquedas mensuales de “automated browser testing” y 10 de “checkout testing”. Miden búsquedas, no compradores. Respaldan la idea de probar un servicio especializado con clientes actuales antes de invertir en un producto de software de mayor alcance.

La dificultad está en el mantenimiento: los recorridos que cambian, las aserciones ambiguas y las falsas alarmas pueden consumir el trabajo que esperabas ahorrar. Lo que aporta una ventaja defendible es una lista de aceptación útil y una evaluación fiable de los fallos, no instalar el mismo servidor MCP público que puede instalar cualquiera.

Segunda oportunidad: un verificador de formularios en entornos de pruebas

Una agencia web podría crear un verificador que rellene formularios con valores sintéticos, provoque errores de campos obligatorios y compruebe que, tras corregir los datos, el envío llegue a un destino simulado. Conviene empezar por los formularios de los sitios que la agencia ya mantiene y por un informe que permita a un desarrollador reproducir lo ocurrido.

El mismo conjunto de datos de DataForSEO para búsquedas en inglés en Estados Unidos estima 10 búsquedas mensuales de “website form testing”. Por sí sola, es una señal débil para captar clientes. Mi propuesta es venderlo como complemento del mantenimiento web y validar después si existe demanda recurrente antes de crear un producto independiente.

La dificultad está en el sistema receptor. Que una página parezca confirmar el éxito no demuestra que los datos de un cliente potencial hayan llegado a su destino. El MVP necesita un endpoint de prueba u otra vía autorizada para verificar la recepción, además de las evidencias del navegador.

Preguntas frecuentes al configurar Playwright MCP

Tu tarea para el lunes: elige el recorrido sin inicio de sesión más cercano a generar ingresos, escribe el resultado esperado y el punto donde debe detenerse, y pide al agente de programación que ya utilizas que lo compruebe en el entorno de pruebas. Revisa las evidencias con el desarrollador responsable de ese flujo antes de ampliar el alcance.

Si quieres un flujo de comprobación en navegador adaptado a tu proceso de despliegue, desarrollamos agentes de IA para los procesos de tu negocio.