Cypress MCP : quand l'agent IA lance lui-même les tests E2E

Le chaînon manquant

Un agent de code écrit aujourd'hui un test Cypress correct en quelques secondes. Ce qu'il ne sait pas faire, c'est le lancer.

Pendant des mois, nos journées ont donc ressemblé à ceci. L'agent écrit le test. Je lance npx cypress run, j'attends, je copie la sortie du terminal dans la conversation. L'agent corrige, je relance. Le développeur était devenu le presse-papiers de l'agent.

Ce n'était pas seulement lent. L'agent travaillait sur ce que je voulais bien lui coller : la fin d'une pile d'appels, sans la capture d'écran, sans le code autour de la ligne qui casse, sans savoir si le test avait échoué une fois ou trois.

Ce que fait cypress-mcp

Le Model Context Protocol (MCP) est le standard qui permet à un agent comme Claude Code, Cursor ou Windsurf d'appeler des outils externes. cypress-mcp est un serveur MCP qui expose Cypress sous forme de douze outils. Les plus utilisés tiennent en une boucle :

• cypress_run_spec lance une spec sans interface et renvoie un résultat structuré.
• cypress_run_test lance un seul test, désigné par son nom.
• cypress_get_failure_context rassemble l'erreur, la pile, l'extrait de la spec et les captures.
• cypress_rerun_last rejoue exactement la dernière exécution, après une correction.

Chaque réponse suit la même enveloppe. Voici, simplifié, ce que l'agent reçoit après un échec :

{
  "ok": true,
  "tool": "cypress_run_spec",
  "summary": "1 failing, 3 passing in cypress/e2e/checkout.cy.ts (1 flaky)",
  "data": { "stats": { "tests": 4, "passing": 3, "failing": 1, "flaky": 1 } },
  "nextActions": ["cypress_get_failure_context"]
}

ok vaut true parce que l'outil a fonctionné, même si un test a échoué. nextActions dit à l'agent quoi faire ensuite. Il n'a plus à le deviner.

Trois choses qu'un terminal ne dit pas à un agent

Un test instable n'est pas un test cassé. Cypress peut réessayer un test qui échoue. cypress-mcp compte les tentatives de chaque test et marque comme instable celui qui échoue puis passe, selon la même règle que Cypress Cloud. Sans cette information, un agent « corrige » un test qui n'avait rien de cassé.

Un échec a besoin de son contexte. Le message d'erreur seul ne suffit pas. L'outil de contexte renvoie la ligne de la spec qui casse avec ce qui l'entoure, et le chemin de la capture prise au moment de l'échec.

La boucle doit être courte. Rejouer la dernière exécution sans reconstruire les arguments, lancer un seul test plutôt que toute la spec : c'est ce qui rend l'itération supportable, pour un agent comme pour un humain.

Ce que la production nous a appris

Un outil qui exécute des commandes sur la machine d'un développeur, avec des arguments envoyés par un modèle, doit être écrit comme du code exposé à Internet. Trois leçons, toutes tirées de cas réels.

Sous Windows, la première version lançait Cypress à travers un shell. Un nom de test contenant & pouvait donc exécuter une commande. Cypress est désormais lancé directement par Node, sans shell, et un test passe exprès par une spec dont le nom contient & et une espace.

Cypress 16 a supprimé Cypress.env(), et @cypress/grep 7 lit maintenant son filtre ailleurs. Sans adaptation, demander « lance seulement ce test » aurait lancé toute la spec, sans la moindre erreur. Une régression silencieuse est le pire cas pour un agent : il croit avoir vérifié ce qu'il n'a pas vérifié. Depuis, une suite de bout en bout pilote un vrai projet Cypress, en version 14 et en dernière version, sous Linux et Windows, à chaque modification et chaque semaine.

Enfin, un chemin de spec qui sort du projet est refusé, et la clé d'enregistrement Cypress Cloud ne transite jamais par l'agent. Elle reste dans l'environnement du serveur.

Et le Cypress Cloud MCP ?

Cypress a lancé son propre serveur MCP, gratuit sur tous les plans de Cypress Cloud. Il ne fait pas la même chose. Il interroge l'historique des exécutions déjà enregistrées : tests en échec, tests instables, rapports d'accessibilité, couverture de l'interface.

cypress-mcp exécute les tests sur la machine du développeur, avant que quoi que ce soit ne soit enregistré. Les deux se complètent. Lancez une exécution avec l'option d'enregistrement : cypress-mcp renvoie l'URL du run, et les outils Cypress Cloud l'acceptent directement pour retrouver le Test Replay. Nos noms d'outils ne recoupent jamais les leurs, et un test le vérifie.

Pourquoi Apache 2.0

cypress-mcp a d'abord été un outil interne à nos équipes, publié ensuite sous une licence qui réservait l'usage commercial. En octobre 2026, une équipe d'ingénierie qui voulait l'adopter nous a demandé si elle avait besoin d'une licence commerciale pour un usage purement local.

La bonne réponse était de supprimer la question. Depuis la version 0.2.0, cypress-mcp est sous licence Apache 2.0, usage commercial et CI compris. Notre métier est de concevoir des logiciels et des suites de tests pour nos clients, pas de vendre des licences d'outillage. Un outil adopté par d'autres équipes nous apprend davantage qu'une redevance.

L'installer

Avec Claude Code, une ligne suffit :

claude mcp add cypress-mcp -- npx cypress-mcp --cwd /chemin/vers/le/projet

Pour Cursor, VS Code ou Windsurf, la même commande se déclare dans la configuration MCP du client. Il faut Node.js 22.12 ou plus récent, et Cypress 12 à 16 installé dans le projet. Pour lancer un seul test par son nom, ajoutez @cypress/grep. Le code source et la documentation sont sur GitHub.

Ce qui reste le travail d'un ingénieur

Un agent qui lance ses propres tests n'est pas un ingénieur QA. Il ne sait pas quels parcours méritent d'être protégés. Il ne sait pas qu'une assertion sur un libellé cassera à la prochaine traduction. Et un test vert ne lui dit pas s'il a vérifié la bonne chose.

Le gain est ailleurs : l'ingénieur ne sert plus de presse-papiers. Il relit des tests qui passent déjà et consacre son temps à ce qui demande du jugement. Les quatre règles qui décident si une suite survit, des sélecteurs stables, des tests indépendants, des données maîtrisées et une exécution rapide, sont détaillées dans notre comparatif Cypress ou Playwright.

Pour mettre cela en place dans votre équipe, ou pour un ingénieur QA qui le porte, voici ce que nous proposons. Le projet lui-même est décrit sur sa page de référence.