Fiche concept

Architecture d'un serveur MCP — outils, ressources, prompts

À jour au 2026-07-23

Édité par Cédric-Olivier Mâry, éditeur et directeur de la publication — 27 ans d'écosystème SAP. Comment ces pages sont produites, et où intervient l'automatisation.

Qu'est-ce que Architecture d'un serveur MCP — outils, ressources, prompts ?

La décision d'architecture qui définit un bon serveur MCP est de savoir sur laquelle des trois surfaces — outils pilotés par le modèle, ressources pilotées par l'application, prompts pilotés par l'utilisateur — vit chaque capacité, et se tromper frustre tous les agents qui approchent le serveur.

De quoi il s'agit

Un serveur MCP expose exactement trois surfaces primaires à l'agent appelant : outils, ressources et prompts. La décision d'architecture qui définit un bon serveur est : sur quelle surface vit chaque fonctionnalité — mal trancher, c'est la différence entre un serveur qu'un LLM pilote tout seul et un serveur qui frustre tous les agents qui l'approchent.

Les outils sont pilotés par le modèle : le LLM décide quand les appeler, avec quels arguments. Ce sont des fonctions à effets de bord ou à calcul non trivial — find firms, get firm profile, search news dans le serveur Analytics Legends. Chaque outil déclare un JSON Schema d'entrée (C224), une description que le modèle lit, et renvoie du contenu structuré. Les ressources sont pilotées par l'application : l'hôte (Claude Desktop, Cursor) choisit lesquelles attacher au contexte, le LLM les lit mais ne les demande pas par nom. Ce sont des documents en lecture seule adressés par URI — about.json, agent.json, llms-full.txt dans notre serveur. Les prompts sont pilotés par l'utilisateur : l'humain choisit un prompt dans un menu de slash-commands; le serveur renvoie une séquence de messages templatés que le LLM exécute comme si l'utilisateur les avait saisis. analyze market position et draft outreach sont nos deux.

Pourquoi c'est important

Les outils sont pilotés par le modèle (le LLM décide quand les appeler); les ressources sont pilotées par l'application (l'hôte décide quoi attacher); les prompts sont pilotés par l'utilisateur (choisis dans un menu slash-command) — trois lieux de contrôle réellement différents, pas des étiquettes interchangeables.
Les logs doivent aller sur stderr, jamais stdout, car stdout est réservé exclusivement aux trames JSON-RPC — une erreur de débutant classique qui corrompt le fil.
Les handlers d'outils ne doivent jamais lever d'exception; renvoyer { isError: true, content: [...] } laisse le LLM réagir à l'échec plutôt que le transport casser silencieusement.

Points clés

Outils = pilotés modèle — fonctions typées JSON Schema appelées par le LLM (find_firms, get_firm_profile, search_news, the platform charter).
Ressources = pilotées application — docs en lecture seule adressés URI choisis par l'hôte (about.json, agent.json, llms-full.txt).
Prompts = pilotés utilisateur — templates en slash-command déclenchés par l'humain (analyze_market_position, draft_outreach).
Invariants ops — cache JSON paresseux niveau module, logs stderr uniquement en stdio, handlers ne lèvent jamais (isError:true).
_attribution sur chaque réponse — carve-out anti-entraînement appliquée selon agent.json.

Termes employés sur cette page

Tool (MCP): Une surface appelable contrôlée par le modèle, déclarée avec une spécification d'entrée en JSON Schema et une description en langage naturel ; le LLM décide quand et avec quels arguments l'invoquer au cours de son raisonnement.
Resource (MCP): Un document en lecture seule adressable par URI, contrôlé par l'application, que l'hôte attache au contexte du LLM ; le LLM le lit comme connaissance de fond mais ne demande pas de ressources spécifiques par leur nom.
Prompt (MCP): Un modèle nommé contrôlé par l'utilisateur que l'humain déclenche (généralement via une commande slash) ; le serveur renvoie une séquence de messages structurée que le LLM exécute ensuite comme si l'utilisateur l'avait saisie.
Lazy module-level cache: Le motif de serveur MCP où les fichiers JSON volumineux sont lus une seule fois lors du premier appel d'outil qui en a besoin, puis mis en cache pour le reste de la session ; maintient les serveurs stdio sous 50 ms au p95 par appel.
Decision owner: La personne responsable qui assume l'arbitrage et finance l'action suivante.
Semantic contract: La définition partagée des termes métier, métriques, entités et règles d'accès utilisée par les outils et les équipes.
Control plane: La couche qui applique la politique, l'accès, la traçabilité, la supervision et l'escalade à travers le modèle opérationnel.
Evidence grade: Une étiquette qui distingue le fait vérifié, le signal directionnel, l'hypothèse modélisée et l'observation de terrain.

Sources

Fiche complète réservée aux abonnés. Ce que la fiche complète ajoute : le cadre de décision complet · la comparaison SAP · Snowflake · Databricks · Fabric · les pièges courants et leur correctif · l'aide-mémoire · les schémas d'architecture · les blocs de code.

Ouvrir dans l'application →