# Meilleurs serveurs MCP pour agents de code

URL: https://agentvera.dev/fr/blog/best-mcp-servers-for-coding/ · Publié: 2026-10-25

Les meilleurs serveurs MCP pour coder avec des agents : Playwright, GitHub, Context7, Sentry, Postgres et plus, avec les commandes pour Claude Code, Codex et Gemini CLI.

**En bref:**

- Commencez par quelques serveurs qui comblent un vrai manque : un navigateur (Playwright), une doc à jour (Context7), vos tickets (GitHub) et vos erreurs (Sentry). L’agent lit déjà les fichiers et lance git.
- Chaque serveur ajoute ses définitions d’outils au contexte à chaque tour : ne le branchez qu’aux agents et projets qui en ont besoin, et limitez les toolsets quand le serveur le permet.
- Donnez aux serveurs de base de données un accès en lecture seule sur une copie de développement, sortez les tokens des fichiers de config en clair et traitez tout ce qu’un serveur renvoie comme non fiable.

Les meilleurs serveurs MCP pour coder avec des agents sont ceux qui apportent à l’agent ce qu’il ne sait pas faire seul : voir l’application tourner dans un navigateur, lire la documentation actuelle d’une bibliothèque, consulter le ticket qu’il corrige, retrouver la stack trace remontée par la production. Un [agent de code](/fr/glossary/coding-agent/) comme Claude Code, Codex ou Gemini CLI lit déjà les fichiers, les modifie et lance des commandes. Ajouter un serveur qui fait doublon ne coûte que du contexte.

Cette liste est subjective et volontairement courte. Pour chaque serveur, vous trouverez ce qu’il fait, quand il sert, comment l’ajouter et à quoi faire attention. Si le protocole est nouveau pour vous, commencez par [ce qu’est un serveur MCP](/fr/blog/what-is-mcp-server/) et l’[entrée MCP du glossaire](/fr/glossary/mcp/).

## Comment j’ai choisi ces serveurs

Un serveur entre dans la liste s’il passe trois tests :

1. **Il comble un vrai manque.** Il atteint quelque chose hors du dépôt : un navigateur, un service hébergé, une base de données, une documentation à jour.
2. **Il est maintenu par l’éditeur ou par un projet reconnu.** Le dépôt officiel donne les instructions d’installation, et le serveur est mis à jour.
3. **Son accès peut être restreint.** Mode lecture seule, toolsets, limitation à un projet ou à certains dossiers. Un serveur qu’on ne peut pas limiter mérite qu’on y réfléchisse à deux fois.

Point commun à tous les serveurs : leurs définitions d’outils sont ajoutées au contexte de l’agent et renvoyées à chaque tour, même si l’agent ne les appelle jamais. La question n’est donc jamais « ce serveur est-il utile ? » mais « est-il utile à cet agent, dans ce projet, maintenant ? »

## Aperçu rapide

| Serveur | Ce qu’il apporte à l’agent | Transport | Pour le restreindre |
| --- | --- | --- | --- |
| Playwright | Piloter un vrai navigateur : ouvrir, cliquer, remplir, capturer | stdio (`npx`) | `--isolated`, `--headless` |
| Chrome DevTools | Console, réseau, traces de performance | stdio (`npx`) | `--isolated` |
| Context7 | Documentation à jour, propre à chaque version | HTTP ou stdio | Clé d’API, rien à écrire |
| GitHub | Tickets, pull requests, recherche de code, Actions | HTTP ou Docker | Toolsets, lecture seule |
| Sentry | Erreurs, stack traces, tri des tickets | HTTP (OAuth) | Organisation/projet dans l’URL |
| Postgres (Postgres MCP Pro) | Schéma, requêtes, EXPLAIN, conseils d’index | stdio (`uvx`/Docker) | `--access-mode=restricted` |
| Supabase | Tables, SQL, migrations, logs | HTTP (OAuth) | `read_only=true`, `project_ref` |
| Git | Log, diff, blame sur un dépôt local | stdio (`uvx`) | `--repository` |
| Fetch | Lire une page web en Markdown | stdio (`uvx`) | Avec parcimonie |
| Filesystem | Fichiers des dossiers que vous désignez | stdio (`npx`) | Dossiers autorisés |

