MCP

Le problème de maintenance

Supposons que votre agent doive récupérer des tâches depuis Asana, consulter un Google Calendar et effectuer une recherche dans Slack — le tout en une seule fois. Avec des outils personnalisés, vous devez écrire trois intégrations. Cette partie est faisable. La partie pénible vient après : vous devez également maintenir ces intégrations chaque fois que l'un de ces services modifie son API, ce qui arrive souvent. Félicitations, vous voilà désormais en train de maintenir un tas de wrappers d'API tiers.

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

Outils vs Compétences vs MCP

Ces trois fonctionnalités remplissent des rôles différents :

• Les outils connectent Claude à vos systèmes internes — votre base de données, votre outil de 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 de révision. Les Compétences sont des instructions, pas nécessairement des intégrations.
• MCP connecte Claude à des services tiers, où le fournisseur de service maintient l'intégration. Vous n'écrivez pas le wrapper Asana — Asana l'a fait.

En résumé : les outils sont pour vos affaires, les Compétences sont pour vos processus, et MCP est pour les affaires de tout le monde.



Connexion à un serveur MCP

La manière la plus simple de se faire une idée de 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 MCP Linear, avec les détails de connexion et le jeton d'authentification stockés dans un fichier .env.

Deux éléments fonctionnent ensemble dans la requête. La clé mcp_servers déclare la connexion — un type, une URL, un nom pour y faire référence, et éventuellement un jeton d'authentification. Ensuite, un outil avec le type mcp_toolset configure les outils que Claude peut utiliser depuis ce serveur. Par défaut, ce sont tous les outils, mais si vous souhaitez restreindre cela, c'est ici que vous le faites.

import os
import anthropic

client = anthropic.Anthropic()

response = client.beta.messages.create(
    model="claude-opus-5",
    max_tokens=1024,
    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 le moindre schéma d'outil. Claude introspecte le serveur, récupère la liste des outils et leurs schémas, puis choisit celui qui convient pour le prompt. Au moment de cette leçon, le connecteur MCP est en version bêta — notez l'en-tête bêta dans la requête.

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



Filtrer les outils que Claude peut utiliser

Les serveurs MCP exposent souvent de très nombreux outils — et vous ne voulez pas toujours que Claude les utilise tous. Peut-être ne voulez-vous pas qu'il dispose de permissions d'écriture, ou vous ne voulez simplement pas que toutes ces définitions d'outils occupent de la place dans le contexte.

La solution : désactivez tout par défaut, puis activez uniquement les outils spécifiques que vous souhaitez. Voici ce schéma avec un serveur MCP Slack :

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

Désormais, Claude peut effectuer des recherches dans Slack et lister les canaux, mais il ne peut ni publier ni supprimer. Ceci est utile lorsque vous faites confiance à un service pour les lectures mais ne voulez pas que Claude écrive en votre nom par accident.

Récapitulatif

• MCP existe pour que vous n'ayez pas à maintenir des intégrations que quelqu'un d'autre a déjà construites. Le fournisseur de service publie un serveur MCP et le maintient à jour — vous ne changez rien lorsque son API change.
• Choisissez la bonne fonctionnalité pour la tâche : 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, jeton d'authentification optionnel) et accordez l'accès avec une entrée mcp_toolset dans tools. Claude introspecte le serveur et découvre les outils par lui-même — aucun schéma à écrire.
• Restreignez 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 version bêta, pensez donc à inclure l'en-tête bêta dans vos requêtes.
• Visitez modelcontextprotocol.io pour obtenir la liste des serveurs disponibles et en savoir plus sur le protocole.