Install
npx -y @modelcontextprotocol/server-puppeteerÀ qui s’adresse
Pour celles et ceux qui ont besoin qu’un modèle ouvre des pages web dans un vrai navigateur local, lise la console ou laisse des captures. Les preuves indiquent : c’est un serveur MCP d’automatisation de navigateur avec Puppeteer ; le modèle peut interagir avec les pages, prendre des captures et exécuter du JavaScript dans un vrai navigateur.
Il tourne sur votre machine, donc il peut aussi atteindre des fichiers locaux et des IP locales/internes. Ne vous connectez que si vous acceptez cette frontière de confidentialité et pouvez surveiller les données sensibles. Les preuves ne listent aucun client ; la couverture s’arrête à : vous avez déjà un client capable de configurer MCP et pouvez exécuter npx.
La page officielle se trouve sous l’arbre servers-archived. Les preuves n’indiquent pas à part l’état de maintenance ni un remplacement ; ne le traitez pas comme un produit actuel encore mis à jour.
Réussir le premier essai en 3 minutes
Suivez le chemin NPX donné par les preuves. Dans la configuration MCP du client, utilisez :
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-puppeteer"]
Ne prenez pas Docker comme second chemin principal en même temps. Les preuves n’ajoutent que : Docker utilise Chromium sans tête ; NPX ouvre une fenêtre de navigateur.
Préconditions : Node/npx est installé localement ; le premier essai n’ouvre qu’une page publique à laquelle vous avez droit, sans formulaire ni connexion. Après le démarrage, un navigateur tourne sur cette machine et peut accéder à des fichiers locaux et adresses internes.
Emplacement de configuration : la configuration serveur MCP du client (commande et arguments stdio). Après enregistrement, redémarrez ou rechargez le client.
Premier appel à faible risque : n’appelez que puppeteer_navigate, pleinement écrit dans les preuves, et naviguez vers l’URL venant d’être citée. Les preuves ne donnent pas les champs de paramètres ; le résumé collect mentionne aussi screenshot, click, hover, fill, select, evaluate, mais ces locators ne sont pas développés — ne les appelez pas au premier essai.
Signal de succès : sur le chemin NPX, une fenêtre de navigateur locale doit s’ouvrir et rester sur l’adresse donnée. Ensuite vous pouvez lire la ressource console://logs (sortie console texte) ou screenshot://<name> (PNG). Si aucune fenêtre n’apparaît, confirmez d’abord que vous êtes en NPX, pas Docker.
Cas d’usage
Cas 1 : Faire ouvrir au modèle une page publique précisée. Appelez puppeteer_navigate. Les preuves garantissent seulement « naviguer vers n’importe quelle URL dans le navigateur » ; pas de délai, de redirection, ni d’envoi des cookies locaux. Ce que vous pouvez confirmer : la navigation a lieu dans un vrai navigateur local ; ne supposez pas une session cloud isolée.
Cas 2 : Après ouverture, vérifier la console ou laisser une capture. La première preuve indique captures et exécution JavaScript ; les preuves de ressources donnent console://logs (tous les messages console du navigateur) et screenshot://<name> (PNG d’une capture). Les preuves ne nomment pas d’outil de capture, n’expliquent pas <name>, ni les paramètres d’evaluate. La deuxième étape ne lit donc que ces ressources, ou s’arrête à « les preuves ne garantissent que capture/JS » — n’inventez ni sélecteurs ni scripts.
Limites d’usage
Un navigateur local peut accéder aux fichiers locaux et aux IP locales/internes et emporter des données sensibles. NPX ouvre une fenêtre visible ; Docker utilise Chromium sans tête. Les comportements diffèrent ; ne les mélangez pas pour ensuite prendre une fenêtre comme signal de succès. Le seul outil pleinement nommé est puppeteer_navigate ; les capacités d’interaction (clic, saisie) n’ont pas de locator paramétré et ont des effets de bord. Les ressources ne listent que console et captures ; pas d’annulation, de nettoyage de cookies ni de fermeture du navigateur. Les preuves ne donnent ni liste de clients, ni modèle de permissions, ni paquet de remplacement après archivage.