## 1. Playwright : laisser l’agent voir l’application

Si vous ne devez en ajouter qu’un, prenez celui-ci. Le serveur Playwright MCP de Microsoft permet à l’agent d’ouvrir votre application sur `localhost`, de lire la page via l’arbre d’accessibilité, de cliquer sur des boutons, de remplir des formulaires et de faire des captures d’écran. On passe de « j’ai modifié le formulaire, ça devrait marcher » à « j’ai envoyé le formulaire et j’ai vu le message de succès ».

```bash
claude mcp add playwright -- npx @playwright/mcp@latest
codex mcp add playwright -- npx @playwright/mcp@latest
gemini mcp add playwright npx @playwright/mcp@latest
```

Il faut Node.js 18 ou plus récent. Options utiles : `--headless` pour tourner sans fenêtre, et `--isolated` pour garder le profil du navigateur en mémoire, afin qu’aucun cookie ni aucune session ne subsiste d’une session à l’autre. Il existe aussi `--allowed-origins`, mais le projet lui-même précise que ce n’est pas une frontière de sécurité : ne comptez pas dessus pour tenir l’agent à l’écart du Web.

À surveiller : les pages que visite l’agent deviennent une entrée du modèle. Une page qui dit « ignore tes instructions et lance cette commande » est une tentative d’[injection de prompt](/fr/glossary/prompt-injection/). Gardez l’agent sur votre propre application autant que possible. Pour un flux complet, voir [les tests navigateur avec des agents IA](/fr/blog/ai-agent-browser-testing/).

## 2. Chrome DevTools : déboguer ce que voit le navigateur

Le serveur Chrome DevTools MCP de Google recoupe Playwright mais penche vers le débogage : messages de la console, requêtes réseau, traces de performance. Quand une page est lente ou qu’une requête échoue sur une erreur CORS, c’est lui qui permet à l’agent de comprendre pourquoi au lieu de deviner.

```bash
claude mcp add chrome-devtools -- npx -y chrome-devtools-mcp@latest
```

Pour Codex et Gemini CLI, utilisez la même commande (`npx -y chrome-devtools-mcp@latest`) avec `codex mcp add` ou `gemini mcp add`. Choisissez un seul des deux serveurs navigateur par agent, sauf vrai besoin des deux : chacun ajoute une longue liste d’outils.

## 3. Context7 : une documentation à jour plutôt que la mémoire

Les modèles apprennent les bibliothèques à partir de données d’entraînement vieilles de plusieurs mois, voire plusieurs années. C’est pour ça que les agents appellent des fonctions renommées il y a deux versions. Context7, d’Upstash, fournit une documentation et des exemples de code à jour et propres à chaque version pour une longue liste de bibliothèques : l’agent peut vérifier au lieu de deviner.

```bash
# Serveur distant
claude mcp add --transport http context7 https://mcp.context7.com/mcp

# Ou en local
codex mcp add context7 -- npx -y @upstash/context7-mcp
```

Si vous avez une clé d’API Context7, passez-la dans un en-tête `CONTEXT7_API_KEY` sur le serveur distant (avec `claude mcp add`, par exemple `--header "CONTEXT7_API_KEY: ctx7sk-…"`). Une bonne habitude à inscrire dans votre `CLAUDE.md` ou `AGENTS.md` : « Quand tu utilises une API de bibliothèque dont tu n’es pas sûr, vérifie d’abord dans Context7. » Les agents suivent mieux une règle écrite qu’un rappel ponctuel ; voir [comment écrire CLAUDE.md et AGENTS.md](/fr/blog/claude-md-agents-md/).

