Le problème de la maintenance

Nous avons des outils, des compétences et des connecteurs. Alors pourquoi MCP existe-t-il ? À première vue, cela ressemble à une deuxième API empilée sur l'API. Question légitime — et la réponse tient à qui maintient le code d'intégration.

Supposons que votre agent doit extraire des tâches d'Asana, vérifier un Google Calendar et rechercher dans Slack — tout en même temps. Avec des outils personnalisés, vous devez écrire trois intégrations. Cette partie est faisable. La partie douloureuse vient après : vous devez aussi maintenir ces intégrations chaque fois que l'un de ces services change son API, ce qui arrive souvent. Félicitations, vous maintenez maintenant un tas de wrappers d'API tiers.

MCP transfère cette maintenance au fournisseur de services. Asana publie un serveur MCP. Slack en publie un. Google en publie un. Chaque serveur expose ses propres outils — avec des descriptions, des schémas et l'authentification — via un protocole standard. Quand leur API change, ils mettent à jour leur serveur. Vous ne changez rien.

Outils vs. compétences vs. MCP

Ces trois fonctionnalités font des travaux différents :

Les outils connectent Claude à vos systèmes internes — votre base de données, votre suivi de projet, vos API propriétaires. Vous possédez le code, donc vous possédez aussi la maintenance.
Les compétences enseignent à Claude une procédure — votre modèle de rapport, votre liste de contrôle d'examen. Les compétences sont des instructions, pas nécessairement des intégrations.
MCP connecte Claude aux services tiers, où le fournisseur de services maintient l'intégration. Vous n'écrivez pas le wrapper Asana — Asana l'a fait.

En résumé : les outils sont pour vos données, les compétences sont pour vos processus, et MCP est pour les données de tout le monde d'autre.

Cartes de comparaison pour les outils, les compétences et MCP, avec la carte MCP en surbrillance : connecte Claude aux services tiers, maintenu par le fournisseur de services

Connexion à un serveur MCP

La façon la plus claire de comprendre MCP est de pointer Claude vers n'importe quel serveur MCP et de le laisser découvrir ce qui s'y trouve. Pour cet exemple, nous utiliserons le serveur Linear MCP, avec les détails de connexion et le token d'authentification stockés dans un fichier . env.

Deux éléments travaillent ensemble dans la requête. La clé mcp_servers déclare la connexion — un type, une URL, un nom pour s'y référer, et optionnellement un token d'authentification. Ensuite, un outil avec le type mcp_toolset configure les outils que Claude peut utiliser à partir de ce serveur. Par défaut, c'est tous, mais si vous voulez le réduire, c'est ici que vous le faites.

import os import anthropic

client = anthropic. Anthropic()

response = client. beta. messages. create( model="claude-opus-4-8", max_tokens=1000, messages=[ {"role": "user", "content": "What tools do you have available? "} ], mcp_servers=[ { "type": "url", "url": "https://mcp. linear. app/mcp", "name": "linear", "authorization_token": os. environ["LINEAR_MCP_TOKEN"], } ], tools=[ { "type": "mcp_toolset", "mcp_server_name": "linear", } ], betas=["mcp-client-2025-11-20"], )

print(response)

Remarquez que nous n'avons jamais écrit un seul schéma d'outil. Claude introspect le serveur, récupère la liste des outils et leurs schémas, et choisit le bon pour le prompt. À partir de cette leçon, le connecteur MCP est en bêta — notez l'en-tête bêta dans la requête.

Exécutez-le, et si votre URL MCP pointe vers le point de terminaison MCP de Linear, Claude liste les outils de Linear et en appelle un. La même chose fonctionne pour pratiquement n'importe quel serveur conforme. Nous n'avons défini aucun outil. Nous n'avons pas écrit de client Linear. Linear maintient cela.

Sortie du terminal listant les outils découverts du serveur Linear MCP, suivie de Claude notant qu'il s'agit d'outils de gestion de projet Linear et choisissant lequel appeler

Filtrer les outils que Claude peut utiliser

Les serveurs MCP exposent souvent beaucoup, beaucoup d'outils — et vous ne voulez pas toujours que Claude les utilise tous. Peut-être que vous ne voulez pas qu'il ait des permissions d'écriture, ou vous ne voulez simplement pas que toutes ces définitions d'outils occupent du contexte.

La solution : désactiver tout par défaut, puis activer uniquement les outils spécifiques que vous voulez. Voici ce modèle avec un serveur Slack MCP :

tools=[ { "type": "mcp_toolset", "mcp_server_name": "slack", "default_config": { "enabled": False, }, "configs": { "search_messages": {"enabled": True}, "list_channels": {"enabled": True}, }, } ]

Maintenant Claude peut rechercher dans Slack et lister les canaux, mais il ne peut pas poster ou supprimer. C'est utile quand vous faites confiance à un service pour les lectures mais que vous ne voulez pas que Claude écrive en votre nom par accident.

Récapitulatif

MCP existe pour que vous n'ayez pas à maintenir les intégrations que quelqu'un d'autre a déjà construites. Le fournisseur de services publie un serveur MCP et le maintient à jour — vous ne changez rien quand leur API change.
Choisissez la bonne fonctionnalité pour le travail : les outils pour vos données, les compétences pour votre processus, MCP pour les services tiers.
Déclarez la connexion dans mcp_servers (type, URL, nom, token d'authentification optionnel) et accordez l'accès avec une entrée mcp_toolset dans tools. Claude introspect le serveur et découvre les outils par lui-même — aucun schéma à écrire.
Réduisez l'accès en définissant default_config: {"enabled": False} et en activant des outils spécifiques dans configs — pratique pour garder un serveur en lecture seule.
Le connecteur MCP est actuellement en bêta, donc incluez l'en-tête bêta sur vos requêtes.
Visitez **modelcontextprotocol. io** pour la liste des serveurs disponibles et pour en savoir plus sur le protocole.