MCP : Connecter Claude au monde extérieur

📚 Navigation dans la série : L'article précédent 21 Sécurité et frontières de risques vous a aidé à comprendre « quand faire confiance à l'IA pour toucher à votre code et à vos systèmes ». Cet article change de perspective — il s'agit de connecter Claude au monde extérieur. Par défaut, il ne peut toucher qu'à vos fichiers locaux et à la ligne de commande ; il ne peut pas accéder à votre base de données, à Jira, ou à Figma. Le MCP est le port unifié qui lui permet de se connecter à toute une panoplie de services externes en une seule fois.

Une petite anecdote pour commencer — quand j'ai installé mon premier serveur MCP, j'ai lutté pendant presque une heure contre une erreur dans le terminal.

À l'époque, je voulais connecter un serveur de base de données. J'ai copié une commande depuis le README d'un dépôt, qui ressemblait à ceci : claude mcp add db -- npx server --transport stdio. Je tape Entrée, impossible de se connecter. J'ai d'abord soupçonné un problème de réseau, puis un problème de paquets. J'ai supprimé et réinstallé plusieurs fois, npx téléchargeait le paquet en boucle, la barre de progression s'affichait et disparaissait — mais la connexion échouait toujours.

Plus tard, en lisant la documentation officielle, j'ai réalisé que la position des arguments était incorrecte. La documentation est explicite : toutes les options (--transport, --env, --scope) doivent être placées « avant » le nom du serveur ; ce qui suit -- (les doubles tirets) est la commande pour démarrer le serveur. Dans la commande ci-dessus, --transport stdio était passé après le --, et était donc traité comme un argument pour le serveur lui-même, ce qu'il ne reconnaissait pas. De plus, stdio étant le transport par défaut, il n'était même pas nécessaire de l'écrire. La bonne syntaxe était tout simplement : claude mcp add db -- npx server, connexion instantanée.

Je vous raconte ce piège pour vous faire gagner cette heure de perdue : le MCP en lui-même n'est pas compliqué ; la difficulté réside dans les détails de "position", de "portée", ou de "besoin d'approbation". Aujourd'hui, nous allons aplanir ces obstacles un à un, et nous terminerons par le lancement d'un véritable serveur.

Après avoir lu cet article, vous saurez :

• Expliquer en une phrase ce qu'est le MCP et quelle faiblesse de Claude il compense.
• Quand utiliser les trois formes de serveur (stdio local, HTTP distant, et l'obsolète SSE), résumé dans un tableau.
• La syntaxe correcte de la commande claude mcp add et les différences entre les portées local, project, et user.
• Comment les outils apparaissent pour Claude après l'ajout du serveur, et si la première utilisation nécessite votre approbation (en lien avec l'article précédent sur les autorisations).
• Un cas pratique que vous pouvez reproduire, avec les résultats attendus : connecter le serveur de documentation officiel en 5 minutes et le vérifier.

---

01 Pour commencer : quelle faiblesse le MCP vient-il combler ?

Commençons par la conclusion : Claude Code est par défaut un assistant qui « ne sait travailler qu'en local » ; le MCP est le port qui lui permet de se connecter aux services externes.

Repensez aux vingt et un articles précédents sur ce que fait Claude : il lit vos fichiers, modifie votre code, exécute vos commandes. Il ne s'agit que de choses locales. Aussi intelligent soit-il, il n'a pas accès au ticket ENG-4521 de votre Jira d'entreprise, ni aux données de votre base de données de production, et il ne voit pas les maquettes de vos designers sur Figma. Il ne peut pas atteindre ces informations ; vous devez vous-même les copier/coller pour les lui fournir.

