Récapitulatif et mise en pratique

Le chemin parcouru

Ce cours vous a mené du concept de Model Context Protocol jusqu’à une configuration déployable en production. Si vous ne deviez retenir qu’une phrase, ce serait celle-ci : le MCP permet à Grok de se connecter à des serveurs d’outils externes via HTTPS, en découvrant et en utilisant automatiquement les outils exposés, sans configuration manuelle côté client.

Sur le plan de l’architecture, quatre points structurent tout le reste. Le MCP distant fonctionne exclusivement sur HTTPS, ce qui exclut le HTTP en clair, localhost et le transport stdio des serveurs locaux. Deux transports sont supportés, le Streaming HTTP moderne et stateless et le SSE à connexion persistante, et c’est le serveur qui impose lequel — vous n’avez rien à choisir. Trois interfaces enfin donnent accès à ce mécanisme : le SDK xAI natif, recommandé, l’API Responses pour la compatibilité OpenAI, et l’API Voice Agent pour les agents vocaux.

Les six paramètres, en un coup d’oeil

Deux obligatoires, quatre optionnels : c’est toute la surface de configuration du MCP distant. Les quatre optionnels ne sont pas du confort pour autant, puisque allowed_tool_names porte votre sécurité et server_description la précision de sélection dès que plusieurs serveurs cohabitent.

Vérifier avant de mettre en production

Trois familles de contrôles méritent une passe explicite. Côté sécurité, assurez-vous que les URL sont en HTTPS avec des certificats valides, que chaque serveur interne possède son token d’authentification, que ces tokens vivent dans des variables d’environnement, que les outils sont restreints au minimum nécessaire, et qu’une rotation régulière des tokens est planifiée plutôt qu’espérée.

Côté configuration, chaque serveur doit porter un server_label unique et descriptif, ses server_description doivent être précises et surtout à jour — une description qui décrit une version antérieure du serveur induit le modèle en erreur. Gardez le nombre total d’outils raisonnable, autour de dix à vingt par session, et retirez de la configuration les serveurs dont personne n’appelle plus les outils.

Côté observabilité, prévoyez avant l’incident plutôt qu’après : les appels d’outils tracés dans vos logs, une alerte sur les erreurs de connexion MCP, un suivi de l’utilisation des tokens par serveur, et une mesure de la latence des appels. Cette dernière est souvent négligée alors qu’elle constitue le premier signal d’un serveur qui se dégrade.

Votre premier agent, en trois paliers

La meilleure façon de consolider ce cours est de construire progressivement. Commencez par un serveur public, sans authentification, pour valider que la mécanique fonctionne de bout en bout.

from xai_sdk import Client
from xai_sdk.tools import mcp
import os

client = Client(api_key=os.getenv("XAI_API_KEY"))

chat = client.chat.create(
    model="grok-4.20-0309-reasoning",
    tools=[
        mcp(
            server_url="https://mcp.deepwiki.com/mcp",
            server_label="deepwiki"
        )
    ],
)

Testez avec une requête qui oblige réellement le modèle à consulter le dépôt, du type « explique-moi l’architecture du projet fastapi/fastapi ». Si la réponse arrive et cite la structure réelle du projet, votre connexion MCP est opérationnelle.

Ajoutez ensuite un outil natif pour voir Grok arbitrer entre deux sources de nature différente. La description du serveur devient utile ici, précisément parce qu’il y a désormais un choix à faire.

tools=[
    mcp(
        server_url="https://mcp.deepwiki.com/mcp",
        server_label="deepwiki",
        server_description="Documentation de projets GitHub open-source"
    ),
    {"type": "web_search"},
]

Franchissez enfin le pas du serveur interne, avec authentification et restriction d’outils. C’est le palier où tout ce que vous avez vu sur la sécurité prend un sens concret.

tools=[
    mcp(server_url="https://mcp.deepwiki.com/mcp", server_label="deepwiki"),
    mcp(
        server_url="https://api.votre-serveur.com/mcp",
        server_label="interne",
        server_description="Données et outils internes de l'entreprise",
        authorization=f"Bearer {os.getenv('INTERNAL_TOKEN')}",
        allowed_tool_names=["search", "get_document"]
    ),
    {"type": "web_search"},
]

Ce qui restera vrai après ce cours

Quatre limites accompagneront tous vos projets MCP avec Grok. L’API Responses au format OpenAI ne supporte ni require_approval ni connector_id, ce qui vous ramène au SDK natif dès que vous voulez une validation humaine avant exécution. Le transport stdio, et donc les serveurs MCP locaux, reste hors de portée : HTTPS uniquement. Chaque outil exposé consomme du contexte, ce qui fait de la sobriété une décision d’architecture et non une coquetterie. Et la latence réseau s’additionne à chaque appel, si bien qu’un agent enchaînant plusieurs outils MCP répondra plus lentement qu’un agent qui n’en appelle qu’un.

Aucune de ces contraintes n’est bloquante. Toutes se contournent par des choix de conception faits en connaissance de cause, ce qui est précisément ce que ce cours vous a donné.

Points clés à retenir

• Le MCP distant connecte Grok à des outils externes via HTTPS en quelques lignes de configuration
• Six paramètres suffisent pour configurer un serveur MCP (deux obligatoires, quatre optionnels)
• La sécurité repose sur le trio HTTPS + authentification + restriction d’outils
• Commencez par un serveur public (DeepWiki) puis progressez vers le multi-serveur authentifié
• Combinez MCP et outils natifs pour créer des agents polyvalents

Testez vos connaissances

Serveurs MCP distants dans l’API Grok : le récapitulatif se mérite.

Déclarer, restreindre, authentifier, combiner : le MCP distant étend Grok à vos systèmes — sous vos règles.