Le connecteur MCP de l'API Claude accepte-t-il un serveur stdio local ?

Non. La documentation indique que le serveur doit être exposé publiquement en HTTP (Streamable HTTP ou SSE) ; un serveur stdio local ne peut pas être connecté directement.

Qui gère le jeton OAuth avec le connecteur MCP ?

Vous. L'application qui appelle l'API mène le parcours OAuth, obtient le jeton d'accès, le rafraîchit au besoin et le passe dans authorization_token.

Le connecteur MCP de l'API Claude : mcp_servers

Le connecteur MCP (Model Context Protocol) de l'API Claude (l'interface de programmation d'Anthropic) permet d'utiliser les outils d'un serveur MCP distant directement dans un appel à l'API Messages, sans écrire de client MCP. On décrit le serveur dans un tableau mcp_servers, on choisit ses outils avec un élément mcp_toolset dans tools, et Claude les appelle comme n'importe quel outil. La fonction est en bêta. Informations relevées le 15/11/2026 sur la documentation d'Anthropic.

Les limites à connaître d'abord

Seuls les outils sont pris en charge : ni ressources ni prompts.
Le serveur doit être public, en HTTP : Streamable HTTP et SSE (Server-Sent Events) sont acceptés ; un serveur local en stdio ne peut pas être branché directement.
L'adresse doit commencer par https://.
Bêta : la documentation liste les en-têtes mcp-client-2026-09-15 et mcp-client-2025-11-20 ; l'ancienne version mcp-client-2025-04-04 est dépréciée.
Conservation des données : la documentation précise que le connecteur n'est pas couvert par les accords de non-conservation des données (ZDR, zero data retention) ; les échanges avec les serveurs MCP, définitions d'outils et résultats compris, suivent la politique de conservation standard d'Anthropic.

L'exemple de base

En Python, d'après la documentation :

client = anthropic.Anthropic()

response = client.beta.messages.create(
    model="claude-opus-5-5",
    max_tokens=1000,
    messages=[{"role": "user", "content": "What tools do you have available?"}],
    mcp_servers=[
        {
            "type": "url",
            "url": "https://example-server.modelcontextprotocol.io/sse",
            "name": "example-mcp",
            "authorization_token": "YOUR_TOKEN",
        }
    ],
    tools=[{"type": "mcp_toolset", "mcp_server_name": "example-mcp"}],
    betas=["mcp-client-2025-11-20"],
)

Ne mettez jamais un vrai jeton en dur dans le code : lisez-le depuis une variable d'environnement ou un coffre à secrets.

Décrire le serveur : mcp_servers

Champ	Obligatoire	Rôle
`type`	Oui	Seule valeur acceptée : `url`
`url`	Oui	Adresse du serveur, en `https://`
`name`	Oui	Identifiant unique, repris par exactement un `mcp_toolset`
`authorization_token`	Non	Jeton OAuth si le serveur en demande un

Choisir les outils : mcp_toolset

Un mcp_toolset porte mcp_server_name, et en option un default_config (réglage par défaut de tous les outils) et des configs (réglages outil par outil, prioritaires). Chaque outil accepte enabled (activé, vrai par défaut) et defer_loading (ne pas envoyer d'emblée la description au modèle, à combiner avec l'outil de recherche d'outils).

Trois façons de faire :

Tout activer : un simple {"type": "mcp_toolset", "mcp_server_name": "..."}.
Liste blanche : default_config à enabled: false, puis enabled: true sur les seuls outils voulus.
Liste noire : tout est activé, et vous désactivez les outils à risque. La documentation recommande de désactiver les outils d'écriture ou destructifs pour un assistant en lecture seule, ou quand vous voulez une confirmation humaine avant tout changement.

Règles vérifiées par l'API : chaque serveur déclaré doit être utilisé par exactement un mcp_toolset, et chaque mcp_toolset doit viser un serveur déclaré. Un nom d'outil inconnu dans configs produit un avertissement côté serveur, pas une erreur.

Ce que renvoie l'API

Quand Claude utilise un outil MCP, la réponse contient deux nouveaux types de blocs : mcp_tool_use (l'appel) et mcp_tool_result (le résultat). Contrairement au tool use classique, vous n'exécutez rien : l'API appelle le serveur pour vous. Voir MCP ou function calling pour la différence entre les deux mécanismes.

L'authentification

Pour un serveur protégé par OAuth (le standard de délégation d'accès), c'est à votre application de mener le parcours d'autorisation, d'obtenir le jeton d'accès avant l'appel et de le rafraîchir au besoin, puis de le passer dans authorization_token. Pour obtenir un jeton de test, la documentation renvoie à MCP Inspector (voir tester un serveur avec MCP Inspector). Le côté serveur de l'autorisation est expliqué sur la page MCP distant et OAuth.

Quand l'utiliser

Vous construisez une application sur l'API Claude et le service à brancher a déjà un serveur MCP distant.
Vous voulez limiter précisément les outils exposés au modèle, requête par requête.

Si vos outils sont locaux, ou si vous avez besoin de ressources et de prompts, il faut un vrai client MCP, ou un hôte comme Claude Desktop ou Claude Code.