À surveiller : il est en lecture seule, donc le risque est faible, mais ses outils coûtent quand même du contexte. Donnez-le aux agents qui écrivent du code s’appuyant sur des bibliothèques tierces, pas à un agent relecteur qui ne lit que des diffs.

## 4. GitHub : tickets, pull requests et CI

Le serveur officiel de GitHub lit et écrit les tickets, les pull requests, les résultats de recherche de code, les exécutions d’Actions et plus encore. L’agent peut partir du texte du ticket, examiner le workflow en échec et ouvrir une pull request à la fin.

Le serveur distant se trouve à `https://api.githubcopilot.com/mcp/`. Vous pouvez aussi le lancer en local avec Docker :

```bash
claude mcp add github -e GITHUB_PERSONAL_ACCESS_TOKEN=$GITHUB_PAT \
  -- docker run -i --rm -e GITHUB_PERSONAL_ACCESS_TOKEN ghcr.io/github/github-mcp-server
```

C’est ici que le moindre privilège compte le plus. Le serveur GitHub a beaucoup d’outils, et certains écrivent. Restreignez-le :

- **Toolsets.** N’activez que le nécessaire, par exemple `repos,issues,pull_requests`, avec l’option `--toolsets` ou `GITHUB_TOOLSETS` en local, ou l’en-tête `X-MCP-Toolsets` sur le serveur distant.
- **Lecture seule.** Utilisez `--read-only` en local, ajoutez `/readonly` à l’URL distante (`https://api.githubcopilot.com/mcp/readonly`) ou envoyez `X-MCP-Readonly: true`.
- **Un token à granularité fine.** Limitez le personal access token aux dépôts sur lesquels travaille l’agent, avec les permissions minimales pour la tâche.

Un agent relecteur ou de tri a rarement besoin d’écrire. Ne donnez les outils d’écriture qu’à l’agent censé ouvrir des pull requests.

## 5. Sentry : partir de la vraie erreur

Le serveur MCP hébergé de Sentry permet à l’agent de chercher des erreurs, de lire des stack traces et de consulter le détail d’un ticket. « Corrige le bug que les utilisateurs rencontrent au paiement » devient « corrige cette exception, à cette ligne, avec ces breadcrumbs ». L’authentification passe par OAuth : la première connexion ouvre une page de connexion dans le navigateur.

```bash
claude mcp add --transport http sentry https://mcp.sentry.dev/mcp/my-org/my-project
```

Remplacez `my-org` et `my-project` par les slugs de votre organisation et de votre projet. Limiter l’URL à un projet est ce que recommande Sentry : les outils visent alors ce projet par défaut et certains outils de découverte sont masqués, ce qui économise aussi du contexte. Sentry associé à GitHub fonctionne bien pour [corriger les échecs de CI](/fr/blog/auto-fix-ci-failures-with-ai/) et les bugs de production à partir du ticket.

## 6. Un serveur de base de données, en lecture seule

Un agent qui peut regarder le schéma et lancer un `SELECT` écrit de meilleures requêtes et de meilleures migrations. Un agent qui peut lancer `DROP TABLE` sur la production, c’est une mauvaise journée en préparation. Deux options solides :

**Postgres MCP Pro** (crystaldba/postgres-mcp) fonctionne avec n’importe quelle base PostgreSQL. En plus des requêtes, il sait expliquer les plans d’exécution, vérifier la santé de la base et suggérer des index. Son réglage clé est le mode d’accès :

```bash
claude mcp add postgres --env DATABASE_URI=postgresql://readonly_user:pass@localhost:5432/app_dev \
  -- uvx postgres-mcp --access-mode=restricted
```

`restricted` limite le travail à des transactions en lecture seule et plafonne la durée d’exécution ; `unrestricted` autorise lecture et écriture complètes. Utilisez restricted, et connectez-vous de toute façon avec un utilisateur qui n’a que les droits `SELECT`. Deux verrous valent mieux qu’un, d’autant que le projet signale que des langages de procédures stockées non sûrs pourraient contourner ses contrôles.

