Les 10 meilleurs serveurs MCP pour OpenAI Codex en 2026

Ce guide présente les dix serveurs MCP qui valent la peine d’être connectés à Codex, ainsi que les trois qui apparaissent sur d’autres listes mais ne devraient pas figurer sur la vôtre. Le premier est le MCP Bright Data, qui comble le fossé que Codex ne peut pas combler seul : lire le web en direct depuis des pages qui se défendent. Vous apprendrez :

1. Comment le support MCP dans Codex fonctionne réellement en 2026, notamment ce qui a changé et ce que la plupart des guides se trompent encore.
2. Quels dix serveurs méritent leur place, avec le TOML exact pour chacun.
3. Ce que chaque serveur vous coûte avant d’effectuer le moindre travail.
4. Quels serveurs populaires éviter, et pourquoi deux d’entre eux sont des problèmes de sécurité plutôt que des préférences.

Une note sur la méthode, car la plupart des listes dans cette catégorie sont vagues à ce sujet. Nous n’avons pas pu obtenir les identifiants de chaque fournisseur ici, donc ce guide ne prétend pas avoir exécuté les dix de bout en bout. Chaque bloc de configuration ci-dessous est tiré de la documentation ou du dépôt du fournisseur, chaque nombre d’outils est le nombre documenté plutôt qu’un résultat tools/list en temps réel, et lorsqu’un fournisseur n’a publié aucune instruction Codex, l’entrée le dit clairement.

Les dix, en un coup d’œil

À quoi ressemble vraiment le support MCP dans Codex en 2026

Commencez ici, car une grande partie des guides qui se classent actuellement sur ce sujet décrivent une version de Codex qui n’a pas existé depuis 2025. L’affirmation que vous continuerez à rencontrer est que Codex ne parle que stdio et ne peut pas se connecter à des serveurs MCP distants. C’était vrai pendant environ cinq semaines. Le support HTTP streamable a été intégré dans Codex 0.44.0 le 3 octobre 2025, et le flag experimental_use_rmcp_client qui le conditionnait a été supprimé dans la version 0.77.0 en décembre. Tout article vous demandant encore de définir ce flag décrit une opération sans effet, et plusieurs pages de documentation de fournisseurs n’ont pas non plus été mises à jour.

Ce que Codex supporte aujourd’hui, c’est stdio et HTTP streamable, avec des jetons bearer, un OAuth MCP complet incluant les Documents de Métadonnées d’ID Client et l’Enregistrement Dynamique de Client, et l’authentification de session ChatGPT pour les serveurs de première partie de confiance. Ce qu’il ne supporte pas mérite également d’être connu : il n’y a pas de transport SSE ni de transport WebSocket. Un serveur qui ne publie qu’un endpoint SSE a besoin d’un pont stdio devant lui, ce qui est la raison la plus courante pour laquelle une configuration copiée depuis un tutoriel Claude Code échoue dans Codex.

Les serveurs résident dans ~/.codex/config.toml sous [mcp_servers.<name>], ou dans un .codex/config.toml au niveau du projet que Codex ne lit que dans les projets de confiance. Un seul fichier sert le CLI, l’extension IDE et l’application de bureau ChatGPT. Le transport est inféré plutôt que déclaré : donnez à un serveur une command et il s’exécute en stdio, donnez-lui une url et il s’exécute en HTTP. Il n’y a pas de champ type à définir.

# stdio
[mcp_servers.context7]
command = "npx"
args = ["-y", "@upstash/context7-mcp"]

# remote HTTP, token from the environment
[mcp_servers.figma]
url = "https://mcp.figma.com/mcp"
bearer_token_env_var = "FIGMA_OAUTH_TOKEN"

Le CLI couvre le même terrain sans modifier TOML manuellement. codex mcp add <name> -- <command> enregistre un serveur stdio, codex mcp add <name> --url <url> en enregistre un distant, et codex mcp login <name> exécute le flux OAuth. Dans une session, /mcp liste ce qui s’est réellement connecté, ce qui est la première chose à vérifier quand un serveur semble ne rien faire.

Chaque serveur que vous ajoutez a un coût avant d’effectuer le moindre travail

