Serveurs MCP (2/2) : comment doper votre agent IA avec des serveurs MCP ?
Dans cette faq, nous verrons comment doper votre agent IA en utilisant le MCP avec un exemple de configuration d'un serveur MCP et les fabuleuses possibilités que cela nous ouvre, à nous, consultants AMOA web mais aussi à vous très chers internautes !
Si vous ne voyez pas ce qu'est le MCP, c'est que vous n'avez pas encore lu notre faq qui explique ce qu'est un serveur MCP.
Nous allons utiliser la célèbre librairie de test Playwright pour automatiser un test de connexion dans notre univers de développement.
Jusqu'à présent, les IA nous permettaient d'écrire les tests plus facilement mais avec les serveurs MCP, nous pouvons faire de Claude Code une sorte "d'assistant de recette".
Exemple d'utilisation d'un serveur MCP : Claude Code (CC) et le serveur MCP de Playwright.
Prérequis : vous devez avoir la dernière version LTS de node.js et installé Claude Code.
D'abord installer le serveur MCP de Playwright dans CC. Pour cela, dans votre projet lancer la commande sur votre terminal :
cd votreProjet
claude mcp add playwright npx @playwright/mcp@latest
Note importante : si vous utilisez nvm pour jongler entre les versions de node.js, supprimez toutes les versions pour ne garder que la dernière LTS v22.16.0. En effet, les serveurs MCP ont encore du mal à gérer les versions de node et ils prennent souvent la plus vieille de vos versions.
Lancer CC et vérifiez que le serveur est bien connecté :
claude
/mcp
Résultat : 
Maintenant nous allons tester notre login à l'application. Voici l'interface de login que nous avons développée :
Demandons maintenant à CC de tester avec un de nos utilisateurs de test :
>> avec playwright, test le login sur la page http://localhost:3001/write/identify avec un utilisateur [XXX] mot de passe [YYY]
Note 1 : remplacez [XXX] et [YYY] par un login et mot de passe de test
Note 2 : en nommant l'outil (agentic tool) "avec playwright", CC comprend qu'il doit utiliser le MCP.
Claude va nous proposer un plan d'action et vous n'avez qu'à le suivre en acceptant :
Update Todos
⎿ ☐ Navigate to login page http://localhost:3001/write/identify
☐ Enter [XXX]
☐ Enter password [YYY]
☐ Submit login form
☐ Verify successful login
Résultat de CC :
⏺ ✅ Test de connexion réussi!
L'utilisateur avec l'email [XXX] et le mot de passe [YYY] s'est connecté avec succès. Après la connexion :
- Redirection automatique vers la page des sites (/write/sites)
- Message de connexion affiché: "Logged in as [XXX]"
- Accès au menu admin avec les options: Owners, Sites, Tests
Maintenant essayons avec un mauvais mot de passe. Le test ne passe plus :
⏺ ❌ Échec de connexion avec mot de passe incorrect!
Avec l'email [XXX] et le mot de passe [ZZZ] (incorrect):
- La page reste sur /write/identify
- Message d'erreur affiché: "Password or username is incorrect"
- L'utilisateur n'est pas connecté et doit réessayer
Maintenant j'aimerais pouvoir rejouer simplement mes tests. J'ai deux possibilités : à l'ancienne, je regroupe mes tests sous forme de fichiers que je peux rejouer, et puis la nouvelle : je créé une commande dans Claude pour qu'il rejoue mon test quand je veux.
Commençons par l'ancienne méthode :
fais un répertoire de test et ajoute un fichier de test de connexion, met les identifiants dans le fichier .env pour ne pas qu'ils soient commités et ajoute une commande au package.json pour lancer les tests
On teste notre test :
npx playwright install
npm run test
Là un développeur le mettrait dans son workflow CI/CD mais un consultant AMO qui veut tester du code ou faire une recette end to end (e2e) automatisée a plus malin à faire !
Maintenant la nouvelle méthode : dans votre répertoire taper les commandes suivantes :
mkdir -p .claude/commands
touch .claude/commands/login-test.md
vi .claude/commands/login-test.md
et coller ce texte :
1. **Ask for credentials** - Request email, valid password, and invalid password from the user
2. **Navigate to login page** at `http://localhost:3001/write/identify`
3. **Test successful login** - Use provided valid credentials and verify redirect to `/write/sites`
4. **Test failed login** - Use invalid password and verify error message "Password or username is incorrect"
5. **Test form validation** - Submit empty form and verify it stays on login page
6. **Test Remember Me checkbox** - Verify checkbox exists and can be checked/unchecked
The test results should be reported with:
- ✅ for passed tests
- ❌ for failed tests
- Summary of all test results
**Important**: Never store credentials except if needed in .env file. Always ask the user to provide them when running tests.
Revenez dans Claude Code et lancez la commande : tapez / pour avoir la liste des commandes disponibles :
Executez la commande login-test et laissez Claude travailler.
Les petites hallucinations
Vous avez vu que j'ai insisté pour qu'il ne mette pas les identifiants dans le code mais uniquement dans le .env. Ainsi ils ne seront pas commités et CC m'a bien assuré qu'ils n'y étaient pas. Seulement une petite recherche dans le code nous donne cela :
~/Projects/node/qodqa/tests/e2e/login.spec.js:
6
7 // Get credentials from environment variables
8: const validEmail = process.env.TEST_USER_EMAIL || 'XXX';
9 const validPassword = process.env.TEST_USER_PASSWORD || 'YYY';
10 const invalidPassword = process.env.TEST_INVALID_PASSWORD || 'ZZZ';
A la place des XXX, YYY et ZZZ, il a mis les identifiants de tests en dur comme valeur par défaut dans le fichier javascript, qui lui sera commité.😱😱😱
Autre hallucination de CC, bien moins grave car il nous détaille bien ses tests : il a ajouté un test sur la case 'se souvenir de moi' sans que je lui demande. C'est pas bête mais son test n'est pas pertinent, il ne regarde pas si le cookie est déposé, juste si on peut cliquer sur la case... et moi je sais que cela ne marche pas cette fonctionnalité !
Il a aussi ajouté un test pour vérifier que les champs devaient être remplis. Pas bête, mais incomplet : il teste avec des champs vides mais logiquement nous devrions tester aussi les combinaisons d'un champ nul et pas l'autre.
Note pour cet exemple j'ai utilisé Sonnet 4 alors que Opus 4.1 aurait peut être évité cette coquille.
Conclusion
Ici avec un exemple de recette automatisée par AI on voit toute la puissance que cela peut apporter mais en même temps l'agent commet encore des erreurs qu'une meilleure configuration pourra sans aucun doute minimiser.
Références :
Crédit photo Renaud Bessieres