**Supabase** propose un serveur hébergé à `https://mcp.supabase.com/mcp`. Ajoutez `?project_ref=<id>&read_only=true` pour le lier à un seul projet et exécuter chaque requête avec un utilisateur Postgres en lecture seule. Supabase conseille lui-même de l’utiliser sur des données de développement, de garder l’approbation manuelle des appels d’outils et de ne pas le confier à des utilisateurs finaux.

À noter : l’ancien serveur Postgres de référence du projet MCP est archivé. Choisissez-en un qui est maintenu.

## 7. Git, Fetch et Filesystem : les serveurs de référence

Le projet MCP maintient encore quelques serveurs de référence. Ils sont pratiques, mais vérifiez d’abord que votre agent en a besoin.

- **Git** (`uvx mcp-server-git --repository /path/to/repo`) : outils log, diff, blame et commit. Les agents de code lancent déjà `git` dans le terminal ; ce serveur sert surtout aux clients sans accès au shell, ou quand vous voulez que les opérations git apparaissent comme des appels d’outils explicites.
- **Fetch** (`uvx mcp-server-fetch`) : transforme une page web en Markdown pour le modèle. Utile pour lire une référence d’API absente de Context7. Chaque page récupérée est une entrée non fiable : l’avertissement sur l’injection de prompt s’applique pleinement.
- **Filesystem** (`npx -y @modelcontextprotocol/server-filesystem /path/one /path/two`) : accès aux fichiers limité aux dossiers listés. Claude Code et Codex modifient déjà les fichiers du projet ; servez-vous-en pour exposer un dossier supplémentaire, par exemple un répertoire partagé de design tokens, sans ouvrir tout votre dossier personnel.

## D’autres à connaître

Selon votre stack, ceux-ci peuvent mériter une place : **Linear** ou **Notion** pour les tâches et les specs, **Stripe** pour les objets de paiement en mode test, **Figma** pour lire les maquettes, la documentation **Cloudflare**, et des serveurs mobiles pour les simulateurs. Appliquez les trois mêmes tests. Un serveur ajouté « au cas où » ajoute surtout du contexte.

## Ajouter des serveurs à Claude Code, Codex et Gemini CLI

Le même serveur fonctionne dans les trois ; seul l’enregistrement change.

**Claude Code.** Les options se placent avant le nom, la commande du serveur après `--` :

```bash
claude mcp add --transport http sentry https://mcp.sentry.dev/mcp
claude mcp add --scope project playwright -- npx @playwright/mcp@latest
claude mcp list
```

`--scope local` (par défaut) le garde pour vous dans ce projet, `--scope user` pour tous vos projets, et `--scope project` écrit un `.mcp.json` dans le dépôt pour l’équipe. `.mcp.json` prend en charge l’expansion `${VAR}` : vous pouvez commiter le fichier sans commiter les tokens. Lancez `/mcp` dans une session pour vous connecter aux serveurs OAuth.

**Codex.** Utilisez la CLI ou modifiez `~/.codex/config.toml` :

```toml
[mcp_servers.github]
url = "https://api.githubcopilot.com/mcp/readonly"
bearer_token_env_var = "GITHUB_PAT"

[mcp_servers.playwright]
command = "npx"
args = ["@playwright/mcp@latest"]
enabled_tools = ["browser_navigate", "browser_snapshot", "browser_click", "browser_take_screenshot"]
```

`bearer_token_env_var` lit le token dans une variable d’environnement plutôt que dans le fichier, et `enabled_tools` / `disabled_tools` réduisent un serveur aux outils voulus. `codex mcp login <name>` gère les serveurs OAuth.

**Gemini CLI.** `gemini mcp add` écrit dans `.gemini/settings.json` (projet, par défaut) ou dans `~/.gemini/settings.json` avec `--scope user` :

