El Model Context Protocol (MCP) es la habilidad que le das a tu agente de Cursor para comunicarse con APIs de terceros y ejecutar tareas reales fuera del editor. Aquí aprendes a configurarlo con Playwright para correr end-to-end testing sobre tu plataforma de cursos y documentar ese proceso con Gherkin, sin escribir código manualmente.
Cómo conectar páginas internas antes de activar el MCP
Antes de meterte con Playwright, conviene revisar la navegación interna de tu app. Si la landing de cursos no enlaza con el detalle del curso, ni el curso con la clase, el flujo de pruebas se rompe.
La forma de resolverlo es pasarle al agente el contexto completo de la página y un ejemplo claro de cómo construir cada enlace. Le compartes la URL de la landing del curso, la URL de una clase y le pides que genere los links desde la página correspondiente.
¿Qué pasa si el agente usa el ID en vez del slug? El enlace falla porque la ruta del curso espera un slug. Le das feedback directo en el chat indicando que la URL funciona con slug y el agente ajusta el código sin que tengas que tocarlo.
El objetivo es que tú no codees: el agente importa el componente Link de Next.js, modifica el archivo correcto (en este caso Course Detail) y deja la navegación lista [01:30].
Qué es el Model Context Protocol y cómo instalarlo en Cursor
Un MCP es un puente entre tu agente y servicios externos. Existen integraciones oficiales y de la comunidad, y la recomendación es revisar siempre quién creó el MCP antes de instalarlo, porque le estás dando acceso a tu proyecto y, en algunos casos, a tu sistema de archivos.
Para este flujo se usa el MCP oficial de Playwright, pensado para automatización de navegador y pruebas de extremo a extremo.
Dónde se configura el MCP en Cursor
La instalación se hace desde la configuración del editor:
- Abre File, Preferences, Cursor Settings.
- Entra al tab MCP Tools.
- Selecciona agregar uno custom.
- Pega dentro del objeto MCP Servers la configuración de Playwright que copias del repositorio oficial.
- Guarda y cierra.
Cursor ejecuta por detrás un comando npx que levanta el servidor. Si el indicador queda en rojo, apaga y vuelve a prender el MCP para recargar la configuración. Cuando todo está bien, verás el mensaje 31 tools enabled [04:45].
¿Qué son las tools de un MCP? Son funciones específicas que el agente puede invocar. En Playwright incluyen navegar a una URL, leer contenido visible, hacer clic y capturar el DOM, entre otras 31 acciones disponibles.
Cómo correr un end-to-end testing en lenguaje natural
Una vez instalado el MCP, abres un nuevo chat y le pasas un prompt en lenguaje coloquial. Por ejemplo: utilizando el MCP de Playwright, ve a esta URL y accede al curso de React. Luego, ve a la primera clase del curso y dime si puedes ver el reproductor de vídeo.
El agente pide permiso antes de ejecutar cada tool. Vas autorizando paso a paso:
- Navegación a la URL inicial.
- Lectura del contenido visible para validar que la landing cargó.
- Clic sobre el curso de React.
- Acceso a la primera clase.
- Verificación del reproductor de vídeo.
El resultado esperado es una respuesta como esta: al acceder al curso de React y entrar a la primera clase, se puede ver el reproductor. El HTML contiene un elemento video con controles y una fuente video. Eso confirma que el flujo end-to-end pasa correctamente [07:20].
Cómo documentar pruebas con Gherkin y Cucumber
Que una prueba funcione es solo la mitad del trabajo. La otra mitad es documentarla para poder repetirla sin escribir el prompt completo cada vez.
Aquí entra Cucumber, un framework de documentación de pruebas, y Gherkin, su sintaxis basada en palabras clave en inglés como Feature, Scenario, Given, When y Then. Esta sintaxis describe escenarios en formato legible tanto para humanos como para máquinas.
Cómo pedirle al agente que documente con Gherkin
Le compartes al agente la URL de la documentación oficial de Gherkin y le indicas: quiero que documentes el test utilizando Gherkin y guardes el archivo en source/docs. El agente:
- Lee la documentación de referencia.
- Traduce el test ejecutado a sintaxis Gherkin.
- Crea la carpeta docs dentro de source.
- Genera el archivo con el escenario completo.
El archivo resultante describe el Feature (visualizar el reproductor de la primera clase del curso de React), el rol del usuario y el escenario paso a paso: ir a la URL, seleccionar el curso de React y acceder a la primera clase [09:50].
¿Para qué sirve Gherkin si ya tengo el test funcionando? Sirve para reutilizar la prueba. La próxima vez le dices al agente corre estos end-to-end usando el MCP de Playwright apuntando al archivo, y no tienes que volver a escribir el flujo completo.
Reto: invertir el flujo de desarrollo
Ya viste el camino completo: desarrollo, pruebas y documentación. La pregunta interesante es si puedes hacerlo al revés. Documentar primero un escenario en Gherkin y pedirle al agente que escriba el código y genere las pruebas a partir de esa especificación.
Es el espíritu del Behavior Driven Development. Investígalo, pruébalo en tu proyecto y cuéntame en los comentarios cómo te fue.