C’est ce qui distingue une configuration Codex fonctionnelle d’une configuration lente, et c’est presque entièrement absent des autres listes. Codex démarre chaque serveur MCP activé à l’ouverture d’une session, que le modèle appelle ou non l’un de ses outils. Un problème OpenAI déposé en septembre 2026 l’énonce clairement : Codex initialise et démarre chaque serveur MCP activé à l’ouverture d’une session locale, même si aucun des outils de ce serveur n’est utilisé. Dix serveurs représentent dix processus ou poignées de main à chaque démarrage de session, et les définitions d’outils de chacun occupent du contexte pour toute la session.

Les nombres d’outils rendent le calcul évident. Le serveur GitHub officiel documente environ 88 outils, Playwright environ 71, Chrome DevTools 57, Notion 35. Installez ces quatre ensemble et le modèle choisit parmi environ 250 définitions d’outils avant que vous n’ayez écrit une invite. Codex vous donne trois leviers que la plupart des guides ne mentionnent jamais, et ils font la différence entre un serveur utile et un serveur coûteux.

[mcp_servers.github]
url = "https://api.githubcopilot.com/mcp/"
# trim the surface to the toolsets you actually use
enabled_tools = ["search_code", "get_pull_request", "list_issues"]
# reads run unattended, writes stop and ask
default_tools_approval_mode = "writes"
# a chatty tool cannot blow up the context window
[mcp_servers.github.tools.search_code]
output_token_limit = 25000

enabled_tools est une liste d’autorisation et disabled_tools est une liste de refus appliquée après. default_tools_approval_mode accepte auto, prompt, writes ou approve, et writes est le paramètre que la plupart des gens veulent réellement : les outils en lecture seule s’exécutent sans surveillance tandis que tout ce qui modifie l’état s’arrête et demande. tools.<tool>.output_token_limit plafonne ce qu’un seul outil peut retourner. La documentation de Figma enregistre un appel de contexte de design retournant plus de 351 000 tokens, et là où Claude Code répond avec une variable d’environnement, Codex répond ici, par outil.

Deux comportements par défaut vous surprendront avant tout cela. Codex accorde dix secondes à un serveur pour démarrer et soixante secondes par appel d’outil. Les serveurs installés via npx ou uvx ont régulièrement besoin de plus de temps sur un cache froid, et l’échec est silencieux plutôt que bruyant : la session signale l’agrégation de zéro outil depuis un serveur et continue. Un développeur sur r/codex a décrit l’expérience précisément en novembre 2025, après avoir essayé Serena, Context7 et Playwright sur Windows : les guides d’installation donnent l’impression qu’il suffit d’ouvrir config.toml, d’ajouter un extrait et ça marche, ce qui vous amène à supposer que vous avez manqué quelque chose de basique. En général, vous avez seulement omis startup_timeout_sec.

Ce que le sandbox de Codex ne couvre pas

Codex dispose d’un sandbox et d’une liste d’autorisation réseau, et il est facile de supposer que les deux s’étendent aux serveurs que vous connectez. Ce n’est pas le cas. La référence de configuration est explicite à ce sujet en plus d’un endroit : la fonctionnalité de proxy réseau ne filtre pas la recherche web, les applications, MCP ou autres outils hébergés, et la liste expérimentale de domaines réseau ne restreint pas la recherche web, les applications ou les serveurs MCP. Une liste d’autorisation de domaines contraint ce que le shell propre de l’agent peut atteindre. Elle ne contraint pas ce qu’un serveur MCP atteint au nom de l’agent.

Ce n’est pas un argument contre MCP. C’est un argument pour traiter chaque serveur comme quelque chose ayant ses propres identifiants et son propre périmètre d’impact, c’est pourquoi les paramètres d’approbation et de liste d’autorisation ci-dessus comptent davantage dans Codex que les paramètres équivalents ailleurs. C’est aussi la raison pour laquelle deux serveurs largement recommandés se trouvent dans la section à ne pas installer à la fin de ce guide plutôt que dans le classement.

1. Bright Data MCP : le web en direct, débloqué

