Un point rouge sur le serveur MCP de Cursor, une liste d’outils vide ou des échecs silencieux ? Lisez les logs, corrigez les erreurs de PATH et de JSON, réglez les scopes du token GitHub, les ports de Figma et les erreurs de navigateur de Playwright, puis testez chaque serveur avec l’inspecteur pour que votre agent retrouve ses outils.
Vous collez un bloc de serveur dans mcp.json, vous redémarrez Cursor, et le panneau des réglages affiche un point rouge, ou un point vert à côté d’une liste d’outils vide. L’agent continue comme si votre serveur GitHub, Figma ou Playwright n’avait jamais existé. Ce silence rend le débogage de MCP si pénible : rien ne plante, rien ne s’explique, et la correction tient souvent en une seule ligne que vous ne voyez pas depuis l’écran des réglages.
Cet article passe en revue les défaillances à l’origine des serveurs MCP de Cursor qui ne fonctionnent pas, dans l’ordre qui permet de les trouver le plus vite. La première section regroupe quatre vérifications valables pour chaque serveur. Viennent ensuite les pièges propres à GitHub, Figma et Playwright, puis les limites d’outils, les demandes d’approbation et une méthode pour tester n’importe quel serveur hors de l’éditeur. Chaque correction indique son symptôme, pour que vous alliez directement à celle qui correspond à votre écran.
💡 Remarque sur les versions : Cursor et les trois serveurs évoluent rapidement. Les libellés des menus, les options et les URL changent d’une version à l’autre. Si un nom affiché à l’écran diffère de celui de cette page, faites confiance à la sortie de vos logs plutôt qu’à cet article.
Avant d’accuser un serveur en particulier, écartez les problèmes qui cassent tous les serveurs à la fois. Dans la plupart des cas, l’un de ces quatre points est le coupable.
Ouvrez le panneau Output de Cursor et choisissez le canal des logs MCP dans la liste déroulante. Le libellé exact change selon les versions, mais il se trouve avec les autres canaux de Output. Le log affiche la commande que Cursor a lancée, ainsi que tout ce que le serveur a écrit sur stderr avant de s’arrêter. Trois messages expliquent la plupart des échecs :
spawn npx ENOENT : Cursor ne trouve pas l’exécutable. Passez à la correction du PATH ci-dessous.MCP error -32000: Connection closed : le processus a démarré puis s’est arrêté aussitôt, généralement à cause d’un token manquant, d’un argument incorrect ou d’un plantage au lancement.Request timed out : le serveur est en vie mais lent, souvent parce que npx télécharge un paquet lors de sa première exécution.💡 Astuce : Copiez les 30 dernières lignes du log avant de modifier quoi que ce soit. Chaque redémarrage écrase les preuves dont vous avez besoin si votre première hypothèse est fausse.
Cursor lit deux fichiers : ~/.cursor/mcp.json pour chaque projet, et .cursor/mcp.json à l’intérieur du projet en cours. Les deux doivent contenir du JSON strict, c’est-à-dire sans commentaires, sans virgules finales et avec uniquement des guillemets droits. Une seule virgule mal placée peut faire ignorer tout le fichier par Cursor, sans message clair.
{
"mcpServers": {
"github": {
"command": "docker",
"args": ["run", "-i", "--rm", "-e", "GITHUB_PERSONAL_ACCESS_TOKEN", "ghcr.io/github/github-mcp-server"],
"env": { "GITHUB_PERSONAL_ACCESS_TOKEN": "${env:GITHUB_TOKEN}" }
}
}
}
Pour vérifier un fichier, exécutez node -e "JSON.parse(require('fs').readFileSync('.cursor/mcp.json','utf8'))". Il n’affiche rien quand le JSON est valide et indique la position exacte de l’erreur dans le cas contraire. Les versions récentes de Cursor remplacent les placeholders ${env:NAME} par les valeurs de votre environnement. Si votre version transmet le texte littéral à la place, le serveur reçoit un faux token et échoue avec une erreur d’authentification. Testez donc avec une vraie valeur, dans un fichier local non versionné.
Cursor lancé depuis le dock, le menu Démarrer ou Spotlight ne lit pas votre profil de shell. Les outils installés avec nvm, fnm ou Homebrew peuvent lui rester invisibles, alors qu’ils fonctionnent dans votre terminal, et le log affiche spawn npx ENOENT. Remplacez la commande simple par un chemin absolu. Exécutez which npx sous macOS et Linux, ou where npx sous Windows, puis collez le résultat :
"command": "/Users/you/.nvm/versions/node/v22.11.0/bin/npx"
Windows ajoute un second piège. npx est un script .cmd, et certains lanceurs ne peuvent pas l’exécuter directement. Encapsulez-le dans cmd, et passez toujours -y pour que npx ne s’arrête jamais pour demander l’autorisation d’un téléchargement que personne ne voit :
"command": "cmd",
"args": ["/c", "npx", "-y", "@playwright/mcp@latest"]
Modifier le fichier ne redémarre pas toujours un serveur en cours d’exécution. Désactivez puis réactivez le serveur dans Cursor Settings, Tools & MCP (les anciennes versions l’indiquent simplement MCP), ou exécutez Developer: Reload Window depuis la palette de commandes. Si l’ancien état persiste, quittez complètement Cursor. Un processus résiduel peut occuper un port ou un profil de navigateur et faire échouer un nouveau démarrage pour des raisons sans rapport avec votre configuration.
GitHub maintient son propre serveur dans le dépôt github/github-mcp-server, sous deux formes : une version locale qui tourne dans Docker, et une version hébergée. Si votre configuration pointe encore vers l’ancien paquet npm @modelcontextprotocol/server-github, abandonnez-le. Ce paquet est déprécié au profit du serveur officiel de GitHub, et c’est la nouvelle version qui reçoit les corrections et les nouveaux outils.
La panne la plus courante sur GitHub est un serveur qui se connecte sans problème, alors que chaque appel d’outil renvoie une erreur 401, 403 ou un déroutant 404. Un 404 sur un dépôt privé signifie généralement que le token ne peut pas voir ce dépôt, et non qu’il n’existe pas. Vérifiez quatre points :
repo, et de read:org si vous interrogez des données d’organisation.💡 Astuce : Testez le token hors de Cursor avec
curl -H "Authorization: Bearer $GITHUB_TOKEN" https://api.github.com/user. Un profil en JSON signifie que le token fonctionne, et que le problème se trouve dans la configuration.
Le serveur local a besoin de Docker. Trois lignes de log indiquent ce problème : docker: command not found, Cannot connect to the Docker daemon et un délai d’attente pendant le téléchargement de l’image. Démarrez d’abord Docker Desktop, puis exécutez docker pull ghcr.io/github/github-mcp-server une fois dans un terminal, afin que Cursor n’attende jamais le premier téléchargement. Vérifiez aussi l’option -i dans vos args. Elle maintient stdin ouvert, et sans elle le serveur s’arrête dès son démarrage. Derrière un proxy d’entreprise, le téléchargement depuis ghcr.io peut échouer alors que les autres téléchargements Docker fonctionnent.
Si Docker continue de vous poser problème, passez au serveur hébergé. Il ne nécessite ni Docker, ni Node, ni configuration du PATH :
"github": {
"url": "https://api.githubcopilot.com/mcp/",
"headers": { "Authorization": "Bearer ${env:GITHUB_TOKEN}" }
}
Une erreur 401 pointe vers le token, et un délai d’attente vers un proxy ou un pare-feu. Le serveur de GitHub expose aussi un grand nombre d’outils, ce qui compte pour les limites évoquées plus loin. Son README décrit les toolsets, configurables via la variable d’environnement GITHUB_TOOLSETS sur le serveur local ou via un en-tête X-MCP-Toolsets sur le serveur distant. Vous pouvez ainsi ne charger que repos, issues et pull_requests et laisser le reste de côté.
Figma propose deux voies. La première est un serveur local qui tourne dans l’application de bureau Figma. La seconde est un serveur hébergé avec connexion via le navigateur. Les noms, les ports et les chemins ont changé depuis le lancement. Vérifiez-les dans la documentation actuelle de Figma si une étape ci-dessous ne correspond pas à votre écran. Les échecs se répartissent en trois catégories.
Le serveur local vit dans l’application de bureau, et non dans l’onglet du navigateur. L’application doit être ouverte, un fichier de design doit être chargé, et le serveur MCP doit être activé depuis le panneau d’inspection du Dev Mode ou depuis les préférences, selon votre version. Figma a aussi lié l’accès MCP à des offres payantes et à certains types de sièges. Vérifiez donc que votre siège le permet avant de passer une heure sur la configuration. Quand l’application est fermée, Cursor affiche une connexion refusée. Cela ressemble à un serveur défaillant, mais il s’agit en réalité d’un processus absent.
Le serveur local écoute sur le port 3845. Les versions récentes répondent à /mcp, et les anciennes utilisaient /sse. Une configuration qui contient encore l’ancien chemin reçoit une erreur 404 ou un handshake refusé :
"figma": { "url": "http://127.0.0.1:3845/mcp" }
Utilisez 127.0.0.1 à la place de localhost. Sur certaines machines, localhost se résout d’abord en IPv6, et un serveur lié à IPv4 refuse cette route. Si le port est déjà occupé, identifiez le processus concerné avec lsof -i :3845 sous macOS et Linux, ou netstat -ano | findstr 3845 sous Windows. Pour la voie hébergée, configurez Cursor avec https://mcp.figma.com/mcp et terminez la connexion dans le navigateur lorsque c’est demandé. Vous avez fermé l’onglet de connexion par erreur ? Désactivez puis réactivez le serveur pour relancer le processus.
Les outils locaux agissent sur votre sélection en cours ou sur un lien vers un cadre. Si vous demandez à l’agent de « construire cet écran » sans rien sélectionner, il reçoit une réponse vide, ce qui ressemble à un serveur mort alors que la connexion fonctionne parfaitement. Sélectionnez un cadre dans Figma, ou collez le lien du cadre dans votre prompt. Si un très grand cadre dépasse le délai, sélectionnez une section plus petite et construisez l’écran par parties.
💡 Astuce : Après chaque modification dans Figma, posez d’abord une question simple à l’agent, par exemple le nom du cadre sélectionné. Une réponse correcte prouve que toute la chaîne fonctionne avant de demander une mise en page complète.
@playwright/mcp de Microsoft est le choix habituel, et la configuration minimale est courte :
"playwright": { "command": "npx", "args": ["@playwright/mcp@latest"] }
Comme il lance un vrai navigateur, il échoue de plus de façons que les deux autres serveurs.
Une ligne de log comme Executable doesn't exist ou Chromium distribution 'chrome' is not found signifie qu’aucun navigateur correspondant n’est installé. Par défaut, le serveur demande Chrome. Installez Chrome de la manière habituelle, ou exécutez npx playwright install chrome dans un terminal. Le serveur fournit aussi un outil browser_install, de sorte que vous pouvez demander à l’agent de l’appeler quand cette erreur apparaît. Pour utiliser un autre moteur, ajoutez --browser firefox ou --browser webkit aux args, puis installez ce moteur de la même façon.
La session par défaut utilise un dossier de profil persistant. Une seconde fenêtre de Cursor, ou un processus Chrome resté actif après un plantage, verrouille ce dossier. Le log indique alors que le navigateur est déjà utilisé et suggère l’option --isolated. Fermez les processus parasites, ou ajoutez l’option pour que chaque session démarre avec un profil neuf en mémoire :
"args": ["@playwright/mcp@latest", "--isolated"]
Les sessions isolées oublient les connexions. Si vous devez rester connecté à un site, donnez plutôt au serveur un profil dédié avec --user-data-dir.
Les conteneurs, WSL, les sessions SSH et les machines de CI n’ont généralement pas d’écran. Ajoutez donc --headless. En dernier recours, dans un conteneur qui s’exécute en root, --no-sandbox supprime l’erreur de sandbox, au prix d’une isolation moins forte. Vérifiez aussi la version de Node, car le paquet exige Node 18 ou plus récent. Enfin, le premier lancement télécharge le paquet et démarre un navigateur, ce qui peut dépasser le délai d’attente de Cursor. Exécutez npx @playwright/mcp@latest --help une fois dans un terminal pour préchauffer le cache : le démarrage suivant depuis Cursor sera rapide.
Certaines pannes laissent tous les points verts. Le serveur est connecté, et l’agent ne l’utilise jamais. Deux causes expliquent la plupart de ces cas.
Trop d’outils chargés. Cursor avertit lorsque le nombre total d’outils de tous les serveurs devient important, avec un plafond historique d’environ 40 outils, susceptible de varier selon votre version. GitHub seul peut en exposer des dizaines. Une fois ce seuil dépassé, les outils de certains serveurs peuvent ne jamais atteindre le modèle. Désactivez les serveurs dont vous n’avez pas besoin dans le projet en cours, utilisez les toolsets de GitHub, et gardez des fichiers .cursor/mcp.json au niveau du projet aussi légers que possible.
Mauvais mode ou approbation en attente. Les outils MCP fonctionnent en mode Agent. En mode Ask, le modèle ne peut pas les appeler. Par défaut, chaque appel demande une approbation, et si vous faites défiler la fenêtre sans répondre, le chat paraît figé. Approuvez l’appel, ou activez l’exécution automatique pour les serveurs de confiance. Ouvrez aussi l’entrée du serveur et vérifiez qu’aucun outil individuel n’a été désactivé.
💡 Astuce : Un bon prompt de test est explicite : « Utilisez l’outil playwright pour ouvrir example.com et dites-moi le titre de la page. » Nommer le serveur lève tout doute sur l’outil que le modèle doit choisir.
Lancez l’inspecteur MCP. L’inspecteur officiel démarre n’importe quel serveur et liste ses outils sans que Cursor fasse obstacle :
npx @modelcontextprotocol/inspector npx -y @playwright/mcp@latest
Si le serveur se connecte et liste ses outils dans l’inspecteur mais pas dans Cursor, le problème se trouve dans l’environnement de Cursor : PATH, variables d’environnement ou fichier de configuration. S’il échoue aussi dans l’inspecteur, le problème vient du serveur ou de votre machine, et le message d’erreur le désigne en général.
Faites lire les logs par un LLM. Les longs logs sont fastidieux, et un modèle de langage repère rapidement la ligne pertinente. Avec Claude Sonnet 5 sur PicassoIA :
REDACTED.GPT 5.6 Sol fait un bon second avis sur les cas tenaces, et Gemini 3.5 Flash gère une première analyse rapide des très longs logs. Tout ce que vous collez dans un modèle hébergé quitte votre machine : masquez donc systématiquement les secrets avant.
| Symptôme | Cause probable | Correction |
|---|---|---|
spawn npx ENOENT | Cursor ne voit pas Node dans le PATH | Utilisez le chemin absolu vers npx |
Connection closed juste après le démarrage | Token manquant ou plantage au lancement | Lisez stderr dans le log, vérifiez les valeurs d’environnement |
| Outils listés, appels qui renvoient 401 ou 403 | Token GitHub expiré ou aux droits insuffisants | Recréez le token, autorisez-le pour le SSO |
docker: command not found | Docker absent ou arrêté | Démarrez Docker Desktop, téléchargez l’image à l’avance |
| Figma refuse la connexion | Application de bureau fermée ou serveur MCP désactivé | Ouvrez un fichier de design, activez le serveur |
| Figma renvoie 404 | Ancien chemin /sse | Remplacez l’URL par /mcp |
| Exécutable Playwright introuvable | Aucun navigateur correspondant installé | Exécutez npx playwright install chrome |
| Navigateur Playwright déjà utilisé | Dossier de profil verrouillé | Fermez les processus parasites ou ajoutez --isolated |
| Point vert, l’agent ignore les outils | Trop d’outils, ou mode Ask | Réduisez les serveurs, passez en mode Agent |
Une fois vos serveurs opérationnels, MCP devient intéressant bien au-delà du code. PicassoIA expose aussi ses modèles de génération via sa propre connexion MCP et son API pour développeurs, qui repose sur quatre modèles : PicassoIA Image, Image Editor Pro, PicassoIA Video et Seedance 2.5 Lite pour la vidéo avec son. Vous configurez la connexion depuis la page MCP de votre compte, sur picassoia.com/en/mcp/accounts. Elle se comporte comme n’importe quel autre serveur dans Cursor, donc toutes les vérifications ci-dessus s’y appliquent aussi.
Une limite mérite d’être connue lorsque des tâches semblent bloquées : un compte exécute jusqu’à 5 prédictions simultanément, partagées entre tous vos identifiants et toutes vos connexions MCP. Une sixième tâche attend, et depuis l’éditeur, cela peut ressembler à un serveur figé.
Vous n’avez pas besoin de serveur MCP pour commencer, cependant. Ouvrez l’application web, écrivez un prompt et obtenez un résultat en quelques secondes :
Choisissez un besoin réel de votre dernier projet, comme une image d’en-tête pour un README, une bannière pour un article de blog ou une fausse photo de produit pour une démo, puis générez trois versions. Comparez-les, modifiez un détail à la fois, et gardez celle qui convient. Ouvrez Picasso IA, écrivez votre premier prompt, et voyez à quoi ressemblera votre prochain projet.
Choisissez votre langue
