DeepWiki et outils custom

DeepWiki, le serveur public sur lequel s’exercer

Tout ce que vous avez vu jusqu’ici reste abstrait tant que vous n’avez pas branché un vrai serveur. DeepWiki est le candidat idéal pour ce premier essai : il expose un serveur MCP public à l’adresse https://mcp.deepwiki.com/mcp, sans authentification, qui donne accès à la documentation de n’importe quel projet GitHub.

La configuration tient en quelques lignes, puisque le seul paramètre optionnel réellement utile ici est la description.

from xai_sdk.tools import mcp

tools = [
    mcp(
        server_url="https://mcp.deepwiki.com/mcp",
        server_label="deepwiki",
        server_description="Documentation de projets open-source GitHub. Recherche et consultation de code, README, guides."
    )
]

Une fois cette connexion établie, adressez à Grok des questions qui exigent réellement d’aller lire le dépôt : « explique-moi comment fonctionne le routing dans le projet facebook/react », « quelles sont les options de configuration de vercel/next.js ? », ou « montre-moi la structure du projet langchain-ai/langchain ». Le modèle appelle les outils DeepWiki, récupère documentation et code source, puis synthétise une réponse structurée. Comparez cette réponse à celle que vous obtiendriez sans le serveur MCP : la différence entre ce que le modèle sait et ce qu’il vient de lire saute aux yeux.

Passer à vos propres serveurs

DeepWiki est un excellent terrain d’entraînement, mais la valeur réelle du MCP apparaît quand le serveur expose ce que personne d’autre ne peut exposer : vos données, vos processus, vos outils métier.

Techniquement, un serveur MCP est une application web qui répond à deux types de requêtes. La découverte d’abord : quand Grok se connecte, il demande la liste des outils disponibles avec leurs schémas. L’exécution ensuite : quand le modèle décide d’appeler un outil, il transmet le nom de celui-ci et ses arguments, et attend le résultat. Le serveur doit exposer un endpoint HTTPS conforme au protocole MCP, en Streaming HTTP ou en SSE — les deux transports vus au début du cours.

Ce qui rend un serveur custom intéressant, ce n’est pas sa technique mais le choix des outils qu’il publie. Voici trois exemples de découpage cohérent, où chaque serveur couvre un domaine et un seul :

Serveur "analytics" :
  - get_dashboard_metrics : métriques du tableau de bord
  - query_events : interroger les événements analytiques
  - get_funnel_report : rapport d'entonnoir de conversion

Serveur "content" :
  - search_articles : recherche dans le CMS
  - get_article : récupérer un article complet
  - list_categories : lister les catégories de contenu

Serveur "devops" :
  - get_deploy_status : statut du dernier déploiement
  - list_alerts : alertes de monitoring actives
  - get_service_health : santé d'un service spécifique

Ce découpage par domaine n’est pas décoratif : il vous permet ensuite de doser l’authentification et les restrictions serveur par serveur, plutôt que d’appliquer une règle unique à un fourre-tout d’outils hétérogènes. Une fois votre serveur déployé, la connexion suit exactement le schéma de DeepWiki, enrichi du token et de la liste blanche.

tools = [
    mcp(
        server_url="https://mcp.monentreprise.com/analytics",
        server_label="analytics",
        server_description="Métriques et rapports d'analyse. Tableaux de bord, funnels, événements.",
        authorization=f"Bearer {os.getenv('ANALYTICS_TOKEN')}",
        allowed_tool_names=["get_dashboard_metrics", "query_events"]
    )
]

Public et interne dans la même session

C’est en mélangeant les deux familles que les configurations deviennent réellement intéressantes, car le modèle peut alors rapprocher une source publique d’une source que lui seul possède.

tools = [
    # Serveur public pour la documentation open-source
    mcp(
        server_url="https://mcp.deepwiki.com/mcp",
        server_label="deepwiki",
        server_description="Documentation de projets GitHub open-source"
    ),
    # Serveur interne pour la documentation produit
    mcp(
        server_url="https://docs.monentreprise.com/mcp",
        server_label="docs-internes",
        server_description="Documentation technique interne, guides d'architecture, ADR",
        authorization=f"Bearer {os.getenv('DOCS_TOKEN')}"
    ),
    # Serveur interne pour les données métier
    mcp(
        server_url="https://api.monentreprise.com/mcp",
        server_label="données",
        server_description="Données métier : clients, commandes, inventaire",
        authorization=f"Bearer {os.getenv('API_TOKEN')}",
        allowed_tool_names=["search_customers", "get_order", "check_inventory"]
    ),
]

Demandez alors à Grok de comparer la documentation officielle de React avec votre guide d’architecture interne sur le routing : il interroge DeepWiki pour la première et votre serveur de documentation pour le second, puis confronte les deux. Aucun modèle ne peut produire cette réponse depuis ses seules connaissances, et aucune recherche web non plus, puisque la moitié de la matière n’existe que chez vous.

Remarquez enfin comment les trois serveurs sont configurés différemment. Le serveur public n’a ni token ni liste blanche, la documentation interne a un token mais reste largement ouverte car elle est en lecture, et les données métier cumulent token et restriction stricte à trois opérations. Chaque serveur porte le niveau de contrôle que son contenu justifie — c’est exactement l’intérêt de les séparer.

Points clés à retenir

• DeepWiki (https://mcp.deepwiki.com/mcp) est un serveur MCP public prêt à l’emploi pour la documentation GitHub
• Vous pouvez créer vos propres serveurs MCP pour exposer des outils spécifiques à votre métier
• Un serveur MCP custom est une application web HTTPS qui répond aux requêtes de découverte et d’exécution
• La combinaison de serveurs publics et internes donne les configurations les plus puissantes
• Chaque serveur garde son propre niveau d’authentification et de restriction d’outils