Codex peut déjà lire une URL, et pour une page de documentation non protégée, c’est suffisant. Le fossé s’ouvre sur les sites que la plupart des travaux commerciaux ciblent réellement. Les détaillants, les marketplaces, les sites d’emploi et les plateformes sociales servent une page différente à un client automatisé qu’à un navigateur, et l’échec est rarement une erreur propre. C’est une page qui retourne, s’analyse et contient la mauvaise chose, ce qui est le pire résultat possible pour un agent qui énoncera le résultat avec confiance.

Le MCP Bright Data place toute la pile de données web derrière un seul endpoint : recherche sur plusieurs moteurs, scraping qui retourne du Markdown propre depuis des pages derrière une gestion des robots, extraction structurée depuis plus d’une centaine de plateformes, et automatisation de navigateur quand une page ne cède qu’à l’interaction. Il expose 69 outils au total, et c’est l’un des serveurs où le découpage avec enabled_tools vaut les cinq minutes. Chaque compte Bright Data inclut 5 000 requêtes par mois sans frais et sans carte, ce qui est suffisant pour l’évaluer correctement sur une tâche réelle.

[mcp_servers.brightdata]
url = "https://mcp.brightdata.com/mcp?pro=1"
bearer_token_env_var = "BRIGHTDATA_API_KEY"
startup_timeout_sec = 20
tool_timeout_sec = 120
default_tools_approval_mode = "auto"

Deux de ces paramètres sont délibérés. Le scraping d’une page défendue peut prendre plus de temps que les soixante secondes par défaut de Codex, donc tool_timeout_sec est augmenté. Et parce que chaque outil ici est une lecture contre le web public plutôt qu’une écriture contre vos systèmes, l’approbation auto est sûre et supprime la friction d’invite par appel qui rend les serveurs de type navigateur fatigants à utiliser. Pour le serveur hébergé, il n’y a rien à installer ; le package local est @brightdata/mcp si vous préférez l’exécuter en stdio.

Si vous souhaitez la version plus longue de cette configuration, incluant son exécution sur une tâche réelle de bout en bout, consultez notre guide pour connecter Codex à Bright Data.

2. Context7 : une documentation correspondant à votre version installée

La façon la plus courante pour un agent de codage de gaspiller un après-midi est d’utiliser avec confiance une API qui a été renommée deux versions mineures auparavant. Context7 résout une bibliothèque vers une version spécifique et retourne sa documentation, et il le fait avec exactement deux outils. Sur une liste où l’alternative est 88, ce ratio est tout l’argument. C’est le serveur utile le moins coûteux ici de loin, et le premier à ajouter.

codex mcp add context7 -- npx -y @upstash/context7-mcp

Il s’exécute de manière anonyme, avec une clé API augmentant la limite de débit et un niveau gratuit de 1 000 appels par mois. La mise en garde honnête est que la qualité varie selon la bibliothèque : la critique que vous trouverez dans les forums de développeurs est que pour les packages moins populaires, il retourne le même mince extrait de Markdown de manière répétée. Pour les frameworks largement utilisés, c’est nettement mieux que la date limite d’entraînement du modèle, ce qui est le cas qui compte.

3. GitHub MCP Server : l’autre moitié du travail

Codex est déjà bon pour éditer un dépôt sur disque. Ce qu’il ne peut pas voir, c’est tout ce qui entoure le code : l’exécution Actions qui échoue, le commentaire de révision qui explique pourquoi une fonction semble étrange, l’issue liée qui décrit l’exigence réelle. Le serveur GitHub officiel comble cela, et c’est le seul serveur de cette liste où le budget d’outils doit vraiment être géré, avec environ 88 outils répartis sur 22 ensembles d’outils.

GitHub vous donne les contrôles pour le faire : --toolsets ou la variable d’environnement GITHUB_TOOLSETS pour charger uniquement les groupes dont vous avez besoin, --tools pour la sélection individuelle, et --read-only pour supprimer entièrement l’accès en écriture. Commencez en lecture seule. Un chemin d’injection d’invite depuis une issue publique vers un dépôt privé a été démontré par Invariant Labs, et bien que GitHub ait déployé des atténuations, sa propre documentation précise que le mode de verrouillage n’est pas une limite d’autorisation. À noter également : beaucoup de développeurs trouvent que le CLI gh couvre le même terrain moins cher, puisque Codex peut déjà exécuter des commandes shell.

