Ressources, prompts ou outils MCP — quand chaque surface gagne

De quoi il s'agit

L'erreur de conception la plus fréquente lorsqu'on construit un serveur Model Context Protocol consiste à forcer chaque capacité à devenir un outil. La spécification expose délibérément trois surfaces distinctes — outils, ressources et prompts — précisément pour que trois parties différentes, le modèle de langage, l'application hôte et l'utilisateur humain, contrôlent chacune ce qu'elle est le mieux placée pour contrôler. Réduire les trois à « il suffit d'en faire un outil » est pratique au départ, mais cela consomme des jetons, ralentit le temps de réponse et, surtout, dégrade la capacité du modèle à choisir le bon outil tout court, parce que chaque ressource ou prompt mal placé dans la liste des outils est une option de plus que le modèle doit lire et écarter à chaque appel.

Pourquoi c'est important

• La mauvaise surface brûle des tokens, ralentit les réponses et dégrade la précision de sélection, même avec des handlers corrects.
• Les ressources (config, manifestes, glossaires) sont attachées par l'hôte au démarrage de session, peu coûteuses à lire, sans appel LLM nécessaire.
• Les prompts sont des templates déterministes déclenchés par l'utilisateur (ex. « analyze market position ») — pas des fonctions décidées par le modèle.

Points clés

• Outil — action pilotée modèle (search, fetch, write) ; le LLM décide du moment et des arguments.
• Ressource — contexte piloté application (config, manifeste, glossaire) ; l'hôte attache à la session, le LLM lit passivement.
• Prompt — template piloté utilisateur (slash command) ; l'humain déclenche, le serveur renvoie une instruction multi-tour.
• Règle de décision — qui décide quand ? Modèle → outil. Application → ressource. Humain → prompt.
• Coût de mauvaise classification — tokens brûlés, latence en hausse, précision en baisse ; l'erreur n°1 en production.
• Elicitation (spec 2026-07-28) — un quatrième foyer de contrôle distinct : le SERVEUR décide en cours de tâche qu'il lui manque une information, mais le CLIENT décide comment et s'il la recueille auprès de l'humain ; ni ressource, ni outil, ni prompt.
• Skills over MCP (extension communautaire, spec 2026-07-28) — des guides structurés et découvrables par l'humain, posés sur le triptyque existant ; proche du prompt quant à qui l'invoque, plus riche en structure qu'une ressource ou qu'un prompt.

Termes employés sur cette page

Model-controlled surface

Une surface de serveur MCP (les tools) où le LLM décide, au moment du raisonnement, s'il faut invoquer l'appel et comment, sur la base de la description et de la spécification d'entrée en JSON Schema.

Application-controlled surface

Une surface de serveur MCP (les resources) où l'application hôte (Claude Desktop, Cursor, Claude Code) décide quels documents adressables par URI attacher à la fenêtre de contexte du LLM.

User-controlled surface

Une surface de serveur MCP (les prompts) où l'utilisateur humain déclenche explicitement un modèle nommé — généralement via un menu de commandes slash — et le serveur renvoie une séquence de messages multi-tours structurée.

Everything-as-tool anti-pattern

L'échec de conception le plus courant des serveurs MCP : regrouper documents de configuration, notes de méthodologie et workflows modélisés dans des tools, ce qui gonfle l'espace de sélection d'outils et dégrade la précision du LLM.

Elicitation

Une fonctionnalité côté client formalisée dans la spécification MCP (2026-07-28) : le serveur déclenche, en cours de tâche, une demande d'information supplémentaire à l'utilisateur ; c'est le client — ni le modèle, ni le serveur seul — qui décide comment et s'il expose cette demande. Distincte des trois surfaces d'origine car le déclencheur est côté serveur mais la satisfaction passe par le client.

Skills over MCP

Une extension optionnelle de MCP (livrable d'un groupe de travail communautaire, spec 2026-07-28) exposant via le protocole des instructions riches, structurées et rédigées par des humains pour des workflows d'agents — une couche de guides éditorialisés, découvrable et déclenchée par l'humain comme un prompt, mais dotée de plus de structure interne qu'un gabarit.

Completions utility

Un utilitaire de serveur MCP (spec 2026-07-28, server/utilities/completion) qui permet à un serveur de suggérer des valeurs d'argument valides pour un prompt ou un modèle de ressource pendant que l'utilisateur tape — une facilité pilotée par l'application, pas une décision du modèle.

Sources

1. MCP specification — Architecture overview
2. Anthropic MCP examples repository
3. Model Context Protocol — Specification index, revision 2026-07-28
4. Model Context Protocol — Server Features: Tools (spec 2026-07-28)
5. Model Context Protocol — Server Features: Resources (spec 2026-07-28)
6. Model Context Protocol — Server Features: Prompts (spec 2026-07-28)
7. Model Context Protocol — Extensions overview (spec 2026-07-28)
8. Model Context Protocol — Skills extension overview
9. Model Context Protocol — MCP Apps extension overview
10. Model Context Protocol — Understanding MCP clients (elicitation, roots and sampling as client features)
11. Model Context Protocol — Client Best Practices (progressive discovery and context cost of tool definitions)
12. Claude Platform Docs — Tool search tool (native search over large tool catalogues)
13. CIO — If AI makes the decision, who owns the consequence? (decision rights and authority drift, 28 Sep 2026)
14. SiliconANGLE — Komprise combats ‘MCP bloat’ with a universal interface for AI agents to access enterprise data (metadata-first pattern, 29 Sep 2026)