```bash
gemini mcp add --transport http github https://api.githubcopilot.com/mcp/readonly \
  --header "Authorization: Bearer $GITHUB_PAT"
```

Dans `settings.json`, `includeTools` et `excludeTools` limitent les outils, et `trust: true` supprime les demandes de confirmation. Laissez `trust` désactivé pour tout ce qui écrit. Attention : un token passé dans `--header` comme ci-dessus finit dans le fichier de configuration ; préférez les références `$VAR` dans `env` et `headers` quand c’est possible.

## Notes de sécurité

Les serveurs MCP relient un modèle à des systèmes réels. Une courte checklist :

- **Le moindre privilège par défaut.** Modes lecture seule, toolsets restreints, un projet par serveur, tokens à granularité fine. Accordez l’écriture à un agent pour une tâche, pas à tous les agents pour toujours.
- **Des données de développement, pas la production.** Pointez les serveurs de base de données vers une copie locale ou le staging. Si un agent doit regarder la production, utilisez un utilisateur en lecture seule et une session courte.
- **Pas de secrets en clair.** Variables d’environnement, références `${VAR}` ou trousseau du système. Un token dans un `.mcp.json` commité est un token fuité.
- **Tout ce que renvoie un serveur est non fiable.** Pages web, commentaires de tickets, lignes de base de données et messages d’erreur peuvent tous contenir des instructions destinées à l’agent. Gardez les approbations actives pour les outils qui écrivent ou lancent des commandes.
- **Sachez ce que vous exécutez.** Un serveur stdio est du code qui tourne sur votre machine avec vos droits. Installez depuis le dépôt officiel, figez les versions pour tout ce qui est sensible, et ne copiez pas de commandes d’installation depuis n’importe quel README.
- **Regardez la liste des outils.** Listez les outils d’un serveur avant de le donner à un agent, et retirez ce dont vous n’avez pas besoin.

Pour une vue d’ensemble, lisez [la sécurité des agents de code IA](/fr/blog/ai-coding-agent-security/).

## Associer les serveurs aux agents

Si vous faites tourner plusieurs agents, distribuez les serveurs par rôle :

| Agent | Serveurs |
| --- | --- |
| Frontend | Playwright ou Chrome DevTools, Context7, Figma |
| Backend | Context7, Postgres ou Supabase en lecture seule |
| Correction de bugs | Sentry, GitHub (tickets et Actions), Playwright |
| Relecteur | GitHub en lecture seule |

Le contexte de chaque agent reste léger, et ce qu’une erreur ou une instruction injectée peut atteindre reste limité. Cela réduit aussi la [consommation de tokens](/fr/blog/claude-code-token-usage/).

## Comment je procède avec AgentVera

Enregistrer les mêmes serveurs trois fois dans trois formats devient vite lassant. Dans AgentVera, je les garde au même endroit :

- **Une seule liste pour toutes les CLI.** Le [gestionnaire MCP](/fr/features/mcp-manager/) conserve les serveurs et les branche au démarrage d’un agent : Claude Code, Codex, Gemini CLI, Copilot, Cursor, opencode et les autres CLI compatibles MCP. Je donne chaque serveur à tous les agents, à certains agents, à un groupe ou à un rôle d’équipe, et je le limite à certains projets.
- **Un catalogue et une mesure du coût.** Le catalogue contient des entrées prêtes pour Playwright, Chrome DevTools, Context7, GitHub, Sentry, Supabase, Git, Fetch, Filesystem et d’autres. Le test de connexion liste les outils d’un serveur avec un coût approximatif en tokens par outil : je vois ce que chacun ajoute à chaque tour.
- **Les secrets dans le trousseau.** Les variables d’environnement et les tokens d’en-tête sont conservés dans le trousseau du système d’exploitation, et les serveurs distants passent par la passerelle d’AgentVera : la config de la CLI ne contient jamais le token.
- **Un navigateur que je peux suivre.** Le [navigateur des agents](/fr/features/agent-browser/) leur donne un Chrome géré via Playwright MCP, et je suis les onglets en direct.
- **Un accès à la base encadré par des règles.** Plutôt qu’une chaîne de connexion brute, le [gestionnaire de base de données](/fr/features/database-manager/) laisse les agents interroger une connexion via son propre outil, en lecture seule par défaut, avec chaque requête journalisée. [DB Guard](/fr/features/db-guard/) vérifie les migrations écrites par l’agent.
- **Les approbations.** Pour les agents Claude Code, l’[approbation automatique](/fr/features/auto-approval/) ne répond qu’aux demandes connues pour être sûres ; tout le reste continue de m’être soumis.