4. Chrome DevTools MCP : pourquoi la page est cassée, pas ce qu’elle fait

Celui-ci apparaît dans la propre documentation Codex d’OpenAI et presque nulle part ailleurs, ce qui en fait le serveur le plus sous-recommandé de cette liste. La distinction avec Playwright mérite d’être bien comprise, car ils ne sont pas concurrents. Playwright pilote une application : cliquer ici, remplir cela, affirmer l’autre. Chrome DevTools MCP explique une application : traces de performance, erreurs de console avec mappage de source, la cascade réseau, et treize outils d’inspection du tas pour traquer la mémoire. Quand Codex a écrit du code qui fonctionne mais est lent, c’est le serveur qui lui dit pourquoi.

Il documente 57 outils, que --slim réduit considérablement. Il est exclusivement Chrome par définition. Et les statistiques d’utilisation sont envoyées à Google par défaut, donc ajoutez --no-usage-statistics si cela compte dans votre environnement.

[mcp_servers.chrome_devtools]
command = "npx"
args = ["-y", "chrome-devtools-mcp@latest", "--slim", "--isolated", "--no-usage-statistics"]
startup_timeout_sec = 30

Le flag --isolated n’est pas optionnel en pratique. Les serveurs pilotant des navigateurs échouent sous Codex avec une erreur indiquant que le profil du navigateur est déjà utilisé, et cela se produit même avec un accès complet au système de fichiers accordé. Exécuter chaque session contre un profil jetable est la solution, et elle s’applique à Playwright ci-dessous pour la même raison.

5. Serena : des modifications au niveau des symboles plutôt que la recherche textuelle

Serena place un serveur de langage derrière MCP, de sorte que l’agent travaille avec des symboles plutôt que des chaînes. Trouver chaque référence à cette fonction, renommer cette classe dans tout le projet, lire uniquement le corps de cette méthode plutôt que le fichier entier. Sur une grande base de code, c’est une qualité d’opération différente de grep, et cela dépense considérablement moins de tokens pour atteindre la même réponse.

Il mérite sa place ici pour une raison spécifique à Codex : Serena embarque un mode --context=codex qui désactive ses propres outils qui dupliquent ce que Codex possède déjà. C’est exactement l’hygiène de contexte que le reste de ce guide préconise, réalisée par le fournisseur plutôt que laissée à votre charge.

[mcp_servers.serena]
command = "uvx"
args = ["--from", "git+https://github.com/oraios/serena", "serena", "start-mcp-server", "--context", "codex"]
startup_timeout_sec = 60

Le délai d’attente est délibérément généreux. Serena indexe un projet lors de la première exécution, et c’est le serveur le plus susceptible de dépasser le délai par défaut de dix secondes.

6. Sentry : ce qui s’est réellement cassé, depuis la production

Coller une trace de pile dans une invite fonctionne. Laisser l’agent extraire lui-même l’issue, avec la version, les fils d’Ariane et la fréquence, fonctionne mieux, et cela vous évite d’être le goulot d’étranglement. Le serveur distant de Sentry est un HTTP streamable simple avec OAuth, donc codex mcp login sentry est toute la configuration.

Un point d’exactitude, puisque d’autres listes laissent entendre le contraire : la documentation de Sentry dispose d’onglets de configuration pour Claude Code, Cursor et VS Code, mais aucun pour Codex. OpenAI le recommande dans la documentation Codex et le transport est entièrement supporté, donc ça fonctionne — mais personne chez Sentry n’a écrit les instructions Codex, et vous ne devriez pas vous attendre à un chemin copier-coller. Restreindre l’endpoint à /mcp/{org}/{project} masque les outils de découverte et maintient la surface réduite.

7. Postgres MCP Pro : des plans de requêtes, pas seulement une connexion

La plupart des serveurs MCP de bases de données donnent à l’agent un moyen d’exécuter du SQL. Celui-ci lui donne un moyen de raisonner sur le SQL. Il explique les plans de requêtes, analyse une charge de travail contre pg_stat_statements pour trouver les requêtes qui vous coûtent vraiment, et simule des index hypothétiques pour que l’agent puisse tester une idée avant que vous ne la construisiez. Il fait cela avec neuf outils, et parce qu’il s’exécute en stdio, il contourne tous les modes d’échec OAuth distant de cette liste.

