Playwright MCP : effectuer la première navigation du navigateur dans le client

À qui cela s'adresse

Ce guide s'adresse aux personnes qui utilisent déjà un client MCP et qui sont prêtes à lancer un navigateur sur cette machine pour automatiser des pages. Il s'agit de décider s'il faut brancher Playwright MCP sur le client actuel tout de suite, et non de lire d'abord une longue présentation. La condition la plus stricte est que Node.js local soit en version 18 ou plus récente ; si la version est insuffisante, il ne faut pas continuer à écrire la configuration. Le dépôt le décrit comme un serveur MCP qui fournit une automatisation de navigateur et comprend les pages via des instantanés d'accessibilité, pas via des captures d'écran. Deux points doivent être acceptés : des processus liés au navigateur apparaîtront sur cette machine, et de vraies visites seront effectuées vers les adresses indiquées. Si l'objectif est seulement de parcourir le dépôt, sans faire exécuter d'action navigateur par le client, ce chemin ne convient pas. Les éléments disponibles ne mentionnent ni secteur, ni poste, ni taille d'équipe ; aucun portrait d'utilisateur imaginaire n'est ajouté ici.

Première tentative en 3 minutes

N'utiliser que le chemin officiel de configuration MCP standard. Ouvrir l'emplacement de configuration des serveurs du client MCP déjà en usage — aucun nom de fichier précis n'est donné, donc passer par l'entrée de réglages MCP de ce client — et ajouter un service nommé playwright, commande npx, argument @playwright/mcp@latest. Ne pas juxtaposer une deuxième méthode d'installation principale.

Vérifier d'abord que la machine satisfait Node.js 18 ou plus récent, puis écrire le JSON ci-dessous dans la configuration tel quel, à l'identique octet par octet, sans changer les noms de clés ni les espaces :

{
  "mcpServers": {
    "playwright": {
      "command": "npx",
      "args": ["@playwright/mcp@latest"]
    }
  }
}

Enregistrer, puis redémarrer ou recharger ce client. Le signal de succès est l'apparition des noms browser_navigate et browser_navigate_back dans la liste des outils. La connexion ne compte que lorsque ces noms sont exposés ; ne pas considérer qu'une fenêtre de navigateur s'ouvre ou qu'une page se charge comme une installation terminée.

Une fois connecté, n'effectuer qu'un seul appel exploratoire : utiliser browser_navigate. Seul le nom de l'outil est consigné — pas de tableau de paramètres, pas d'URL d'exemple, pas de chemin d'annulation — donc le contenu à renseigner doit suivre la description d'outil affichée à ce moment par le client. Ne pas inventer de paramètres ni de points de terminaison. Cet appel fera visiter au navigateur local l'adresse fournie, produira des requêtes réseau et un chargement de page, et laissera des processus liés au navigateur sur la machine. Ce n'est pas une opération en lecture seule, ni un risque nul. Avant l'appel, il faut confirmer que l'adresse a été indiquée par soi-même et qu'elle peut accepter d'être visitée. Après l'appel, le point de confirmation est le retour de cet appel. Si browser_navigate_back est ensuite utilisé, la page courante du navigateur changera de la même façon et une nouvelle requête réseau pourra se produire. Avant cet appel, confirmer que la session courante contient déjà un historique de navigation vers lequel revenir.

Cas d'usage

Cas 1 : ouvrir avec browser_navigate une page explicitement indiquée. Le moment est celui où les deux noms d'outils sont déjà apparus et où une adresse pouvant accepter d'être visitée est disponible. Seul ce nom d'outil peut être rattaché aux éléments disponibles ; il n'y a pas d'URL de démonstration ni de champs de paramètres rédigés. L'effet de bord est une navigation réelle et un accès réseau. Revérifier l'adresse avant l'appel, puis voir après coup si cet appel s'est terminé. Ne pas y voir un aperçu hors ligne local, et ne pas supposer que le contenu de la page ne sera pas lu.

Cas 2 : revenir à la page précédente avec browser_navigate_back. Le moment est celui où une navigation vient d'être achevée dans la même session de navigation. Là encore, seul ce nom d'outil est donné — pas d'API de liste d'historique, pas de chemin d'annulation ou undo. Sans navigation avant réussie, le retour peut échouer ou aboutir à une page inattendue ; l'état après échec n'est pas décrit. Cet appel changera aussi la page courante et pourra interroger à nouveau le réseau. Avant l'appel, confirmer qu'une navigation a bien eu lieu ; le point de confirmation reste le retour de cet appel.

Limites d'usage

Le plancher d'exécution est Node.js 18 ou plus récent ; ne pas forcer une version plus ancienne. La capacité s'arrête à l'automatisation de navigateur, et la description indique des instantanés d'accessibilité plutôt que des captures d'écran. Aucun outil de type capture n'apparaît, ni de commande pour fermer le navigateur, nettoyer la session, désinstaller ou undo. Ne pas supposer l'absence de réseau, de lecture locale ou de frontière de confidentialité : dès qu'il y a navigation, le site cible est visité, le contenu de la page peut entrer dans le contexte du client, et des processus de navigateur apparaissent sur la machine. Si la première tentative échoue, vérifier d'abord la version de Node et si le JSON est identique octet par octet au fragment officiel, puis voir si les deux noms d'outils sont apparus. Ne pas passer à une méthode d'installation absente des éléments disponibles. Ne pas traiter comme déjà prises en charge des capacités qui n'y sont pas nommées.