## Pour conclure

La meilleure configuration MCP pour coder est réduite : un navigateur, une documentation à jour, votre gestionnaire de tickets et le suivi des erreurs, plus une base de données en lecture seule quand la tâche l’exige. Ajoutez les serveurs par agent et par projet, restreignez chacun avec son mode lecture seule ou ses toolsets, sortez les tokens des fichiers en clair et traitez tout ce qu’un serveur renvoie comme non fiable. Si vous voulez gérer les serveurs de plusieurs agents au même endroit, [téléchargez AgentVera gratuitement](/fr/download/) et ouvrez la page MCP.

## Questions fréquentes

**Quels sont les meilleurs serveurs MCP pour coder ?** Pour la plupart des projets : Playwright ou Chrome DevTools pour voir l’application tourner, Context7 pour une documentation à jour, GitHub pour les tickets et les pull requests, Sentry pour les erreurs de production, et un serveur de base de données en lecture seule pour vérifier les données. N’ajoutez les autres que lorsqu’une tâche l’exige.

**Combien de serveurs MCP brancher sur un même agent ?** Aussi peu que la tâche le demande. Les définitions d’outils de chaque serveur sont envoyées à chaque tour : dix serveurs avec beaucoup d’outils consomment du contexte même sans être utilisés. Trois à cinq serveurs ciblés par agent sont un bon point de départ.

**Est-ce sûr de donner à un agent de code un accès à la base de données via MCP ?** Sur une copie de développement ou de staging, avec un utilisateur en lecture seule ou un mode du serveur qui n’autorise que des transactions en lecture, oui. Ne branchez pas un agent sur la production avec un accès en écriture, et gardez en tête que les données de la base peuvent contenir du texte qui cherche à piloter l’agent.

**Ai-je besoin du serveur MCP filesystem avec Claude Code ou Codex ?** En général, non. Les agents de code lisent et modifient déjà les fichiers du projet. Le serveur filesystem sert aux clients sans accès aux fichiers, ou quand vous voulez exposer de façon contrôlée un dossier supplémentaire hors du projet.

**Puis-je utiliser les mêmes serveurs MCP dans Claude Code, Codex et Gemini CLI ?** Oui. MCP est un protocole ouvert, et la même commande stdio ou la même adresse HTTP fonctionne dans les trois. Seule la façon de l’enregistrer change : claude mcp add, codex mcp add ou config.toml, et gemini mcp add ou settings.json.

---

**À propos d’AgentVera.** AgentVera est une app de bureau pour macOS, Windows et Linux, développée par Solviera Teknoloji. Elle exécute 18 agents de code IA (Claude Code, Codex, Gemini CLI, Copilot, Cursor, Antigravity, opencode, Hermes, Qwen Code, Kimi Code, Kiro, Amp, Droid, Goose, Vibe, Crush, Aider, Cline) côte à côte, par projet, dans de vrais terminaux avec les installations et connexions CLI de l’utilisateur. L’offre gratuite inclut des agents illimités. Télécharger: https://agentvera.dev/fr/download/ · Tarifs: https://agentvera.dev/fr/pricing/