Analogie : un hub (station d'accueil) avec de nombreux ports. Votre ordinateur portable devient de plus en plus fin, il n'a peut-être qu'un ou deux ports Type-C, impossible de brancher de l'HDMI, un câble réseau, une clé USB ou un lecteur de carte. Que faire ? Brancher un hub — un seul câble connecté et vous avez accès au HDMI, réseau, USB, et alimentation. Le MCP est ce hub pour Claude : connectez-le une fois, et une multitude d'outils de services externes s'offrent à lui.

La définition officielle est la suivante :

Claude Code peut se connecter à des centaines d'outils et de sources de données externes via le Model Context Protocol (MCP), une norme open source pour l'intégration d'outils IA. Les serveurs MCP fournissent à Claude Code un accès à vos outils, bases de données et API.

Il y a un mot-clé ici : norme open source. Le MCP (Model Context Protocol, Protocole de Contexte Modèle, une norme ouverte définissant « comment l'IA appelle des outils externes ») n'est pas un protocole propriétaire réservé à Anthropic, c'est un standard public. L'avantage est : « une seule connexion, utilisable partout ». Si vous écrivez un serveur MCP pour une base de données, Claude Code pourra l'utiliser, tout comme d'autres clients compatibles MCP.

Quand devriez-vous penser à l'utiliser ? Le conseil officiel est très terre à terre :

Lorsque vous vous surprenez à copier des données depuis un autre outil (comme un suivi de problèmes ou un tableau de bord de surveillance) dans le chat, connectez un serveur.

Voici quelques scénarios que vous êtes susceptible de rencontrer, pour bien comprendre l'utilité :

• « Implémente la fonctionnalité décrite dans le ticket JIRA ENG-4521, puis ouvre une PR sur GitHub » — il lit le ticket lui-même, pas besoin de lui expliquer.
• « À partir de notre base PostgreSQL, trouve les e-mails des 10 utilisateurs ayant utilisé la nouvelle fonctionnalité ce mois-ci » — il consulte la base directement, pas besoin d'exporter un CSV pour lui.
• « Mets à jour le modèle d'e-mail selon le nouveau design sur Figma » — il va lire le design, pas besoin de captures d'écran.

💡 En résumé : Claude ne peut modifier que des fichiers locaux et des commandes par défaut, il ne peut pas atteindre votre base de données, vos tickets ou vos maquettes ; le MCP est ce port unique, qui une fois connecté, lui offre toute une série d'outils de services externes.

---

02 Trois formes de serveur : exécution en local, ou connexion dans le cloud

Il n'y a pas qu'un seul type de serveur MCP. Comprendre leurs différences vous permettra de savoir comment modifier une commande copiée. La question centrale est : ce serveur s'exécute-t-il sur votre propre machine, ou est-il hébergé sur une adresse web ?

Analogie : les appareils connectés au hub, certains sont sur votre bureau, d'autres à distance. Une clé USB, un lecteur de carte sont branchés sur le hub, juste à côté de vous ; l'autre bout d'un câble réseau est connecté à un serveur dans un centre de données, très loin. Les serveurs MCP sont également divisés en deux catégories — l'un est exécuté en tant que processus local sur votre machine, l'autre est hébergé à distance, et vous vous y connectez.

L'équipe officielle a fourni plusieurs modes de transport (transport, c'est-à-dire comment Claude Code et le serveur communiquent) ; vous n'utiliserez au quotidien que les deux premiers, le dernier étant obsolète :

Forme	Où ça tourne	Comment l'ajouter	Idéal pour
stdio (processus local)	Sur votre machine, en tant que processus enfant	claude mcp add <nom> -- <commande>	Lecture de fichiers locaux, contrôle de navigateur local, connexion à des sockets de base de données locale.
HTTP (hébergé à distance)	Sur une URL spécifique	claude mcp add --transport http <nom> <url>	Services cloud (comme Sentry, Notion, GitHub), recommandé par la documentation officielle.
SSE (distant, obsolète)	Sur une URL spécifique	claude mcp add --transport sse <nom> <url>	Rencontré dans de vieilles configs, utilisez HTTP si possible.

Voici quelques pièges fréquents pour les débutants :

Le serveur stdio ne nécessite pas le drapeau --transport. Comme les processus locaux utilisent par défaut la méthode de transport stdio, il n'est pas nécessaire de le préciser. Ce qui est crucial, c'est la commande qui suit le -- — c'est l'instruction qui dit à Claude Code « comment démarrer ce serveur ». Par exemple, l'exemple officiel avec Playwright (un outil permettant à Claude de contrôler un navigateur) :

claude mcp add playwright -- npx -y @playwright/mcp@latest

Ce qui suit le --, npx -y @playwright/mcp@latest, est la commande de démarrage ; le -y demande à npx d'installer sans demander de confirmation. Un serveur stdio équivaut à « Claude démarre un petit programme en arrière-plan pour vous », donc il nécessite que l'environnement adéquat soit installé sur votre machine (ici, Playwright a besoin d'une version récente de Node).

Le HTTP est le premier choix pour les services cloud. C'est ce que dit la version officielle :

Les serveurs HTTP sont l'option recommandée pour se connecter à des serveurs MCP distants. C'est le transport le plus largement supporté par les services cloud.

Pour Sentry, Notion, GitHub, vous n'avez besoin de rien installer localement, donnez-lui simplement une URL et c'est connecté :

claude mcp add --transport http sentry https://mcp.sentry.dev/mcp

SSE (Server-Sent Events) est à connaître, mais pas à utiliser pour des nouveaux ajouts. La version officielle l'a clairement marqué comme « obsolète » :

Le transport SSE (Server-Sent Events) est obsolète. Veuillez utiliser les serveurs HTTP lorsque cela est possible.

Le SSE se retrouve généralement si vous héritez de l'ancien fichier .mcp.json de quelqu'un ; pour de nouveaux serveurs, utilisez toujours le HTTP.

💡 En résumé : Utilisez stdio pour les outils locaux (suivi de la commande de démarrage après --, pas de spécification du transport), utilisez HTTP pour les services cloud (avec l'URL, recommandé par la version officielle), et SSE est obsolète, remplacez-le si vous le voyez.

---

03 Comment ajouter un serveur : commande, portée, et ce petit piège

Maintenant que vous connaissez les formes, voyons comment les ajouter. Deux commandes de base, et tout le reste, c'est du détail.

Pour ajouter un serveur HTTP distant — --transport http, suivi du nom, suivi de l'URL :

claude mcp add --transport http notion https://mcp.notion.com/mcp

Pour ajouter un serveur stdio local — pas de transport, suivi de la commande de démarrage après -- :

claude mcp add airtable -- npx -y airtable-mcp-server

Et voici le piège du début de l'article, souligné dans un encart Note de la documentation officielle, qui mérite d'être bien gardé en mémoire :

Toutes les options (--transport, --env, --scope, --header) doivent se trouver avant le nom du serveur. Ensuite, -- (le double tiret) sépare le nom du serveur de la commande et des paramètres transmis au serveur MCP.

En termes simples : les drapeaux propres à claude mcp add se mettent tous devant, tout ce qui suit -- est destiné au serveur. Une erreur de position, et la commande ne fonctionnera pas.

Trois portées (scopes) : dans quels projets ce serveur sera-t-il utilisable ?

Lors de l'ajout d'un serveur, un autre choix se pose : ce serveur sera-t-il utilisé uniquement dans le projet en cours, partagé avec l'équipe, ou utilisé pour tous vos projets ? C'est le rôle de la « portée » (scope), spécifiée avec --scope.

Analogie : le partage d'une imprimante au bureau. Certaines imprimantes ne sont connectées qu'à votre ordinateur, vous seul pouvez imprimer (local) ; d'autres sont sur le réseau du département, enregistrées au registre, tous les collègues peuvent s'en servir (project, dans Git) ; enfin, il y a votre petite imprimante portable, que vous transportez et branchez n'importe où (user, inter-projets). Ces trois portées sont les trois niveaux de « où est-il placé, et qui y a accès ».

Voici les différences entre les trois portées proposées par l'équipe officielle :

Portée	Chargé pour quels projets	Partagé avec l'équipe ?	Stocké où
local (par défaut)	Uniquement le projet en cours	Non, privé	~/.claude.json (dans la rubrique du projet)
project	Uniquement le projet en cours	Oui, via le contrôle de version	.mcp.json à la racine du projet
user	Tous vos projets	Non, privé	~/.claude.json (dans mcpServers global)

Pour choisir, retenez ces trois phrases :

• Expérimentation personnelle, avec des identifiants que l'on ne veut pas dans le dépôt de code → local (par défaut, sans --scope).
• Pour que toute l'équipe ait la même configuration → project, écrit dans .mcp.json et committé dans Git, les coéquipiers l'obtiendront en pullant.
• Serveurs que vous utilisez tous les jours pour tous vos projets → user, ajouté une fois, disponible partout.

# Utilisable pour tous les projets (portée user)
claude mcp add --scope user --transport http sentry https://mcp.sentry.dev/mcp

# Partagé avec l'équipe (portée project, écrit dans .mcp.json)
claude mcp add --scope project --transport http github https://api.githubcopilot.com/mcp/

À l'usage, j'ai pris une habitude : les serveurs comme Sentry, GitHub que j'utilise tous les jours pour mes projets personnels, je les mets tous en user — je les ajoute une fois, et ils sont automatiquement là dans les nouveaux projets, évitant de les reconfigurer. Au début, par facilité, j'utilisais toujours local par défaut, ce qui me forçait à réajouter le serveur pour chaque nouveau projet, jusqu'à ce que je comprenne l'intérêt de user. Je n'utilise project dans .mcp.json que lorsque « ce serveur est spécifique à ce projet, et les collaborateurs doivent aussi pouvoir l'utiliser ».

L'écriture directe du .mcp.json

Pour la portée project, vous pouvez aussi éditer manuellement le fichier .mcp.json. C'est simplement du JSON, et les champs pour HTTP et stdio diffèrent :

{
  "mcpServers": {
    "claude-code-docs": {
      "type": "http",
      "url": "https://code.claude.com/docs/mcp"
    },
    "playwright": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "@playwright/mcp@latest"]
    }
  }
}

HTTP nécessite l'url, stdio nécessite command et args. Il est committé dans le dépôt de contrôle de version, constituant ainsi une "configuration as code" pour l'équipe — quiconque le clone et lance Claude Code lira cette configuration. Un rappel officiel : après une modification de .mcp.json, il faut quitter et redémarrer la session pour qu'elle prenne effet, car Claude Code ne la lit qu'au démarrage.

💡 En résumé : Pour le HTTP utilisez --transport http suivi de l'URL, pour le stdio utilisez -- suivi de la commande, tous les drapeaux sont placés avant le nom ; pour la portée retenez les trois usages — expérimentation personnelle local, inter-projet user, et partage en équipe avec .mcp.json via project.

Cette image représente le rôle du MCP comme un « hub (station d'accueil) » : à gauche se trouvent les outils locaux intégrés de Claude Code (lecture/écriture de fichiers, exécution de commandes), à droite le monde externe auquel il n'a pas accès par défaut (GitHub, Jira, PostgreSQL, Figma, Sentry) — au centre, la couche MCP connecte les deux avec des câbles stdio et HTTP, rendant les outils des services externes directement disponibles pour Claude.

---

04 Une fois le serveur ajouté : comment les outils apparaissent-ils, leur appel nécessite-t-il votre approbation ?

Le serveur est ajouté, ce qui se passe ensuite rejoint directement le sujet des autorisations de l'article précédent.

Voyons d'abord comment les outils "apparaissent". Chaque serveur MCP apporte avec lui un lot d'outils (par exemple, un serveur GitHub apporte "lire une PR", "ouvrir un ticket"). Une fois ajouté, ces outils sont enregistrés auprès de Claude, qui peut les utiliser de la même manière que ses outils intégrés. Comment confirmer la connexion et voir quels outils sont disponibles ? Voici deux commandes :

# Dans le terminal : lister tous les serveurs configurés et leur état de connexion
claude mcp list

# Dans la session Claude : voir le statut et les outils de chaque serveur
/mcp

claude mcp list vous montrera l'état de chaque serveur avec des symboles que vous devez connaître (ils sont la réponse à la question "pourquoi mon serveur ne marche pas ?") :

État	Signification
✓ Connected	Connecté, prêt à l'emploi
! Needs authentication	Connecté mais nécessite une connexion (OAuth ou token), allez dans /mcp pour authentifier
✗ Failed to connect / Connection error	Échec de connexion (serveur ne répond pas, ou échec de commande), vérifiez la commande / l'URL
⏸ Pending approval	Serveur de projet provenant de .mcp.json, en attente de votre approbation

Ce ⏸ Pending approval est la première instance où "il vous faut approuver". L'équipe officielle a conçu ce mécanisme avec prudence :

Pour des raisons de sécurité, Claude Code demandera une approbation avant d'utiliser un serveur défini dans un fichier .mcp.json (au niveau du projet).

Pourquoi cette étape ? Imaginez que vous clonez un dépôt, et que son .mcp.json stipule "démarre ce serveur local à l'ouverture". Sans approbation, cela signifierait qu'un dépôt tiers démarre discrètement un processus sur votre machine. L'approbation bloque ce comportement — conformément aux principes de sécurité de l'article précédent, tout ce qui vient d'une source inconnue doit attendre votre feu vert. (Si vous refusez par erreur, claude mcp reset-project-choices réinitialisera ce choix.)

La deuxième approbation a lieu lors de la première utilisation de l'outil. La documentation dit dans le Guide de démarrage rapide :

Lorsque Claude appelle un serveur pour la première fois, il demandera la permission d'utiliser ce nouvel outil. Approuvez-la pour continuer.

Cela veut dire qu'ajouter un serveur ne donne pas à Claude la permission de l'utiliser à sa guise. Lorsqu'il voudra appeler un outil MCP pour la première fois, il s'arrêtera pour vous demander — c'est le même mécanisme d'autorisation que lorsqu'il souhaite modifier un fichier ou exécuter une commande (voir chapitres précédents). Vous devez approuver pour qu'il procède.

Il y a aussi un petit détail pour vous aider à "vérifier l'authenticité" : lorsque Claude appelle un outil MCP, le nom du serveur est indiqué à côté de l'appel de l'outil dans la sortie. Cela vous permet de confirmer que "cette réponse provient bien du service externe, et n'est pas une invention de l'IA". Par exemple, après avoir connecté Sentry, voir sentry à côté de l'appel d'outil vous assure que l'IA a bien consulté le rapport de crash, et qu'elle ne fabrique pas de faux souvenirs.

💡 En résumé : Une fois ajoutés, les outils MCP sont enregistrés pour Claude, avec deux barrières de validation — une pour le chargement d'un serveur de projet .mcp.json, et une pour la première utilisation de l'outil ; le nom du serveur affiché dans la sortie est votre preuve que "la réponse vient de l'extérieur".

---

05 La confiance dans les serveurs tiers : ne branchez pas n'importe quoi

Cette section est courte mais elle ne doit surtout pas être ignorée — elle fait directement suite aux limites de sécurité de l'article précédent.

Reprenons l'avertissement officiel, qui apparaît encadré en rouge Warning dans la documentation :

Avant de connecter un serveur, vérifiez que vous lui faites confiance. Les serveurs qui récupèrent du contenu externe peuvent vous exposer à des risques d'injection de prompts.

En clair : Les serveurs MCP sont du code/services tiers, et Anthropic n'effectuera pas d'audit de sécurité pour vous. Les connecteurs du répertoire officiel (Anthropic Directory) ont fait l'objet d'un examen de base, mais vous devez juger vous-même de la fiabilité des autres serveurs.

Analogie : l'installation d'une dépendance tierce dans un projet de production. Vous ne feriez pas un simple npm install sur un paquet inconnu sans savoir qui le maintient, juste pour le mettre en ligne — vous regarderiez d'abord qui le maintient, combien de personnes l'utilisent, et sa réputation. Le serveur MCP est fondamentalement cette « dépendance tierce » : évaluez sa provenance avant de l'installer, surtout s'il s'agit d'un serveur qui récupère des contenus externes (pages web, tickets, e-mails).

Pourquoi les serveurs qui lisent du contenu externe sont-ils plus risqués ? Parce que c'est le terrain propice à l'injection de prompts (prompt injection) — comme on l'a vu dans l'article précédent. En bref : la page web ou le ticket récupéré par le serveur pourrait cacher des instructions malveillantes « destinées à l'IA », et Claude pourrait être trompé en les lisant. Plus le serveur va chercher loin (dans la "nature"), plus le risque est élevé.

Voici quelques règles empiriques pour la connexion des serveurs :

Scénario	À connecter ou non ?
Connecteurs audités dans le répertoire officiel (Anthropic Directory)	✅ À privilégier
Serveurs officiels de grandes entreprises (GitHub, Sentry, Notion)	✅ Relativement sûrs
N'importe quel serveur tiers avec peu d'étoiles sur GitHub	⚠️ Lisez le code source, réfléchissez avant de le connecter
Donner des droits d'écriture sur votre base de production à un serveur	❌ Restez en lecture seule si possible, ne donnez pas l'écriture

La dernière règle est primordiale. L'exemple officiel de connexion à une base de données utilise spécifiquement un compte readonly dans le DSN — si un compte en lecture seule suffit, ne donnez pas les droits d'écriture, c'est l'approche la plus pragmatique pour minimiser les risques.

💡 En résumé : Les serveurs MCP sont du code tiers, Anthropic ne les audite pas pour vous ; vérifiez la confiance avant connexion, privilégiez le répertoire officiel et les gros acteurs, méfiez-vous des injections de prompts avec les serveurs lisant des contenus externes, et utilisez toujours des comptes en lecture seule pour les bases de données.

---

06 Mise en pratique : Connecter un vrai serveur en 5 minutes

L'action vaut mieux que les mots. Voici comment vous connecter au serveur de documentation officiel — il s'agit d'un serveur HTTP hébergé qui ne nécessite aucune connexion ni configuration particulière, parfait pour l'apprentissage, sans exiger d'environnement complexe.

Note : Ce serveur est un service HTTP hébergé, ce qui nécessite une connexion Internet ; si l'accès à code.claude.com est bloqué dans votre région, activez un proxy/VPN pour tester.

Étape 1 : Ajouter le serveur (dans votre terminal classique, pas dans une session claude)

claude mcp add --transport http claude-code-docs https://code.claude.com/docs/mcp

Résultat attendu : Une ligne de confirmation, similaire à Added HTTP MCP server claude-code-docs with URL: https://code.claude.com/docs/mcp to local config. Si vous voyez Added = la configuration est enregistrée (il précise local config, c'est-à-dire la portée local par défaut, valide uniquement dans le projet actuel).

Étape 2 : Vérifier le statut de la connexion

claude mcp list

Résultat attendu : La liste affichera claude-code-docs avec la mention ✓ Connected. Le coche verte = la connexion a réussi. S'il affiche ✗ Failed to connect, il s'agit probablement d'un problème de réseau (utilisez un proxy/VPN et réessayez).

Étape 3 : Démarrer la session et lui demander d'utiliser le serveur

claude

Une fois dedans, entrez la requête (en précisant le nom du serveur pour s'assurer qu'il l'utilise plutôt que de simplement chercher sur internet par lui-même) :

Utilise le serveur claude-code-docs pour chercher à quoi sert la variable d'environnement MCP_TIMEOUT

Résultat attendu : Claude va s'arrêter lors du premier appel au serveur pour demander votre autorisation (c'est l'étape 04 « approbation de la première utilisation de l'outil ») — donnez-lui l'autorisation. Ensuite, il affichera l'explication de MCP_TIMEOUT (utilisée pour configurer le délai d'attente du démarrage du serveur MCP), et la sortie affichera l'appel d'outil suivi de claude-code-docs. Cela prouve que la réponse provient du serveur de documentation et n'est pas une pure invention du modèle.

Étape 4 : Nettoyage (optionnel)

Pour retirer ce serveur après vos tests :

claude mcp remove claude-code-docs

Résultat attendu : Un message de confirmation de la suppression. En exécutant claude mcp list, claude-code-docs aura disparu de la liste.

Une remarque officielle à retenir : Chaque serveur connecté utilise une part de la fenêtre de contexte (ses noms et descriptions d'outils doivent être chargés pour chaque session). L'article précédent soulignait qu'un contexte saturé rend l'IA plus "bête" — assurez-vous de faire un remove des serveurs inutilisés pour libérer cet espace précieux.

Ces quatre étapes vous permettent de parcourir l'ensemble du cycle de vie d'un serveur MCP : "ajout → vérification du statut → appel approuvé → retrait". Pour tout futur serveur, la démarche sera la même ; vous changerez simplement le nom, l'URL/commande, et ajouterez --scope et d'autres paramètres d'authentification si besoin.

💡 En résumé : Le serveur de documentation officiel est l'idéal pour l'entraînement : add pour ajouter, list pour vérifier la coche verte, appeler et approuver en session, puis remove pour désinstaller ; effectuer cette suite vous en apprendra plus que n'importe quelle longue explication textuelle.

---

07 Résumé

Cet article vous a permis d'ouvrir Claude au monde extérieur — de l'assistant "uniquement local" à un assistant "connecté à de nombreux services via un point central", tout cela grâce au "hub" MCP.

Récapitulatif des points clés :

Objectif	Ce qu'il faut utiliser	Point clé
Comprendre le MCP	Une norme de connexion open source	Claude n'accède pas à l'extérieur par défaut, MCP centralise ces accès
Connecter un outil local	stdio	claude mcp add <nom> -- <commande>, on n'écrit pas transport
Connecter un service cloud	HTTP	--transport http et l'URL, recommandé par la doc
Définir où le serveur est utilisé	scope (Portée)	local (par défaut), user (tous les projets), project (partage équipe, fichier .mcp.json)
Vérifier la connexion/outils	claude mcp list / /mcp	Repérez les statuts ✓ Connected, ⏸ Pending approval
Contrôler l'utilisation des outils par Claude	Deux étapes d'approbation	Chargement initial de serveur de projet, puis premier appel à l'outil

Ce que vous pouvez maintenant faire : Comprendre comment MCP résout la limite de Claude, faire la distinction entre l'ajout de serveurs stdio ou HTTP, assigner correctement un serveur avec --scope, vérifier le statut avec claude mcp list et /mcp, gérer les deux étapes d'autorisation, et jauger le niveau de confiance requis pour les serveurs tiers. Cette "capacité de connexion" vous donne les clés pour transformer Claude de "l'assistant de code local" à un outil pouvant interagir directement avec tous vos flux de travail.

Ce simple point d'entrée vous évitera d'avoir à perdre du temps comme je l'ai fait — retenez « les options avant le nom, la commande après -- », et vous vous épargnerez bien des tracas.

---

Article suivant 23 « Les Sous-agents (Subagents) » — Le MCP donne de nouvelles compétences à Claude, mais lorsque les tâches se multiplient, un seul Claude finira par se sentir dépassé, et sa fenêtre de contexte s'encombrera inévitablement. Le prochain article vous propose une autre méthode : ne laissez pas un seul Claude tout gérer, recrutez plutôt une équipe de petits assistants spécialisés, chacun disposant de son propre contexte. Le délégué distribue les tâches, et les sous-agents travaillent en toute autonomie sans encombrer la session principale. Imaginez pouvoir assigner l'« analyse des logs », « l'écriture de tests » et « le lancement du build » à trois sous-agents qui travailleront en parallèle sans que leurs informations ne se mélangent... N'est-ce pas beaucoup plus efficace que de demander à un seul Claude de jongler avec tout ça ?

---

Lectures recommandées

• GitHub Actions : mentionnez Claude dans une PR, et laissez-le travailler
• Mode Vocal (Voice) : parlez pour exprimer vos instructions, au lieu de les taper
• Intégration avec des modèles tiers / domestiques