Configuration multi-serveur

Plusieurs sources, un seul agent

Le MCP distant prend toute sa dimension quand vous branchez Grok sur plusieurs serveurs à la fois. Chacun apporte ses outils, et le modèle arbitre seul entre eux selon la requête reçue. C’est ce qui sépare un agent qui sait faire une chose d’un agent qui sait mener une enquête : consulter le statut d’un service, puis l’historique d’un client, puis un article de dépannage, sans que vous ayez écrit la moindre ligne d’orchestration.

La syntaxe : rien de nouveau, juste plusieurs entrées

Il n’existe pas de mode multi-serveur à activer. Vous ajoutez simplement plusieurs objets MCP dans le tableau tools.

from xai_sdk.tools import mcp

tools = [
    mcp(server_url="https://mcp.deepwiki.com/mcp", server_label="deepwiki"),
    mcp(server_url="https://your-custom-tools.com/mcp", server_label="custom"),
    mcp(server_url="https://api.example.com/tools", server_label="api-tools"),
]

Le même principe s’applique à l’API Responses au format OpenAI, où chaque serveur devient un dictionnaire du tableau. Cette version ajoute les descriptions, dont vous allez voir qu’elles cessent d’être facultatives dès qu’on dépasse un serveur.

tools = [
    {
        "type": "mcp",
        "server_url": "https://mcp.deepwiki.com/mcp",
        "server_label": "deepwiki",
        "server_description": "Documentation de projets open-source GitHub"
    },
    {
        "type": "mcp",
        "server_url": "https://your-custom-tools.com/mcp",
        "server_label": "custom",
        "server_description": "Outils internes de l'entreprise"
    },
    {
        "type": "mcp",
        "server_url": "https://api.example.com/tools",
        "server_label": "api-tools",
        "server_description": "API de données et d'analyse"
    },
]

Les labels deviennent structurants

Le server_label, jusqu’ici confort de lecture, devient ici indispensable. Prenez un cas très banal : vous connectez votre documentation interne et DeepWiki, et tous deux exposent un outil nommé search. Sans labels distincts, deux outils portent le même nom et Grok n’a aucun moyen de trancher. Avec les labels, deepwiki__search interroge la documentation GitHub tandis que docs-internes__search fouille votre base de connaissances — deux outils clairement séparés, que le modèle choisit à partir des descriptions et du fil de la conversation.

Trois règles suffisent à ne jamais rencontrer de problème. Chaque label doit être unique dans la configuration. Il doit refléter la source de données plutôt que la fonction technique, car c’est la provenance qui distingue les serveurs entre eux, pas ce qu’ils font. Et il doit rester court sans devenir interchangeable. Le contraste ci-dessous illustre l’écart entre les deux approches :

# Bon : labels descriptifs et distincts
server_label="deepwiki"
server_label="crm"
server_label="jira"

# Mauvais : labels ambigus
server_label="server1"
server_label="server2"
server_label="tools"

Les labels de la seconde série sont un piège différé. Ils fonctionnent le jour où vous les écrivez, parce que vous savez ce que contient server1. Six mois plus tard, en relisant un log d’incident, plus personne ne le sait — et le modèle, lui, ne l’a jamais su.

Comment Grok sélectionne un serveur

Face à plusieurs serveurs, le modèle croise quatre sources d’information pour décider. Il part de la requête utilisateur, c’est-à-dire de ce qui est réellement demandé. Il consulte ensuite le server_description de chaque serveur, qui lui dit à quoi sert celui-ci dans l’ensemble. Il descend d’un cran vers les noms et descriptions des outils eux-mêmes, chaque outil portant les siens. Et il tient compte du contexte de la conversation, puisque les messages précédents pèsent sur la sélection : si le client vous a déjà donné son numéro de compte trois tours plus tôt, Grok sait qu’il peut appeler crm__get_customer sans redemander.

De ces quatre sources, la deuxième est celle sur laquelle vous avez le plus de prise, et c’est précisément pourquoi les descriptions changent de statut en multi-serveur. Privé de descriptions, Grok se rabat sur les seuls noms d’outils — un search face à un autre search, sans indication de ce qu’ils indexent. Les erreurs de sélection qui en découlent sont d’autant plus déroutantes qu’elles semblent aléatoires : le modèle choisit correctement la moitié du temps, par chance.

Un agent de support de bout en bout

Cette configuration réunit tout ce qui précède dans un cas d’usage complet.

tools = [
    mcp(
        server_url="https://kb.monentreprise.com/mcp",
        server_label="knowledge",
        server_description="Base de connaissances produit. Articles d'aide, FAQ, guides de dépannage.",
        allowed_tool_names=["search_articles", "get_article"]
    ),
    mcp(
        server_url="https://crm.monentreprise.com/mcp",
        server_label="crm",
        server_description="CRM. Historique client, tickets précédents, informations de compte.",
        authorization=f"Bearer {os.getenv('CRM_TOKEN')}",
        allowed_tool_names=["get_customer", "search_tickets", "get_ticket"]
    ),
    mcp(
        server_url="https://status.monentreprise.com/mcp",
        server_label="status",
        server_description="Statut des services. Incidents en cours, maintenances planifiées.",
        allowed_tool_names=["get_current_status", "list_incidents"]
    ),
]

Un client écrit « mon service ne fonctionne plus ». Grok vérifie d’abord s’il existe un incident en cours via status__get_current_status, consulte le compte du client avec crm__get_customer pour savoir de quel service il s’agit, puis cherche un article de dépannage par knowledge__search_articles. Cet enchaînement n’est écrit nulle part dans votre code : il découle des descriptions et de la question posée. Notez aussi que chaque serveur reste restreint à ses opérations de lecture — la puissance du multi-serveur ne dispense jamais de la liste blanche.

Points clés à retenir

• Passez plusieurs objets MCP dans le tableau tools pour le multi-serveur
• Chaque serveur doit avoir un server_label unique et descriptif
• Les server_description sont essentielles pour guider Grok vers le bon serveur
• Grok choisit automatiquement le serveur adapté en fonction de la requête et du contexte
• Restreignez les outils de chaque serveur avec allowed_tool_names pour limiter le bruit