Combiner MCP et outils built-in

Deux familles d’outils, un seul catalogue

Le MCP n’est pas la seule manière de donner des capacités à Grok. L’API xAI embarque des outils natifs, dits built-in, que le modèle peut appeler sans qu’aucun serveur externe soit impliqué. Rien ne vous oblige à choisir entre les deux familles : elles se déclarent au même endroit et se combinent librement dans une même configuration.

Quatre outils natifs couvrent l’essentiel des besoins.

• Web search : recherche en temps réel sur le web
• Code execution : exécution de code Python dans un sandbox
• Image analysis : analyse et description d’images
• File parsing : lecture et extraction de contenu de fichiers

Ils se déclarent dans le tableau tools par leur seul type, sans URL ni label — ce qui se comprend, puisqu’il n’y a aucun serveur distant à désigner.

Les mélanger : rien à apprendre de plus

La syntaxe ne demande aucune construction particulière. Vous placez les objets MCP et les objets natifs côte à côte dans le même tableau.

from xai_sdk import Client
from xai_sdk.tools import mcp

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

chat = client.chat.create(
    model="grok-4.20-0309-reasoning",
    tools=[
        # Outil MCP distant
        mcp(
            server_url="https://mcp.deepwiki.com/mcp",
            server_label="deepwiki",
            server_description="Documentation de projets GitHub"
        ),
        # Outil natif : recherche web
        {"type": "web_search"},
    ],
)

L’API Responses au format OpenAI applique la même logique, l’outil MCP prenant simplement sa forme de dictionnaire typé.

response = client.responses.create(
    model="grok-4.20-0309-reasoning",
    input=[{"role": "user", "content": "Compare React et Vue selon la doc officielle et les tendances actuelles"}],
    tools=[
        {
            "type": "mcp",
            "server_url": "https://mcp.deepwiki.com/mcp",
            "server_label": "deepwiki"
        },
        {"type": "web_search"},
    ],
)

L’orchestration se fait toute seule

Du point de vue du modèle, MCP et natif ne forment qu’un catalogue unique. Grok ne distingue pas un outil qui part sur le réseau vers un serveur tiers d’un outil exécuté par l’infrastructure xAI : il voit des capacités, avec des noms et des descriptions, et sélectionne à chaque étape celle qui avance la réponse.

Prenez la requête « compare la configuration du routing dans Next.js avec les meilleures pratiques actuelles ». Grok appelle d’abord deepwiki__search pour lire la documentation de routing dans le dépôt Next.js, puis web_search pour repérer des articles récents sur les pratiques du moment, et synthétise enfin les deux sources en une réponse cohérente. À aucun moment vous n’avez indiqué cet ordre, ni même que ces deux outils devaient être utilisés ensemble. Le modèle décide seul de la séquence, et vous n’avez pas de logique d’orchestration à écrire.

Deux compositions types

Un agent de recherche technique tire parti d’une documentation de référence, d’une ouverture sur le web et d’une capacité de vérification par le code.

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

Ce trio permet de consulter la documentation d’un projet, de chercher des informations complémentaires en ligne, puis d’exécuter du code pour valider une solution avant de la proposer. Le troisième outil est celui qui change la nature de la réponse : au lieu d’affirmer qu’un extrait fonctionne, l’agent le vérifie.

Un assistant technique interne obéit à une autre logique, où deux serveurs privés portent la connaissance de l’entreprise et le web ne sert que de recours.

tools = [
    mcp(
        server_url="https://kb.monentreprise.com/mcp",
        server_label="kb",
        server_description="Base de connaissances interne",
        authorization=f"Bearer {os.getenv('KB_TOKEN')}"
    ),
    mcp(
        server_url="https://jira.monentreprise.com/mcp",
        server_label="jira",
        server_description="Tickets et projets Jira",
        authorization=f"Bearer {os.getenv('JIRA_TOKEN')}",
        allowed_tool_names=["search_issues", "get_issue"]
    ),
    {"type": "web_search"},
]

L’assistant cherche dans la base de connaissances, consulte les tickets Jira liés, et complète par une recherche web si l’information manque en interne. Notez la restriction sur Jira, limitée à la consultation : sans elle, une instruction mal intentionnée glissée dans le corps d’un ticket pourrait pousser le modèle vers une opération d’écriture.

Le coût caché de l’abondance

Chaque outil ajouté, MCP ou natif, occupe de la place dans la fenêtre de contexte pour y loger sa définition. Une configuration généreuse se paie donc en espace disponible pour la conversation, en temps de traitement, et en précision de sélection.

Trois réflexes suffisent à contenir cette dérive. Limitez le nombre total d’outils, et résistez à la tentation de brancher cinq serveurs de cinquante outils quand votre cas d’usage en réclame dix. Appliquez allowed_tool_names sur chaque serveur MCP pour ne conserver que les outils pertinents. Et n’ajoutez pas d’outil natif « au cas où » : si votre agent n’a aucune raison d’exécuter du code, code_interpreter n’est pas une option gratuite, c’est du contexte consommé et une occasion supplémentaire de se tromper d’outil.

Points clés à retenir

• Les outils MCP et les outils natifs (web search, code execution) coexistent dans le même tableau tools
• Grok orchestre automatiquement les appels entre outils MCP et natifs selon la requête
• La combinaison permet de créer des agents puissants qui exploitent à la fois des sources internes (MCP) et externes (web search)
• Limitez le nombre total d’outils pour préserver le contexte et la précision du modèle
• Utilisez allowed_tool_names pour chaque serveur MCP afin de réduire le bruit