Se connecter à des serveurs MCP et les utiliser

Branchez Claude sur votre compte GitHub et il peut lire une issue ouverte, rédiger un correctif et ouvrir une pull request sans que vous quittiez le chat. Cette capacité vient des serveurs MCPMCPUn standard ouvert qui permet aux assistants IA de se connecter aux outils et données de l'entreprise de façon cohérente et gouvernée, sans intégration sur mesure à chaque fois.Voir la définition complète →. Dans cette leçon, vous allez apprendre à les trouver, à les connecter et à distinguer les versions locales des versions distantes.

Ce qu'est réellement un serveur MCP

Vous connaissez déjà MCP (le Model Context Protocol), le standard ouvert qui permet à Claude de dialoguer avec des outils extérieurs. Un serveur MCP est un petit programme qui expose un système précis (GitHub, Slack, une base Postgres, votre système de fichiers) sous forme d'outils et de ressources que Claude peut appeler. Claude est le client ; le serveur est ce à quoi il se connecte.

Le protocole est maintenu de façon ouverte sur modelcontextprotocol.io, et la spec est la même que vous utilisiez Claude Code, l'application desktop ou votre propre agent construit avec le SDK. C'est tout l'intérêt : écrivez ou installez un serveur une fois, utilisez-le partout.

Il existe deux variantes, et choisir correctement compte plus que tout le reste dans cette leçon.

Serveurs locaux

Un serveur local tourne sur votre machine, dans un processus que Claude lance. Il communique via stdio (entrée/sortie standard). Utilisez-les quand l'outil a besoin d'un accès direct à votre matériel : le serveur filesystem qui lit des dossiers locaux, ou un serveur Postgres qui interroge une base sur localhost.

Les serveurs locaux sont privés et rapides, mais ils n'existent que là où vous les avez installés. Ils ne vous suivent pas sur l'application mobile.

Serveurs distants

Un serveur distant tourne sur internet et Claude s'y connecte en HTTP. Les serveurs officiels GitHub et Slack sont distants : ils vivent à une URL, gèrent leur propre authentification (généralement OAuth) et fonctionnent depuis n'importe quelle surface Claude, y compris le web et le mobile.

Dans les applications Claude, les serveurs MCP distants apparaissent sous un nom plus accessible : les Connectors. Le répertoire de connectors liste ceux qui ont été vérifiés et que vous pouvez ajouter en deux clics. Construire un connector personnalisé revient toujours à monter un serveur MCP distant ; la marketplace n'est que la porte d'entrée curatée.

Une règle simple : si ça touche à des fichiers locaux, allez en local. S'il s'agit d'un produit SaaS avec un compte, préférez le connector distant.

Où trouver des serveurs

Trois sources fiables :

1. Le répertoire de connectors dans les applications Claude. Settings, puis Connectors. C'est le chemin le plus rapide pour GitHub, Google Drive, Slack et autres outils populaires. Ils sont distants et gérés.
2. [github.com/modelcontextprotocol/servers](https://github.com/modelcontextprotocol/servers), la collection de référence officielle. Filesystem, fetch, memory et d'autres, prévus pour tourner en local dans la plupart des cas.
3. Les repos des éditeurs. Beaucoup d'entreprises livrent le leur. Celui de GitHub est sur github.com/github/github-mcp-server et existe à la fois comme serveur distant et comme image Docker locale.

Évitez les serveurs au hasard d'auteurs inconnus. Un serveur MCP tourne avec les permissions que vous lui accordez, donc traitez son installation comme celle de n'importe quel autre logiciel ayant accès à vos comptes.

L'exemple concret : ajouter GitHub

Donnons à Claude la capacité de lire des issues et d'ouvrir des pull requests. Il y a deux façons de faire, selon là où vous travaillez.

Option A : le connector GitHub (le plus simple, distant)

Dans l'application desktop ou web de Claude, ouvrez Settings, Connectors, trouvez GitHub et cliquez sur connect. Vous serez redirigé vers l'écran OAuth de GitHub pour autoriser l'accès et choisir les dépôts que Claude peut voir. Terminé. Pas de fichier de config, pas de tokentokenUn token est l'unité de base de texte que traitent les modèles de langage : le plus souvent un fragment de mot, un mot entier ou un signe de ponctuation, plutôt qu'un simple caractère.Voir la définition complète → à coller, et ça fonctionne sur tous vos appareils.

C'est le bon choix pour la plupart des gens. Vous pouvez maintenant demander :

« Lis l'issue #214 dans mon repo acme/web-app, résume le bug, puis ouvre une PR avec un correctif sur une nouvelle branche. »

Claude appelle les outils du serveur GitHub (get_issue, create_branch, create_pull_request, etc.), et comme vous relisez chaque étape, rien n'est mergé sans votre accord.

Option B : configuration locale (pour Claude Code et les setups personnalisés)

Si vous travaillez dans Claude Code (l'agent de codage d'Anthropic en terminal) ou si vous câblez votre propre client, vous configurez les serveurs explicitement. Claude Code lit les serveurs MCP depuis une config JSON. Voici le serveur GitHub qui tourne en local via Docker, authentifié avec un personal access token :

{
  "mcpServers": {
    "github": {
      "command": "docker",
      "args": [
        "run", "-i", "--rm",
        "-e", "GITHUB_PERSONAL_ACCESS_TOKEN",
        "ghcr.io/github/github-mcp-server"
      ],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "${GITHUB_PAT}"
      }
    }
  }
}

