Authentification et headers — Remote MCP : connecter des outils externes

Prouver qui appelle

DeepWiki et les autres serveurs MCP publics acceptent n’importe quel appelant, ce qui est cohérent avec leur vocation. Dès que vous exposez vos propres outils, la donne change : sans authentification, quiconque devine l’URL peut interroger votre CRM ou déclencher vos traitements. xAI met deux paramètres à votre disposition pour y répondre — authorization pour le jeton d’accès, headers ou extra_headers pour tout le reste.

Le paramètre authorization

Il transmet un token d’authentification au serveur MCP. Concrètement, la chaîne que vous fournissez est placée telle quelle dans l’en-tête HTTP Authorization de chaque requête émise vers ce serveur.

mcp(
    server_url="https://api.example.com/mcp",
    server_label="internal",
    authorization="Bearer sk-votre-token-ici"
)

Le format attendu dépend entièrement du serveur cible, car authorization accepte n’importe quelle chaîne : c’est le serveur MCP qui valide, pas xAI. Trois formes couvrent la quasi-totalité des cas rencontrés.

Bearer token : "Bearer sk-xxxx" — le plus répandu, utilisé par la majorité des API REST
API key : "ApiKey votre-cle" — certains services utilisent un préfixe personnalisé
Basic auth : "Basic base64(user:password)" — authentification basique encodée en base64

Puisque ce token part avec chaque requête, sa gestion mérite un minimum de rigueur. Ne le codez jamais en dur dans votre source : un secret écrit dans un fichier versionné finit tôt ou tard dans un dépôt, un log ou une capture d’écran. Passez systématiquement par une variable d’environnement. Si le serveur le permet, préférez un token à portée limitée, qui n’ouvre que les outils dont vous avez réellement besoin — c’est le pendant côté serveur de la restriction allowed_tool_names. Et prévoyez un renouvellement régulier, particulièrement en production, où un token éternel est un token qui finira par fuiter.

import os

mcp(
    server_url="https://api.example.com/mcp",
    server_label="internal",
    authorization=f"Bearer {os.getenv('MCP_SERVER_TOKEN')}"
)

headers et extra_headers

Le token répond à la question « qui êtes-vous ». Beaucoup de serveurs ont besoin de réponses supplémentaires : pour quelle organisation, sur quel environnement, avec quelle version d’API. Ces informations passent par le paramètre headers, ou extra_headers selon le SDK.

mcp(
    server_url="https://api.example.com/mcp",
    server_label="internal",
    authorization="Bearer sk-token",
    headers={
        "X-Organization-Id": "org-123",
        "X-Project-Id": "proj-456"
    }
)

Le cas le plus fréquent est celui des plateformes multi-tenant, où le même endpoint sert plusieurs clients et s’appuie sur un en-tête pour router la requête vers les bonnes données. Viennent ensuite le versioning d’API, avec un en-tête du type "X-API-Version": "2024-01" qui épingle une version précise et vous protège d’une évolution du serveur. Certains systèmes attendent également des métadonnées de suivi — identifiant de session, identifiant d’agent — pour tracer l’origine des appels, ou des en-têtes de rate limiting qui déterminent le plan tarifaire appliqué.

Le nom du paramètre varie selon l’interface que vous utilisez. Le SDK xAI natif emploie headers dans la plupart des cas ; l’API Responses au format OpenAI peut exiger extra_headers, afin d’éviter toute collision avec les en-têtes que ce SDK gère automatiquement pour son propre compte. Le comportement, lui, est rigoureusement le même : les en-têtes sont ajoutés à chaque requête vers le serveur MCP. Si vos requêtes partent sans vos en-têtes, vérifiez d’abord ce nom de paramètre avant de chercher ailleurs.

Une configuration de production complète

Voici comment ces paramètres s’assemblent avec ceux des leçons précédentes, dans un cas réaliste de serveur interne.

from xai_sdk.tools import mcp
import os

tools = [
    mcp(
        server_url="https://api.monentreprise.com/mcp",
        server_label="interne",
        server_description="Outils internes : CRM, documentation, tickets",
        authorization=f"Bearer {os.getenv('INTERNAL_MCP_TOKEN')}",
        headers={
            "X-Organization-Id": os.getenv("ORG_ID"),
            "X-Environment": "production"
        },
        allowed_tool_names=["search_docs", "get_ticket", "search_contacts"]
    )
]

Cette configuration se connecte au serveur MCP interne en HTTPS, s’authentifie avec un Bearer token stocké en variable d’environnement, envoie l’identifiant d’organisation dans un en-tête, et restreint l’accès à trois opérations de lecture. Notez que chaque ligne verrouille un aspect différent : le chiffrement protège le transport, le token prouve l’identité, l’en-tête cadre le périmètre de données, et la liste blanche limite les dégâts possibles. Aucune de ces couches ne remplace les autres.

Points clés à retenir

authorization transmet le token d’accès au serveur MCP via l’en-tête HTTP Authorization
Stockez toujours vos tokens dans des variables d’environnement, jamais en dur dans le code
headers / extra_headers ajoutent des en-têtes HTTP supplémentaires à chaque requête
Les en-têtes servent à l’identification multi-tenant, au versioning d’API et au suivi
Combinez authentification et restriction d’outils pour un maximum de sécurité