Tools, Resources et Prompts dans MCP

Les trois capacités d’un serveur MCP

Le protocole MCP définit trois types de capacités qu’un serveur peut exposer à ses clients. Chacune répond à un besoin différent et s’utilise dans des contextes distincts.

Tools : les fonctions exécutables

Les Tools sont la capacité la plus utilisée de MCP. Un tool est une fonction que le modèle peut décider d’appeler pour accomplir une action ou récupérer une information.

Chaque tool est défini par :

• Un nom unique et descriptif (ex: create_issue, get_weather)
• Une description textuelle que le modèle utilise pour décider quand l’appeler
• Un schéma JSON des paramètres d’entrée (types, descriptions, contraintes)
• Un format de retour (généralement 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})"

La description et le typing sont cruciaux. Le modèle ne voit que ces informations textuelles pour décider quand et comment appeler votre tool. Une description vague ou des paramètres mal typés conduisent à des appels incorrects.

Bonnes pratiques pour les tools

• Nommez clairement : book_restaurant plutôt que process_request
• Décrivez précisément ce que le tool fait ET ce qu’il retourne
• Typez tous les paramètres avec des annotations Python
• Utilisez des docstrings détaillées avec Args et Returns
• Préférez des valeurs lisibles en retour ("John Smith" plutôt qu’un UUID)

Resources : les données consultables

Les Resources exposent des données que le client peut lire sans effet de bord. Contrairement aux tools qui font quelque chose, les resources contiennent quelque chose.

Exemples de resources :

• Le contenu d’un fichier de configuration
• Les données d’une base de connaissances
• La documentation d’une API
• L’état actuel d’un système

@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"
    })

Les resources sont identifiées par des URI (comme config://database ou file:///path/to/doc). Le client peut les lister et les lire à la demande.

En pratique, les resources sont moins utilisées que les tools, car la plupart des cas d’usage peuvent être couverts par un tool qui retourne des données. Mais elles sont utiles quand vous voulez exposer des données statiques ou semi-statiques sans logique d’exécution.

Prompts : les templates réutilisables

Les Prompts MCP sont des templates de prompts paramétrables exposés par le serveur. Ils permettent de partager des instructions optimisées pour des tâches spécifiques.

@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}
```"""

Les prompts sont particulièrement utiles dans un contexte d’équipe : un développeur senior peut créer des prompts de revue de code, de debugging ou d’architecture, et les partager via un serveur MCP à toute l’équipe.

La négociation des capabilities

Quand un client se connecte à un serveur MCP, il y a une phase de négociation :

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. Un serveur peut exposer des capabilities différentes selon l’utilisateur connecté ou le contexte.

Combien de tools par serveur ?

Une question pratique importante : combien de tools devez-vous exposer par serveur MCP ?

Recommandation : gardez vos serveurs focalisés. Un serveur avec 3 à 10 tools bien définis sera plus efficace qu’un serveur avec 50 tools génériques. Quand le modèle a trop de tools disponibles, il peut se perdre dans le choix et appeler le mauvais outil.

Si vous avez beaucoup de fonctionnalités, créez plusieurs serveurs MCP spécialisés. Par exemple :

• Un serveur pour les opérations Git
• Un serveur pour la gestion de projet
• Un serveur pour le monitoring

Le client peut se connecter à plusieurs serveurs simultanément et n’activer que ceux nécessaires à la tâche en cours.

Workflow vs tools granulaires

Plutôt que d’exposer des tools très granulaires (lister les restaurants, vérifier la disponibilité, réserver), envisagez de créer des tools de workflow qui encapsulent une séquence complète (book_restaurant). Cela réduit le nombre d’appels nécessaires et les risques d’erreur.

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