Quelques points à noter :

• command et args indiquent à Claude comment lancer le serveur. Ici, il récupère et exécute l'image Docker officielle de GitHub.
• Le token vient d'une variable d'environnement (${GITHUB_PAT}), il n'est pas en dur. Ne committez jamais un token dans un fichier de config qui vit dans un repo.
• Le flag -i maintient stdin ouvert, c'est ainsi que les serveurs stdio restent en conversation avec le client.

Pour ajouter le même serveur sans éditer le JSON à la main, Claude Code propose une commande :

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

Lancez ensuite `claude mcp list` pour confirmer la connexion, et claude mcp get github pour l'inspecter.

Cadrer le token

Quand vous crcrLe pourcentage de visiteurs ou de prospects qui réalisent une action attendue (achat, inscription, formulaire de contact), calculé en divisant les conversions par le nombre total d'opportunités.Voir la définition complète →éez le personal access token sur GitHub, n'accordez que ce dont la tâche a besoin. Pour lire des issues et ouvrir des PR, cela signifie contenus du dépôt, issues et pull requests, idéalement sous forme de token fine-grained limité aux repos concernés. Les tokens trop larges sont l'erreur de sécurité la plus fréquente ici. Le serveur ne peut faire que ce que le token autorise, donc le token est votre véritable frontière de permissions.

Ajouter les autres serveurs courants

Le schémamaUtiliser un logiciel pour automatiser les tâches et campagnes marketing répétitives, afin de personnaliser à grande échelle sur des canaux comme l'email, le web et le social.Voir la définition complète → se répète. Chaque serveur n'est qu'une command différente et un secret différent.

Filesystem (local). Permet à Claude de lire et écrire des fichiers dans les dossiers que vous désignez. Vous passez les répertoires autorisés en arguments, ce qui agit comme un sandbox strict :

claude mcp add filesystem \
  -- npx -y @modelcontextprotocol/server-filesystem \
  /Users/you/projects /Users/you/notes

Claude peut toucher ces deux dossiers et rien d'autre.

Postgres (local). Pointez-le vers une chaîne de connexion et Claude peut inspecter les schémas et exécuter des requêtes de lecture sur votre base. Restez en lecture seule au niveau du rôle de la base, sauf si vous voulez vraiment autoriser l'écriture.

Slack (connector distant). Ajoutez-le via le répertoire de connectors et autorisez en OAuth. Claude peut alors lire les canaux et publier des messages en votre nom.

Google Drive (connector distant). Même parcours. Une fois connecté, Claude peut chercher et intégrer des documents comme contexte, ce qui se marie bien avec les Projects.

Vérifier que ça marche et rester prudent

Après la connexion, faites un petit test avant de confier quoi que ce soit de réel à Claude. Demandez-lui directement : « À quels outils GitHub as-tu accès en ce moment ? » Un serveur correctement connecté amène Claude à lister ses outils disponibles. S'il répond qu'il n'en a aucun, le serveur n'a pas démarré (vérifiez que Docker tourne, que le token est défini, que la config est du JSON valide).

