Tools, Resources et Prompts dans MCP

Trois capacités, trois intentions

Un serveur MCP peut exposer trois types de capacités à ses clients. Elles ne sont pas interchangeables : chacune répond à un besoin distinct, et confondre les trois conduit à des serveurs difficiles à utiliser pour le modèle. Cette leçon les examine une à une, avant d’aborder la question qui décide de la qualité d’un serveur : combien de tools, et à quelle granularité.

Tools : les fonctions exécutables

Les Tools sont la capacité la plus utilisée du protocole. Un tool est une fonction que le modèle peut décider d’appeler pour accomplir une action ou récupérer une information. Sa définition repose sur quatre éléments : un nom unique et descriptif (create_issue, get_weather), une description textuelle qui indique au modèle quand l’appeler, un schéma JSON des paramètres d’entrée avec leurs types et contraintes, et un format de retour — le plus souvent du texte ou du JSON.

from mcp.server.fastmcp import FastMCP

app = FastMCP("Mon Serveur")

@app.tool()
def get_weather(latitude: float, longitude: float) -> str:
    """Récupère la météo actuelle pour les coordonnées données.

    Args:
        latitude: Latitude en degrés décimaux (-90 à 90)
        longitude: Longitude en degrés décimaux (-180 à 180)

    Returns:
        Description textuelle de la météo actuelle
    """
    # Logique d'appel API météo
    return f"Ensoleillé, 22°C à ({latitude}, {longitude})"

Ne sous-estimez pas la description et le typage : le modèle ne voit rien d’autre. Il n’a pas accès à votre code, ne devine pas vos intentions, et ne peut pas tester un appel pour voir ce qui se passe. Une description vague ou des paramètres mal typés produisent mécaniquement des appels incorrects.

Quelques réflexes rendent vos tools nettement plus fiables. Nommez-les par ce qu’ils font — book_restaurant dit tout, process_request ne dit rien — et décrivez aussi bien l’action que le contenu du retour, car le modèle doit anticiper ce qu’il récupérera. Annotez systématiquement les paramètres en Python et rédigez des docstrings structurées avec Args et Returns : ce sont elles qui alimentent le schéma vu par le modèle. Enfin, renvoyez des valeurs lisibles plutôt que des identifiants opaques ; un tool qui répond "John Smith" permet au modèle de composer une phrase, un tool qui répond un UUID le force à deviner.

Resources : les données consultables

Les Resources exposent des données que le client peut lire sans effet de bord. La nuance avec les tools tient en un verbe : un tool fait quelque chose, une resource contient quelque chose. Le contenu d’un fichier de configuration, une base de connaissances, la documentation d’une API ou l’état courant d’un système sont autant de resources naturelles.

@app.resource("config://database")
def get_db_config() -> str:
    """Configuration actuelle de la base de données."""
    return json.dumps({
        "host": "localhost",
        "port": 5432,
        "database": "production"
    })

Chaque resource est identifiée par un URI — config://database, file:///path/to/doc — que le client peut lister puis lire à la demande. Dans la pratique, elles restent moins employées que les tools, puisqu’un simple tool renvoyant des données couvre la plupart des besoins. Elles gardent leur intérêt quand vous voulez publier des données statiques ou semi-statiques sans logique d’exécution derrière.

Prompts : les templates réutilisables

Les Prompts MCP sont des templates paramétrables que le serveur met à disposition. Ils servent à partager des instructions déjà éprouvées pour une tâche donnée, au lieu de laisser chacun réinventer sa formulation.

@app.prompt()
def code_review(language: str, code: str) -> str:
    """Génère un prompt de revue de code pour le langage donné."""
    return f"""Vous êtes un expert en {language}.
Analysez le code suivant et identifiez :
1. Les bugs potentiels
2. Les problèmes de performance
3. Les améliorations de lisibilité

Code à analyser :
```{language}
{code}
```"""

L’usage prend tout son sens en équipe. Un développeur senior encode ses prompts de revue de code, de debugging ou d’analyse d’architecture dans un serveur MCP, et l’ensemble de l’équipe y accède depuis son propre client, avec la même qualité d’instruction.

La négociation des capabilities

Quand un client se connecte à un serveur, une phase de négociation précède tout usage :

1. Le client demande les capabilities du serveur
2. Le serveur répond avec la liste de ses tools, resources et prompts
3. Le client présente ces capabilities au modèle de langage
4. Le modèle utilise les descriptions pour décider quoi appeler

Cette négociation est dynamique, et c’est une propriété exploitable : un même serveur peut annoncer des capabilities différentes selon l’utilisateur connecté ou le contexte d’appel — un compte administrateur voyant des tools qu’un compte lecture seule ne verra jamais.

Combien de tools par serveur ?

La question paraît anodine, elle conditionne pourtant le taux d’erreur de votre agent. Gardez vos serveurs focalisés : trois à dix tools bien définis fonctionnent mieux que cinquante tools génériques. Passé un certain volume, le modèle se disperse dans le choix et finit par appeler le mauvais outil, ou par empiler des appels inutiles.

Si votre périmètre fonctionnel est large, découpez-le en plusieurs serveurs spécialisés — un pour les opérations Git, un pour la gestion de projet, un pour le monitoring. Le client sait se connecter à plusieurs serveurs simultanément et n’activer que ceux qu’exige la tâche en cours, ce qui revient à charger le contexte utile plutôt que le catalogue entier.

Un dernier arbitrage mérite votre attention : la granularité. Exposer trois tools pour lister les restaurants, vérifier les disponibilités puis réserver oblige le modèle à orchestrer une séquence, avec un risque d’erreur à chaque étape. Un tool de workflow unique — book_restaurant — encapsule la séquence complète, réduit le nombre d’allers-retours et déplace la logique métier là où elle est testable : dans votre code.

Points clés à retenir

• Tools = actions exécutables (90 % des usages), requièrent description et typing précis
• Resources = données consultables via URI, sans effet de bord
• Prompts = templates réutilisables, utiles en équipe
• Gardez vos serveurs focalisés (3-10 tools maximum)
• Préférez les tools de workflow aux tools trop granulaires
• La qualité des descriptions détermine l’efficacité du modèle