Description et outils autorisés

Deux leviers optionnels, deux effets très différents

L’URL et le label suffisent à établir la connexion, mais ils ne disent rien de la manière dont Grok doit se servir du serveur. Deux paramètres optionnels comblent ce vide et se complètent : server_description explique au modèle à quoi sert ce serveur, tandis que allowed_tools — ou allowed_tool_names selon le SDK — décide de ce à quoi il a le droit de toucher. Le premier oriente, le second contraint.

server_description : donner du contexte au modèle

Ce paramètre fournit à Grok une description en langage naturel des capacités du serveur. Le modèle s’en sert pour arbitrer : faut-il interroger ce serveur, ou un autre, ou aucun ?

mcp(
    server_url="https://api.example.com/mcp",
    server_label="docs",
    server_description="Serveur de documentation technique. Permet de rechercher des articles, consulter des guides et obtenir des exemples de code pour l'API interne."
)

Sans cette description, Grok ne dispose que des noms et descriptions individuels des outils exposés. Cela fonctionne, mais le modèle raisonne alors sans vue d’ensemble : il voit une collection d’outils sans savoir ce qu’ils forment collectivement. Une bonne description lui apporte trois choses qu’aucun nom d’outil ne peut transmettre : le moment où ce serveur est pertinent plutôt qu’un autre, le type de requêtes qu’il faut y orienter, et — souvent négligé, souvent décisif — ce que le serveur ne fait pas, ce qui évite des appels condamnés d’avance.

Rédigez cette description comme si vous expliquiez le service à un collègue qui arrive sur le projet. Soyez spécifique : « Base de données de documentation technique produit » est utile là où « Documentation » ne l’est pas. Nommez les actions réellement possibles, du type « permet de rechercher, lire et mettre à jour les tickets ». Et si le périmètre est restreint, dites-le franchement : « accès en lecture seule, pas de modification » économisera au modèle une tentative vouée à l’échec.

allowed_tools : refermer le périmètre

Par défaut, connecter Grok à un serveur MCP injecte dans le contexte du modèle tous les outils que ce serveur expose, sans exception. Sur un CRM, cela signifie que la création, la modification et la suppression de contacts sont accessibles au même titre que la recherche.

mcp(server_url="https://api.example.com/mcp",
    server_label="crm")
# Grok voit TOUS les outils : create_contact, update_contact,
# delete_contact, search_contacts, export_data, etc.

Le paramètre allowed_tool_names renverse ce comportement en établissant une liste blanche explicite. Tout ce qui n’y figure pas devient invisible pour le modèle.

mcp(server_url="https://api.example.com/mcp",
    server_label="crm",
    allowed_tool_names=["search_contacts", "get_contact_details"])
# Grok ne voit que search_contacts et get_contact_details

Pourquoi restreindre, même quand tout va bien

La première raison est la sécurité, et elle relève du principe du moindre privilège. Si votre application n’a besoin que de lire, ne laissez pas à portée du modèle les outils de modification ou de suppression. Un prompt injection réussi — une instruction malveillante glissée dans un document que Grok analyse — ne peut pas déclencher un delete_contact qui n’a jamais été exposé. La liste blanche transforme un incident potentiel en non-événement.

# Lecture seule pour un chatbot public
allowed_tool_names=["search_database", "get_record", "format_data"]

La deuxième raison est la performance. Chaque outil exposé occupe de l’espace dans la fenêtre de contexte, puisque son nom, sa description et son schéma de paramètres doivent y tenir. Un serveur MCP qui publie cinquante outils consomme un volume considérable avant même que l’utilisateur ait posé sa question. En descendant à cinq outils réellement utiles, vous récupérez cet espace pour ce qui compte : la conversation elle-même.

La troisième raison est la précision. Plus le catalogue est fourni, plus le modèle hésite entre des outils voisins — et deux outils dont les descriptions se ressemblent produisent des choix instables d’une exécution à l’autre. Un catalogue resserré autour de votre cas d’usage rend la sélection nettement plus fiable.

Faire jouer les deux ensemble

C’est en associant les deux paramètres que le résultat devient vraiment propre, à condition qu’ils racontent la même histoire.

mcp(
    server_url="https://api.example.com/mcp",
    server_label="crm",
    server_description="CRM en lecture seule. Recherche et consultation de contacts et d'entreprises.",
    allowed_tool_names=["search_contacts", "get_contact", "search_companies", "get_company"]
)

Ici, la description annonce un accès en lecture seule et la liste blanche le garantit techniquement. Méfiez-vous de la situation inverse, qui se rencontre plus souvent qu’on ne le croit : une description héritée d’une version antérieure qui promet des capacités d’écriture désormais retirées de la liste blanche. Le modèle tentera l’appel, échouera, et vous passerez un moment à chercher un bug qui n’existe pas. Relisez toujours ces deux paramètres ensemble, jamais séparément.

Points clés à retenir

• server_description aide Grok à comprendre quand utiliser ce serveur MCP
• Sans allowed_tools, tous les outils du serveur sont injectés dans le contexte
• Restreindre les outils renforce la sécurité, la performance et la précision
• Combinez description et restriction pour un contrôle optimal
• Écrivez la description comme une explication en langage naturel des capacités du serveur