Aller au contenu
Cercle IA Tech · MCP Un site du réseau Cercle IA Tech

Guide

Outils, ressources et prompts MCP : que choisir ?

Tools contrôlés par le modèle, resources par l'application, prompts par l'utilisateur : comment répartir ce qu'expose votre serveur MCP.

Mis à jour le

Un serveur MCP (Model Context Protocol) peut exposer trois choses, et la différence tient à qui décide de s'en servir : les outils sont choisis par le modèle, les ressources par l'application, les prompts par l'utilisateur. Bien répartir ce que vous exposez entre les trois rend votre serveur plus sûr et plus simple à utiliser.

Le tableau de référence

D'après la documentation officielle :

Primitive Ce que c'est Exemples Qui la contrôle
Outils (tools) Des fonctions que le modèle appelle quand la demande s'y prête. Ils peuvent écrire en base, appeler des API externes, modifier des fichiers Rechercher un vol, envoyer un message, créer un événement d'agenda Le modèle
Ressources (resources) Des sources de données passives, en lecture, qui apportent du contexte Lire des documents, consulter une base de connaissances, lire un agenda L'application
Prompts Des modèles d'instructions prêts à l'emploi qui orientent le modèle vers certains outils et ressources Préparer un voyage, résumer mes réunions, rédiger un courriel L'utilisateur

Une API (interface de programmation) n'est ici qu'un exemple de ce qu'un outil peut appeler.

Les outils

Un outil est défini par un nom, une description, un inputSchema (schéma JSON des paramètres) et, en option, un titre lisible, un outputSchema pour les résultats structurés et des annotations. Le client les découvre avec tools/list et les exécute avec tools/call.

Règles de la spécification à connaître :

  • Nom : entre 1 et 128 caractères, sensible à la casse, uniquement lettres ASCII (sans accents), chiffres, _, - et ., unique dans le serveur. Exemples valides : getUser, DATA_EXPORT_v2, admin.tools.list.
  • Ordre : les serveurs devraient renvoyer les outils toujours dans le même ordre, pour faciliter la mise en cache.
  • Erreurs : un outil inconnu ou une requête mal formée donne une erreur de protocole ; une panne d'API, une date invalide ou une règle métier non respectée se renvoie dans le résultat avec isError: true, pour que le modèle puisse corriger et réessayer.
  • Résultats : texte, image, audio, lien vers une ressource ou ressource intégrée, plus éventuellement un structuredContent conforme à l'outputSchema.
  • Annotations : elles décrivent le comportement de l'outil, mais le client doit les considérer comme non fiables tant qu'elles ne viennent pas d'un serveur de confiance.

Et le principe de sécurité : la spécification recommande qu'il y ait toujours un humain capable de refuser l'appel d'un outil.

Les ressources

Une ressource a une URI unique (son adresse, par exemple file:///chemin/document.md) et un type MIME (le format du contenu). Deux formes :

  • Ressource directe : une URI fixe, comme calendar://events/2024.
  • Modèle de ressource : une URI à paramètres, comme travel://activities/{city}/{category}, que l'application complète. Les paramètres peuvent être proposés en autocomplétion.

Méthodes : resources/list, resources/templates/list, resources/read, et subscriptions/listen pour être prévenu des changements. L'application décide ce qu'elle fait du contenu : en garder une partie, le chercher par similarité, ou tout passer au modèle.

Les prompts

Un prompt est un modèle paramétré que l'utilisateur déclenche explicitement, jamais automatiquement. Méthodes : prompts/list et prompts/get. Les applications les présentent souvent en commandes « / » : dans Claude Code, un prompt apparaît sous la forme /serveur:prompt (MCP).

Comment répartir : une méthode simple

Prenons un exemple illustratif : un serveur pour le logiciel de gestion commerciale d'une PME.

  1. Ce qui modifie quelque chose (créer un devis, changer un statut, envoyer un message) : un outil, avec une description précise et, côté client, une confirmation.
  2. Ce qui se lit et sert de contexte (fiche d'un client, catalogue, conditions générales) : une ressource, ou un modèle de ressource si l'adresse dépend d'un identifiant.
  3. Une façon récurrente de travailler (« préparer le point commercial du lundi ») : un prompt qui oriente le modèle vers les bons outils et ressources.
  4. Une recherche que le modèle doit pouvoir lancer seul : un outil en lecture seule. Une ressource n'est pas appelée par le modèle de lui-même ; c'est l'application qui la fournit.

Un point de compatibilité

Tous les clients ne prennent pas en charge les trois primitives. Par exemple, la documentation du connecteur MCP de l'API Claude indique que seuls les appels d'outils y sont pris en charge (voir le connecteur MCP de l'API Claude). Si une fonction doit marcher partout, un outil reste le choix le plus portable.

Pour la mise en œuvre, voir créer un serveur MCP en Python ou en TypeScript.

Questions fréquentes

Quelle différence entre un outil et une ressource MCP ?

Un outil est une fonction que le modèle décide d'appeler et qui peut agir (écrire, envoyer, modifier). Une ressource est une donnée en lecture, identifiée par une URI, que l'application choisit de fournir comme contexte.

Combien de caractères pour le nom d'un outil MCP ?

La spécification recommande entre 1 et 128 caractères, avec seulement des lettres ASCII, des chiffres, le tiret bas, le tiret et le point.

Sources

Pages consultées pour écrire cet article :

  1. https://modelcontextprotocol.io/docs/2026-07-28/learn/server-concepts.md
  2. https://modelcontextprotocol.io/specification/2026-07-28/server/tools.md

À lire aussi