AI & Analytics Legends La plateforme de connaissance SAP Analytics
Fiche concept

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

Architecture d'un serveur MCP — outils, ressources, prompts — illustration de section Analytics Legends pour la base de connaissances SAP Analytics (concepts, études, Academy)

À jour au 2026-10-06

Qu'est-ce que Architecture d'un serveur MCP ?

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.
  • Les propres serveurs MCP publiés par SAP (administration BTP, Integration Suite Gateway) suivent cette même discipline à trois surfaces ; c'est le bon modèle mental pour un consultant qui conçoit un serveur MCP sur mesure devant Datasphere, l'OData S/4HANA ou un data product BDC.
  • La spécification MCP est passée à la révision du 28/07/2026, ajoutant une capacité d'elicitation côté client et un cadre d'extensions (Tasks, Skills over MCP, MCP Apps) non pris en compte dans le cadrage initial à trois primitives de cette architecture — vérifier quelle révision cible un serveur donné.

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.
Elicitation
Une capacité côté client ajoutée dans la révision MCP du 28/07/2026, permettant à un handler d'outil de demander à l'utilisateur final une information manquante ou ambiguë en cours d'appel, via le client, plutôt que d'échouer l'appel et de demander à l'agent appelant de re-solliciter et de réessayer.
Outil scopé par Data Access Control
Un outil dont le schéma d'entrée et la validation côté serveur appliquent les mêmes règles de sécurité ligne/colonne (Data Access Controls dans SAP Datasphere, ou objets d'autorisation dans S/4HANA) qui s'appliqueraient à l'utilisateur appelant dans toute autre interface SAP — l'endroit correct pour faire respecter l'autorisation SAP pour une action exposée via MCP.

Sources

  1. MCP specification — Server features (tools, resources, prompts)
  2. Anthropic MCP TypeScript SDK
  3. SAP Generative AI — official product page
  4. Model Context Protocol — Server features, specification revision 2026-07-28
  5. Model Context Protocol — Extensions overview (Tasks, Skills over MCP, MCP Apps)
  6. SAP Help Portal — Connect to MCP server for SAP BTP administration
  7. SAP Community — MCP Gateway in SAP Integration Suite: your APIs ready for the age of agents
  8. SAP Community — Principal propagation for MCP servers: SAP Integration Suite to SAP S/4HANA
  9. GitHub — modelcontextprotocol/specification (authoritative schema source)
  10. SAP Community — Public release of the MCP server for SAP BTP administration
  11. SAP Community — Build a pro-code A2A agent for SAP S/4HANA Cloud with the CAP Agent Plugin
  12. Model Context Protocol — Understanding MCP servers (tools, resources and prompts as server features)
  13. Model Context Protocol — Architecture overview (hosts, clients, servers and layers)
  14. Model Context Protocol — Client Best Practices (progressive tool discovery against loading every definition upfront)
  15. Google Cloud Blog — Empower your agents with the Google Cloud CLI remote MCP server (two-tool server, caller identity, audit logging, 1 Oct 2026)
  16. SiliconANGLE — Equals Money limits MCP server access to data, not payments (read-only MCP server design, 29 Sep 2026)
  17. SiliconANGLE — Komprise combats ‘MCP bloat’ with a universal interface for AI agents to access enterprise data (metadata-first access, 29 Sep 2026)

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 · les chiffres à citer.

Ouvrir dans l'application →