Deux mises en garde honnêtes. Les mainteneurs n’ont pas publié d’instructions Codex — une demande ouverte est restée sans réponse depuis janvier 2026 — bien qu’un bloc stdio soit trivial à écrire soi-même. Et pointez-le vers un réplica, avec --access-mode=restricted, avant de le pointer vers quoi que ce soit d’important.

8. Playwright : piloter l’application

Playwright MCP pilote un navigateur via l’arbre d’accessibilité plutôt que des pixels, ce qui le rend déterministe d’une manière que l’automatisation basée sur des captures d’écran ne l’est pas, et il fonctionne sur Chromium, Firefox et WebKit. Pour les tests de bout en bout et la reproduction d’un bug signalé, c’est l’outil évident.

Il est classé huitième plutôt que plus haut en raison d’un signal inhabituel : le propre README de Microsoft oriente maintenant les agents de codage loin du serveur MCP, recommandant le CLI Playwright et les compétences comme plus efficaces en tokens et mieux adaptés aux agents à haut débit, et positionnant le MCP pour des boucles agentiques spécialisées. Quand le fournisseur vous dit que son propre serveur n’est pas la bonne forme pour votre cas d’utilisation, cela appartient au classement. Ajoutez --isolated, et attendez-vous à des frictions d’approbation : une issue ouverte avec un soutien communautaire substantiel signale que approval_policy = "never" invite encore à chaque appel, ce que default_tools_approval_mode = "auto" sur le serveur résout.

9. Figma : le contexte de design plutôt qu’une capture d’écran

Donner à un agent un PNG et lui demander le composant produit approximativement la bonne chose. Le serveur Figma lui transmet à la place les variables, les tokens, les contraintes de mise en page et la structure des composants, et le résultat cesse d’être une approximation. Il documente 29 outils via HTTP distant avec OAuth.

Les contraintes sont réelles et méritent d’être vérifiées avant de planifier autour d’elles. Un siège Dev ou Full est requis ; les sièges View obtiennent 20 appels d’outils par mois. Figma restreint les connexions aux clients dans son propre catalogue, et Codex figure actuellement sur cette liste, mais c’en est une. Et c’est le serveur qui a le plus besoin de output_token_limit — la documentation de Figma enregistre une seule réponse de contexte de design de plus de 351 000 tokens.

10. Linear : le ticket sans le copier-coller

Une configuration en une ligne qui supprime une petite taxe constante : codex mcp add linear --url https://mcp.linear.app/mcp, puis codex mcp login linear. L’agent lit l’issue, les critères d’acceptation et le fil de commentaires directement, et peut déplacer le ticket quand c’est fait.

Notez que ce n’est pas la même chose que l’intégration Codex de première partie de Linear, qui fonctionne dans la direction opposée — mentionner Codex dans une issue pour distribuer une tâche cloud. Le serveur MCP est pour le travail local dans le CLI ou l’extension IDE. Si vous avez vu la propre documentation de Linear mentionner le flag experimental_use_rmcp_client, ignorez-le ; ce flag n’existe plus depuis décembre 2025.

Ce qu’il ne faut pas installer

Ces trois-là apparaissent sur la plupart des listes comparables. Deux d’entre eux sont des problèmes de sécurité et un est simplement redondant, et les laisser de côté rendra votre configuration Codex meilleure plutôt que moins bonne.

• Filesystem MCP. Codex dispose déjà d’outils de fichiers natifs régis par son propre système d’approbation. L’ajout de ce serveur les duplique tout en déplaçant l’accès aux fichiers dans un processus en dehors de ce système, vous obtenez donc moins de supervision plutôt que plus. Il a également un historique de vulnérabilités d’évasion de sandbox, CVE-2025-53109 et CVE-2025-53110, du type que vous ne voulez pas dans le composant qui lit votre disque.
• Slack. Le serveur officiel refuse l’Enregistrement Dynamique de Client et attend une application Slack publiée dans un répertoire ou interne, ce qui exclut effectivement Codex CLI. L’ancien package npm est déprécié et porte un avertissement d’exfiltration de données. L’alternative communautaire populaire s’authentifie avec des cookies de session de navigateur, ce qui est très probablement contraire à la politique de votre espace de travail.
• Le serveur Atlassian communautaire. Porte CVE-2026-27825, une écriture de fichier arbitraire menant à une exécution de code à distance notée 9.1, accompagnée d’un problème SSRF distinct. Le serveur officiel Rovo d’Atlassian existe et n’en souffre pas.