Ensuite, lancez une lecture sans enjeu : « Liste les trois issues ouvertes les plus récentes dans acme/web-app. » Les lectures avant les écritures. Une fois le chemin de lecture validé, laissez-le écrire.

Deux habitudes de sécurité à ancrer :

• Approuvez les actions, ne les automatisez pas à l'aveugle. Claude demande confirmation avant chaque appel d'outil par défaut. Gardez ce comportement pour tout ce qui écrit (ouvrir des PR, poster sur Slack, modifier des fichiers). L'auto-approbation convient aux serveurs en lecture seule que vous jugez fiables.
• Un token, une mission. Utilisez des identifiants distincts et étroitement cadrés par serveur. Si un token fuite, le rayon d'impact reste limité.

Local contre distant : choisir en pratique

Maintenant que vous avez vu les deux, voici comment la décision se joue sur un vrai projet.

Disons que vous développez une fonctionnalité et que vous voulez que Claude Code corrige un bug de bout en bout. Vous feriez probablement tourner deux serveurs en même temps : le serveur GitHub (distant ou local) pour lire l'issue et ouvrir la PR, et le serveur filesystem (local) pour que Claude puisse lire et modifier le code réel sur votre machine. Les serveurs MCP se composent. Claude voit l'ensemble des outils réunis et orchestre entre eux dans une seule conversation.

À l'inverse, un collègue sur l'application mobile qui veut simplement que Claude résume les issues GitHub de la semaine pendant son trajet. Il veut le connector distant et rien d'autre, parce qu'un conteneur Docker local ne tourne pas dans sa poche.

Même protocole, déploiement différent, entièrement dicté par le lieu où le travail se fait et par ce à quoi il doit toucher.

Les serveurs dans l'APIAPIApplication Programming Interface : une interface standardisée qui permet aux applications de communiquer et d'échanger des données sans connaître leur fonctionnement interne respectif.Voir la définition complète → et l'agent SDK

Ce n'est pas limité aux applications de chat. La Messages API d'Anthropic prend en charge les serveurs MCP distants via sa fonctionnalité MCP connector, si bien qu'un service backend que vous construisez peut donner à Claude le même accès GitHub ou Slack de façon programmatique. Le Claude Agent SDK va plus loin : c'est la boîte à outils pour construire des agents qui gèrent leurs propres connexions MCP, exécutent les boucles d'outils et prennent en charge l'orchestration que vous feriez sinon à la main.

Le modèle mental reste identique partout. Vous connectez un serveur, Claude découvre ses outils et les appelle au besoin. La documentation de référence pour câbler des serveurs sur les différentes surfaces se trouve sur docs.claude.com, et c'est la source de vérité quand un flag ou un parcours change.

Une note sur Skills versus Connectors

On les confond facilement, alors traçons la ligne clairement. Un Connector (serveur MCP) donne à Claude accès à un système externe vivant : il peut appeler GitHub tout de suite. Une Skill empaquette des instructions et des ressources qui façonnent *la manière* dont Claude accomplit une tâche, comme un playbook réutilisable pour rédiger des descriptions de PR au format de votre équipe. Les Skills disent à Claude comment se comporter ; les connectors lui donnent quelque chose sur quoi agir. Les setups les plus performants utilisent les deux : une Skill qui définit vos conventions de PR, exécutée par-dessus un connector GitHub qui fait l'ouverture effective.

Points clés

• Choisissez local ou distant selon ce à quoi le travail touche. Serveurs stdio locaux pour les systèmes de fichiers et les bases locales ; connectors distants pour les outils SaaS et tout ce dont vous avez besoin sur mobile.
• Pour GitHub, commencez par le connector dans Settings, Connectors. Ne descendez vers une config JSON (image Docker plus token en variable d'environnement) que si vous êtes dans Claude Code ou si vous construisez votre propre client.
• Le token est la frontière de permissions. Créez des identifiants fine-grained, cadrés au repo, à usage unique, et ne les mettez jamais en dur dans une config committée.
• Testez les lectures avant les écritures, et gardez les approbations d'outils actives pour tout ce qui modifie un état.
• Composez les serveurs et associez-les à des Skills. Faire tourner GitHub avec filesystem permet à Claude de corriger un bug de bout en bout ; une Skill par-dessus le fait faire à la façon de votre équipe.