Un classement des meilleurs serveurs MCP pour Codex, d'OpenAI Docs MCP et Context7 à GitHub, Playwright, Chrome DevTools et Figma. Il propose des extraits config.toml prêts à coller, des réglages d'approbation qui maîtrisent l'accès en écriture et une méthode pour ajouter la génération d'images à votre ensemble d'outils.
Codex écrit bien du code à lui seul. Ce qu’il ne peut pas faire seul, c’est lire la documentation de la version de bibliothèque que vous avez installée ce matin, ouvrir une pull request, tester votre page de paiement ou examiner l’erreur survenue en production il y a une heure. Les serveurs MCP comblent cet écart. Chacun fournit à Codex un ensemble d’outils via le Model Context Protocol, et la bonne sélection transforme un assistant capable en un outil qui peut mener un ticket de la description jusqu’à la modification fusionnée.
Ce classement repose sur ce que les développeurs utilisent réellement dans leurs projets : la documentation, la gestion de versions, les navigateurs, les fichiers de design et le suivi des erreurs. Il part de la documentation Codex d’OpenAI, qui cite une courte liste de serveurs recommandés, puis ajoute les compléments qui méritent leur place dans un environnement de travail. Vous obtiendrez au passage config.toml extraits à copier-coller, une méthode pour garder les permissions serrées, et un aperçu de l’ajout de la génération d’images à ce même ensemble.
💡 Réponse rapide : installez d’abord OpenAI Docs MCP, Context7, GitHub et Playwright. Ajoutez Chrome DevTools, Figma et Sentry uniquement lorsqu’un projet en a besoin.
Codex lit ses réglages dans ~/.codex/config.toml. Ce fichier unique est partagé par la CLI, l’extension IDE et l’application de bureau : un serveur enregistré une seule fois apparaît partout. Chaque serveur dispose de sa propre table [mcp_servers.<name>], et Codex se connecte aux serveurs activés au démarrage.
Un serveur MCP est un petit programme, ou un point de terminaison hébergé, qui annonce une liste d’outils. Codex se connecte, lit cette liste et peut appeler ces outils au milieu d’une tâche. Un serveur GitHub expose des actions sur les pull requests. Un serveur de documentation expose une recherche. Codex décide quand appeler un outil, et vos réglages d’approbation déterminent s’il doit d’abord vous demander son avis.
L’effet concret est moins de suppositions. Au lieu d’écrire à partir d’une version d’API restée en mémoire, l’assistant la consulte. Au lieu de vous dire qu’une correction « devrait marcher », il ouvre un navigateur et vérifie.
Le transport dépend des champs que vous renseignez. Un command signifie que Codex lance un processus stdio local. Un url signifie qu’il communique avec un serveur HTTP diffusable distant.
| Serveur stdio | Serveur HTTP diffusable | |
|---|---|---|
| Sélectionné par | command | url |
| Fonctionne | Un processus local lancé par Codex | Un service distant |
| Installation type | Paquet npx plus args | OAuth ou un jeton bearer |
| Identifiants | env ou env_vars | auth (OAuth par défaut) ou bearer_token_env_var |
| Idéal pour | Recherche dans la documentation, navigateurs, fichiers locaux | Services hébergés comme les gestionnaires de tickets |
💡 Pour les serveurs distants qui utilisent OAuth, exécutez
codex mcp loginune seule fois. Dans l’interface du terminal,/mcpaffiche les serveurs actuellement actifs.
L’ordre ci-dessous suit deux règles. Les serveurs qui ne font que lire se classent au-dessus de ceux qui écrivent. Les serveurs qui évitent à Codex de travailler sur des informations périmées se classent au-dessus de ceux qui vous épargnent simplement un clic. Cinq des six proviennent directement de la liste recommandée par OpenAI dans sa documentation Codex.
| Rang | Serveur | Idéal pour | Risque d’écriture |
|---|---|---|---|
| 1 | OpenAI Docs MCP | Réponses actuelles sur l’API OpenAI et Codex | Très faible |
| 2 | Context7 | Documentation de bibliothèques par version | Très faible |
| 3 | GitHub | Pull requests, tickets, exécutions de CI | Moyen |
| 4 | Playwright | Piloter un vrai navigateur | Moyen |
| 5 | Chrome DevTools | Console, réseau, performances | Faible |
| 6 | Figma | Construire à partir de vrais fichiers de design | Faible |
Un classement indique seulement ce qui est bon en général. Ce que vous installez en premier dépend du projet que vous avez sous les yeux :
| Type de projet | Installer en premier | Ajouter plus tard |
|---|---|---|
| Application front-end en solo | Context7, Playwright, Chrome DevTools | Figma |
| Service API backend | Context7, GitHub, Sentry | Un serveur de base de données en lecture seule |
| Dépôt d’équipe avec CI | GitHub, Linear, Context7 | Playwright, Sentry |
Si l’application elle-même appelle des API OpenAI, ajoutez OpenAI Docs MCP à n’importe quelle ligne. Son coût est quasi nul, et il évite toute une famille de bugs liés à des paramètres obsolètes.
Codex connaît ce sur quoi il a été entraîné, et cela peut accuser du retard face à un paramètre renommé ou à un nouveau point de terminaison. Le serveur OpenAI Docs lui permet de consulter la documentation actuelle au lieu de deviner. Il ne fait que lire, donc il y a presque rien qui puisse mal tourner.
Si votre application appelle des API OpenAI, ou si vous posez à Codex des questions sur sa propre configuration, c’est l’installation au meilleur rendement de la liste. Elle se classe première parce qu’elle est à la fois utile et presque sans risque.
Context7 récupère une documentation actuelle, propre à chaque version, pour les bibliothèques et les frameworks, et l’intègre au contexte à la demande. Il s’attaque à l’échec le plus courant des agents : écrire avec assurance pour une API qui a changé il y a deux versions majeures.
Une seule commande l’enregistre :
codex mcp add context7 -- npx -y @upstash/context7-mcp
Ou écrivez la même chose à la main, avec un délai de démarrage plus long pour le premier téléchargement de npx :
[mcp_servers.context7]
command = "npx"
args = ["-y", "@upstash/context7-mcp"]
startup_timeout_sec = 20
💡 Ajoutez une ligne à votre
AGENTS.md, par exemple « utilisez Context7 pour la documentation des bibliothèques », pour que Codex y fasse appel sans que vous le demandiez à chaque fois.
Pour la plupart des équipes, le serveur GitHub officiel est la connexion la plus utile après la documentation. Codex peut lire et commenter des pull requests, rechercher du code dans plusieurs dépôts, trier des tickets et examiner les exécutions de CI en échec. La question « pourquoi ce build est-il rouge ? » passe ainsi d’une chasse de dix minutes entre onglets à une seule instruction.
C’est aussi le premier serveur de cette liste capable de modifier des éléments, donc configurez-le avec soin :
[mcp_servers.github]
url = "https://api.githubcopilot.com/mcp/"
bearer_token_env_var = "GITHUB_MCP_TOKEN"
default_tools_approval_mode = "prompt"
Vérifiez le point de terminaison dans le README de GitHub avant de le copier, car les URL hébergées peuvent changer. Conservez le jeton dans une variable d’environnement, limitez-le aux dépôts où vous travaillez réellement, et commencez par un accès en lecture.
Le serveur Playwright de Microsoft donne à Codex un vrai navigateur à piloter. Il ouvre des pages, remplit des formulaires, clique sur des contrôles, lit la page via son arbre d’accessibilité et conserve l’état du navigateur pendant une session de débogage. La différence se voit dans la formulation de la réponse : « J’ai fait la modification » devient « J’ai fait la modification et confirmé qu’elle s’affiche correctement ».
[mcp_servers.playwright]
command = "npx"
args = ["@playwright/mcp@latest"]
Utilisez-le pour les parcours de paiement, la validation de formulaires et tout ce qui ne se manifeste qu’après trois clics. Comme il peut soumettre des formulaires et cliquer sur des boutons, dirigez-le vers un site de préproduction, pas vers la production.
La documentation d’OpenAI présente Chrome DevTools et Playwright comme des alternatives, mais ils résolvent des problèmes différents. Playwright automatise un parcours. DevTools inspecte une page. Quand la question est « pourquoi est-ce lent ? » ou « quelle est cette erreur dans la console ? », le serveur DevTools permet à Codex d’examiner le panneau réseau, la console et les données de performance, au lieu de raisonner à partir du seul code source.
Beaucoup de projets finissent par utiliser les deux. Si vous ne pouvez en choisir qu’un, prenez Playwright pour les travaux de type tests et DevTools pour les bugs de performance et de rendu.
Sans serveur de design, Codex construit à partir d’une capture d’écran ou de votre description, et les espacements dérivent. Avec le serveur Figma, il peut extraire des informations structurées du fichier lui-même : mise en page, espacements, couleurs et structure des composants. Le résultat est une première version beaucoup plus proche de ce que le designer a livré.
Il occupe la dernière place de la liste courte seulement parce qu’il concerne moins de projets. Dans une équipe front-end qui travaille sur un fichier de design vivant, il peut monter à la deuxième place.
Une fois les six serveurs de base stabilisés, quelques connexions supplémentaires se rentabilisent sur des types de travaux précis. Consultez la documentation actuelle de chaque éditeur pour le point de terminaison et les périmètres d’autorisation, car ceux-ci évoluent plus vite qu’un article de blog.
Sentry publie un serveur MCP capable de transmettre à Codex des traces de pile et les erreurs récentes, de sorte qu’un rapport de bug commence par la vraie défaillance plutôt que par une paraphrase. Linear en publie un également, qui permet à Codex de lire le texte du ticket et les critères d’acceptation avant d’écrire quoi que ce soit. Ensemble, ils couvrent tout le cycle : l’erreur dit ce qui a cassé, le ticket dit ce que signifie « corrigé ».
Les serveurs de bases de données méritent un avertissement. Un serveur branché sur une base de production transforme une faute de frappe en incident. Dirigez-le vers une réplique en lecture seule ou une copie locale, et désactivez tous les outils d’écriture.
Vous pouvez ajouter des serveurs de deux manières, qui donnent le même résultat.
La ligne de commande est le moyen le plus rapide pour un seul serveur :
# local stdio server
codex mcp add playwright -- npx @playwright/mcp@latest
# remote streamable HTTP server
codex mcp add github --url https://api.githubcopilot.com/mcp/
# see what is configured, and log in to OAuth servers
codex mcp list
codex mcp login github
codex mcp add écrit dans le même config.toml, et vous pouvez passer --env NAME=VALUE pour les serveurs locaux qui ont besoin de variables d’environnement. Exécutez codex mcp --help pour la liste complète des commandes.
Après chaque installation, effectuez les trois mêmes vérifications avant de faire confiance à un serveur :
/mcp et vérifiez que le serveur apparaît comme actif.Si la première étape échoue, la cause est généralement un délai de démarrage dépassé, une variable d’environnement manquante ou un paquet qui doit d’abord être téléchargé. Réglez cela avant d’ajouter le serveur suivant, pour toujours savoir quel changement a provoqué quel problème.
Pour un ensemble d’outils que vous réutiliserez, modifiez le fichier. Cela vous permet aussi de définir les options que la CLI ne propose pas. Voici celles qui comptent le plus :
| Champ | Valeur par défaut | Rôle |
|---|---|---|
startup_timeout_sec | 10 | Durée d’attente de Codex avant le démarrage d’un serveur |
tool_timeout_sec | 60 | Durée maximale d’un appel d’outil |
enabled | on | Désactive un serveur sans le supprimer |
required | off | Fait échouer le démarrage si le serveur ne peut pas s’initialiser |
enabled_tools | all | Liste d’autorisation des outils que Codex peut utiliser |
disabled_tools | none | Liste de refus des outils que Codex ne peut pas utiliser |
default_tools_approval_mode | variable | auto, prompt, writes ou approve |
Chaque serveur connecté élargit ce que l’assistant peut toucher. Quelques habitudes permettent de garder cela sous contrôle.
Un serveur peut exposer des dizaines d’outils, et vous n’en avez rarement besoin de tous. Utilisez enabled_tools pour lister exactement ce que Codex peut appeler, ou disabled_tools pour retirer les quelques outils dangereux. Une liste d’outils plus courte signifie aussi moins de texte à lire pour le modèle et moins de mauvais choix.
Ne marquez required = true que pour les serveurs sans lesquels une tâche ne peut pas aboutir. Si un serveur qui n’est qu’un plus ne démarre pas, vous voulez que Codex poursuive, pas qu’il s’arrête.
Le champ default_tools_approval_mode accepte quatre valeurs dans la documentation : auto, prompt, writes et approve. Lisez la page de référence pour le comportement exact de chacune avant de vous y fier. En règle générale, utilisez un mode de demande de confirmation pour tout serveur capable de créer, modifier ou supprimer des éléments, et laissez les serveurs de documentation en lecture seule sur un réglage plus souple.
💡 Une politique de départ raisonnable : serveurs de documentation en mode souple, GitHub et Playwright en mode demande de confirmation, serveurs de bases de données en lecture seule avec les écritures désactivées.
Codex peut rédiger une page d’accueil, mais il ne peut pas peindre l’image principale. PicassoIA propose une connexion MCP et une API pour développeurs afin qu’un assistant puisse générer des visuels dans le cadre de la même tâche. Les détails de connexion se trouvent sur la page des connexions MCP de votre compte PicassoIA, qui nécessite une connexion.
Quatre modèles sont disponibles via l’API et la connexion MCP :
L’URL du serveur n’est pas publiée sur les pages publiques de PicassoIA, copiez-la donc depuis votre compte. Si elle vous donne une URL distante, enregistrez-la avec l’option --url indiquée plus haut, puis vérifiez qu’elle apparaît dans /mcp avant de bâtir un flux de travail dessus.
L’API est asynchrone : vous créez une prédiction, vous interrogez son statut, puis vous récupérez le résultat. Prévoyez ces limites :
Voici un schéma de prompt à essayer une fois la connexion fonctionnelle : demandez à Codex de construire la section d’accueil d’une page, puis d’appeler l’outil d’image avec un prompt photographique au format 16:9 correspondant au sujet de la page, et enfin de référencer l’URL de l’image renvoyée dans le balisage. Une seule tâche, sans changer d’onglet, et le brief de l’image provient du même contexte que le texte.
Si un appel de génération expire dans Codex, augmentez tool_timeout_sec pour ce serveur. Les pages tarifaires et la documentation de l’API décrivent l’accès en termes légèrement différents, donc vérifiez les conditions de votre forfait avant de vous y fier.
Pour la partie texte, PicassoIA héberge aussi des modèles de chat comme GPT 5.6 Sol et Claude Sonnet 5, utiles pour rédiger un AGENTS.md ou comparer deux approches avant de confier la tâche à Codex.
bearer_token_env_var ou env_vars pour que les secrets restent hors d’un fichier que vous pourriez committer.npx télécharge un paquet, et dix secondes peuvent être trop courtes. Augmentez startup_timeout_sec./mcp. Un serveur qui a échoué au démarrage sans le signaler ressemble exactement à un serveur que Codex a choisi de ne pas utiliser.Choisissez trois serveurs dans la liste courte, enregistrez-les et donnez à Codex une vraie tâche : un test qui échoue, une dépendance obsolète, une page qui s’affiche mal sur mobile. Vous saurez en moins d’une heure lesquels méritent leur place.
Allez ensuite plus loin. Ouvrez PicassoIA, générez une image principale avec PicassoIA Image et insérez-la dans la page que Codex vient de construire. Testez différents prompts, essayez l’éditeur sur le résultat, et voyez quelle part d’un lancement vous pouvez finir en une seule séance.
Choisissez votre langue