Le câblage, et vérifier que ça a fonctionné

Ajoutez les serveurs un à la fois et confirmez chacun avant d’ajouter le suivant, car un échec au démarrage est silencieux. Exécutez /mcp dans une session pour voir ce qui s’est réellement connecté ; un serveur configuré mais absent de cette liste a échoué plutôt que chargé. Si un serveur est absent, augmentez d’abord startup_timeout_sec, car dix secondes ne suffisent pas pour un téléchargement npx ou uvx à froid. Si des outils apparaissent mais que Codex ne les appelle jamais, c’est un comportement connu plutôt qu’une configuration cassée : nommez le serveur ou l’outil dans votre invite une fois et il commencera à l’utiliser.

Deux autres choses qui coûtent un après-midi aux gens. Le .codex/config.toml au niveau du projet n’est lu que dans les projets de confiance, donc une configuration qui fonctionne dans un répertoire peut silencieusement ne rien faire dans un autre. Et si vous configurez des serveurs via un manifeste de plugin plutôt que config.toml, les champs OAuth y sont en camelCase tandis que tout dans config.toml est en snake_case.

Questions fréquemment posées

Codex prend-il en charge les serveurs MCP distants ?

Oui. Le HTTP streamable a été intégré dans Codex 0.44.0 le 3 octobre 2025, avec des jetons bearer et un OAuth complet incluant CIMD et Dynamic Client Registration. Le flag experimental_use_rmcp_client qui le conditionnait a été supprimé dans la version 0.77.0 en décembre 2025, donc tout guide vous demandant encore de le définir est obsolète. Codex ne prend pas en charge les transports SSE ou WebSocket.

Combien de serveurs MCP dois-je installer dans Codex ?

Moins que vous ne le souhaitez. Codex démarre chaque serveur activé à l’ouverture d’une session, que ses outils soient utilisés ou non, et les définitions d’outils de chaque serveur consomment du contexte pour toute la session. Quatre serveurs avec des listes d’outils réduites seront plus performants que dix installés tels quels. Utilisez enabled_tools pour restreindre chacun d’eux et enabled = false pour mettre en veille les serveurs dont vous n’avez besoin qu’occasionnellement.

Pourquoi mon serveur MCP n’affiche-t-il aucun outil dans Codex ?

C’est presque toujours le délai de démarrage de dix secondes. Un serveur installé via npx ou uvx peut prendre plus de temps sur un cache froid, et Codex signale l’agrégation de zéro outil plutôt qu’une erreur. Augmentez startup_timeout_sec à 30 ou 60 et réessayez. Si le serveur est un serveur de navigateur, ajoutez --isolated, ce qui résout un échec de verrouillage de profil qui se produit même avec un accès complet accordé.

Le sandbox de Codex restreint-il ce à quoi un serveur MCP peut accéder ?

Non, et c’est largement mal compris. La référence de configuration de Codex indique que son proxy réseau ne filtre pas les outils MCP ou autres outils hébergés, et que la liste expérimentale de domaines réseau ne restreint pas les serveurs MCP. Une liste d’autorisation de domaines régit le shell propre de l’agent, pas ce qu’un serveur connecté récupère en son nom. Traitez chaque serveur comme détenant ses propres identifiants et son propre périmètre d’impact.

Codex peut-il scraper des sites web qui bloquent les robots ?

Pas seul. Codex peut récupérer une URL, mais les sites dotés d’une gestion des robots renvoient une page différente à un client automatisé, et l’échec est généralement silencieux plutôt qu’une erreur. Le MCP Bright Data gère le déblocage, la recherche multi-moteurs et l’extraction structurée depuis plus d’une centaine de plateformes derrière un seul endpoint, avec 5 000 requêtes par mois gratuites et sans carte requise.