chrome-devtools-mcp : les Chrome DevTools mis en serveur MCP pour les agents de code
Ce serveur MCP permet aux agents de code de contrôler et d'inspecter un navigateur Chrome actif via les DevTools, pour le débogage, l'analyse des performances et l'automatisation avec Puppeteer.
En bref
- De quoi s’agit-il ?
- Analyse de chromedevtools/chrome-devtools-mcp : pilotage et inspection d'un Chrome vivant par MCP, traces de performance, réseau et console sourcemappée, mode slim, télémétrie à désactiver explicitement.
- À qui s’adresse-t-il ?
- chrome-devtools-mcp s'adresse aux développeurs qui veulent qu'un agent débogue, mesure ou automatisse un vrai navigateur Chrome, avec la garantie du moteur DevTools plutôt qu'une émulation ; il ne couvre officiellement ni les autres navigateurs Chromium ni les usages non supervisés, le contenu du navigateur étant exposé au client MCP.
- Puis-je l’utiliser commercialement ?
- Oui. Apache-2.0 est une licence permissive : vous pouvez utiliser, modifier et vendre un logiciel qui en dépend, à condition de conserver les mentions de droit d’auteur et de licence.
- Est-il encore maintenu ?
- Oui. Le dépôt a reçu de nouveaux commits au cours des dernières 24 heures.
- En quel langage est-il écrit ?
- Principalement TypeScript, d’après les statistiques de langage de GitHub.
Ces réponses reposent sur les données GitHub du projet (dernière synchronisation le 15 septembre 2026) et sur notre analyse. Elles ne constituent pas un avis juridique.
ANALYSE OPEN SOURCE APPROFONDIE
Un serveur MCP officiel, signé l'équipe des DevTools, avec CLI en option
chrome-devtools-mcp permet à un agent de code, Antigravity, Claude, Cursor ou Copilot cités, de contrôler et d'inspecter un Chrome en cours d'exécution. Le serveur agit comme passerelle Model Context Protocol et donne accès aux capacités des Chrome DevTools pour l'automatisation, le débogage approfondi et l'analyse de performance. Une CLI est aussi fournie pour les mêmes usages sans MCP, documentée dans docs/cli.md.
La provenance pèse dans l'évaluation : le projet vient de l'organisation ChromeDevTools, avec 49922 étoiles et 3501 forks au moment de l'indexation, et un rythme de releases mensuel, v1.6.0 en juillet 2026, v1.7.0 en août, v1.8.0 le 25 août. L'automatisation s'appuie sur Puppeteer avec attente automatique du résultat des actions, ce qui attaque directement la fragilité chronique des scripts de navigateur pilotés par un modèle.
Traces, requêtes réseau et console sourcemappée : ce que l'agent regarde
Trois familles d'outils structurent l'offre. Les insights de performance enregistrent des traces via le moteur DevTools et en extraient des pistes actionnables. Le débogage couvre l'analyse des requêtes réseau, les captures d'écran et la lecture des messages de console, avec stack traces alignées sur les sources via les source maps.
Cette dernière précision a plus de valeur qu'il n'y paraît : un agent qui lit une pile d'erreurs minifiée s'égare, tandis qu'une pile sourcemappée renomme les fichiers et lignes d'origine, rendant le diagnostic automatisé crédible. La référence exhaustive des outils vit dans docs/tool-reference.md, avec une version séparée pour le mode slim, et un journal des changements suit les ajouts version par version.
Télémétrie activée par défaut : les drapeaux et variables qui la coupent
Le README est explicite : Google collecte des statistiques d'usage, taux de succès des invocations d'outils, latences, informations d'environnement, et cette collecte est activée par défaut. La désactivation passe par le drapeau --no-usage-statistics au démarrage du serveur, ou par les variables d'environnement CHROME_DEVTOOLS_MCP_NO_USAGE_STATISTICS ou CI.
Deux précisions complètent le tableau. Cette collecte est indépendante de celle du navigateur Chrome : refuser les métriques de Chrome ne vous désinscrit pas de celles de l'outil, et inversement. Par ailleurs, les outils de performance peuvent envoyer des URL de traces à l'API CrUX de Google pour rapprocher données de laboratoire et données de terrain, désactivable par --no-performance-crux. Les vérifications de mise à jour vers le registre npm se coupent aussi, par CHROME_DEVTOOLS_MCP_NO_UPDATE_CHECKS. Pour un environnement d'entreprise, ces quatre commutateurs se règlent avant le premier lancement.
--slim et --headless : réduire la surface d'outils aux tâches de base
Pour les tâches de navigation ordinaires, le README propose un mode --slim qui restreint le jeu d'outils exposés, illustré avec --headless pour tourner sans fenêtre. Sa référence d'outils distincte, docs/slim-tool-reference.md, permet de savoir exactement ce que cette configuration conserve ou retire.
Le choix est intéressant pour deux raisons. La première est opérationnelle : moins d'outils signifie moins d'ambiguïté pour le modèle, qui choisit parmi un menu plus court, et un contexte plus léger. La seconde est sécuritaire : un agent de rédaction qui n'a pas besoin d'inspecter le réseau n'a pas à recevoir cet outil. Le mode complet reste disponible pour le débogage approfondi, et le passage de l'un à l'autre ne change qu'une ligne d'arguments dans la configuration du client MCP.
Se brancher sur un navigateur existant : --browser-url et le port 9222
Au lieu de lancer son propre Chrome, le serveur peut se connecter à une instance existante via --browser-url, l'exemple d'Antigravity visant http://127.0.0.1:9222, le port de débogage habituel de Chrome. Dans cette configuration, le serveur ne démarre pas le navigateur : il se branche sur celui qu'Antigravity utilise déjà, et s'il n'est pas lancé, l'utilisateur doit d'abord démarrer Chrome depuis l'interface.
Ce mode change la nature du partage : l'agent travaille dans la session ouverte, avec ses profils, ses connexions et ses onglets, plutôt que dans un navigateur jetable. Les deux régimes ont leurs usages, l'inspection d'un état réel authentifié d'un côté, l'automatisation reproductible de l'autre. Le README ne documente pas de verrouillage de périmètre sur cette voie, l'agent voyant la fenêtre entière, ce qui rejoint l'avertissement général sur le contenu exposé aux clients MCP.
Pour Claude Code : un serveur MCP simple ou un plugin avec skills
Deux routes existent pour Claude Code. La première ajoute le serveur MCP seul par la CLI : claude mcp add chrome-devtools --scope user npx chrome-devtools-mcp@latest. La seconde installe un plugin complet, MCP et skills, en enregistrant d'abord le marché par /plugin marketplace add ChromeDevTools/chrome-devtools-mcp puis en installant le plugin correspondant.
Le README précise de retirer toute installation antérieure avant de passer au plugin, pour éviter les doublons de serveurs. La différence entre les deux voies dépasse la commodité : le plugin embarque des skills, donc des procédures enseignées à l'agent sur l'usage des outils DevTools, quand la configuration MCP nue laisse le modèle découvrir les outils seul. Les configurations pour Amp, avec amp mcp add, pour Bob d'IBM, avec ~/.bob/mcp.json rechargé à chaud, et pour les autres clients suivent dans le README.
Chrome stable uniquement : le périmètre de support assumé
Le support officiel couvre Google Chrome et Chrome for Testing, les autres navigateurs basés sur Chromium pouvant fonctionner sans garantie, avec la mention habituelle d'usage à vos risques. L'équipe s'engage sur les correctifs pour la dernière version de Chrome Extended Stable. Les prérequis sont Node.js en version LTS, npm, et un Chrome stable courant.
La configuration d'exemple utilise chrome-devtools-mcp@latest, ce qui garantit la dernière version mais sacrifie la reproductibilité : un agent qui change de comportement après une mise à jour silencieuse du serveur se débogue plus difficilement. Le rythme mensuel des releases, avec v1.8.0 sortie le 25 août 2026 et 94 tickets ouverts, rend cet arbitrage concret. Le parcours d'entrée conseillé reste de démarrer en --slim --headless, de vérifier que vos tâches passent avec ce jeu restreint, puis d'élargir la surface uniquement là où le débogage l'exige.
Conclusion éditoriale
chrome-devtools-mcp s'adresse aux développeurs qui veulent qu'un agent débogue, mesure ou automatisse un vrai navigateur Chrome, avec la garantie du moteur DevTools plutôt qu'une émulation ; il ne couvre officiellement ni les autres navigateurs Chromium ni les usages non supervisés, le contenu du navigateur étant exposé au client MCP. Avant l'adoption, démarrez avec --slim --headless pour circonscrire la surface d'outils, ajoutez --no-usage-statistics si votre politique l'exige, puis lisez docs/tool-reference.md et figez une version plutôt que @latest.
Notes de la communauté