Accueil / Étendre : compétences, MCP, sous-agents, hooks, plugins

Connecter un serveur MCP et ce qui a changé

Un serveur MCP se connecte par OAuth ou par clé, se vérifie par claude mcp list, et le protocole lui-même a changé de cœur le 28 juillet 2026, un fait indépendant de toute version de Claude Code.

Un serveur MCP distant se connecte en une commande : claude mcp add --transport http nom-du-serveur https://exemple.example.com/mcp déclare l'entrée, et Claude Code détecte lui-même si une authentification est nécessaire. Quand le serveur répond 401 ou 403, Claude Code marque l'entrée comme nécessitant une authentification et propose claude mcp login pour ouvrir le flux OAuth, ou l'option --header "Authorization: Bearer ..." pour un jeton fixe passé à la main.

Vérifier avant de faire confiance

claude mcp list affiche l'état réel de chaque serveur déclaré, avec au moins six statuts possibles : connecté, authentification nécessaire, échec de connexion, approbation en attente, rejeté d'après le réglage disabledMcpjsonServers, ou désactivé pour ce projet et réactivable par /mcp ; un serveur HTTP ou SSE déjà utilisé peut aussi s'afficher en cache. Un échec de connexion signale que Claude Code n'a pas réussi à joindre ce serveur précis, pas que la commande list elle-même a échoué, une nuance qui évite de blâmer le mauvais maillon.

$ claude mcp list
depot-tickets       Connected
facturation-api      Needs authentication
brouillon-crm        Pending approval

La portée choisie à l'ajout détermine qui voit ce serveur. Par ordre de priorité décroissante : la portée locale (--scope local, la valeur par défaut, privée, stockée dans ~/.claude.json), puis la portée projet (--scope project, le fichier .mcp.json partagé par git, décrit dans la leçon précédente), puis la portée utilisateur (--scope user, disponible sur tous les projets du poste). Quand deux portées déclarent le même nom de serveur, l'entière configuration de la portée la plus forte est utilisée, rien ne se fusionne champ par champ entre les deux.

Le protocole a changé de cœur le 28 juillet 2026

Indépendamment de Claude Code, la spécification MCP elle-même a changé de forme. La révision publiée le 28 juillet 2026 remplace un cœur avec état, où client et serveur ouvraient d'abord une poignée de main initialize avant tout échange, par un cœur sans état où chaque requête porte ses propres informations de version dans un paramètre _meta. L'en-tête Mcp Session Id disparaît du transport HTTP. La fonctionnalité Tasks, qui permettait de suivre un travail long sans bloquer la réponse, sort du cœur du protocole et devient une extension officielle séparée, avec un sondage tasks/get à la place d'une attente bloquante. Un champ extensions s'ajoute par ailleurs aux capacités du client et du serveur, pour porter d'éventuelles extensions futures au delà du cœur du protocole.

Depuis la version 2.1.232, Claude Code choisit un runtime MCP au démarrage et le garde jusqu'à la sortie. Le runtime v1 reste utilisé sur Bedrock, Claude Platform on AWS, Vertex, Foundry, derrière une passerelle Claude apps, ou quand la récupération de drapeaux de fonctionnalité est coupée. Ailleurs, le runtime v2 négocie automatiquement, avec les serveurs HTTP et les connecteurs claude.ai, la révision de protocole la plus récente que chacun accepte, mais pour un serveur stdio, exactement le type de serveur que la leçon suivante apprend à écrire, cette négociation n'a lieu que si la variable MCP_PROTOCOL_NEGOTIATION vaut auto : sinon la connexion se fait comme en v1. Un serveur ancien, écrit avant juillet 2026, continue donc de fonctionner dans tous les cas, la négociation, quand elle a lieu, choisissant la révision qu'il comprend. Cette section décrit l'état du protocole au 2 septembre 2026, un sujet qui bouge au rythme de ses propres versions, pas de celui du cours. La leçon suivante montre comment écrire, côté serveur, le programme que cette commande claude mcp add vient de déclarer.