Konzeptkarte

MCP-Server-Architektur — Tools, Resources, Prompts

Stand 18. Oktober 2026

Redaktion: Cédric Mary, alleiniger Redakteur und verantwortlich für die Veröffentlichung — 27 Jahre im SAP-Ökosystem. Wie diese Seiten entstehen und wo Automatisierung eingesetzt wird.

Was ist MCP-Server-Architektur?

Die Architekturentscheidung, die einen guten MCP-Server ausmacht, ist, auf welcher der drei Oberflächen — modellgesteuerte Tools, anwendungsgesteuerte Resources oder nutzergesteuerte Prompts — jede Fähigkeit angesiedelt ist; eine falsche Zuordnung frustriert jeden Agenten, der mit dem Server interagiert.

Worum es geht

Ein MCP-Server legt einem aufrufenden Agenten genau drei primäre Oberflächen offen: Tools, Resources und Prompts. Die Architekturentscheidung, die einen guten Server ausmacht, ist, auf welcher Oberfläche jede Funktionalität angesiedelt ist — hier falsch zu liegen, ist der Unterschied zwischen einem Server, den ein LLM autonom steuern kann, und einem, der jeden Agenten frustriert, der ihn berührt.

Tools sind modellgesteuert: Das LLM entscheidet, wann es sie mit welchen Argumenten aufruft. Es sind Funktionen mit Nebenwirkungen oder nicht-trivialer Berechnung — Firmen finden, Firmenprofil abrufen, News durchsuchen im Analytics-Legends-Server. Jedes Tool deklariert eine JSON-Schema-Eingabespezifikation (C224), eine Beschreibung, die das Modell liest, und liefert strukturierten Inhalt zurück. Resources sind anwendungsgesteuert: Die Host-Anwendung (Claude Desktop, Cursor) entscheidet, welche in den Kontext aufgenommen werden, das LLM liest sie, fordert sie aber nicht namentlich an. Es sind URI-adressierbare, schreibgeschützte Dokumente — about.json, agent.json, llms-full.txt in unserem Server. Prompts sind nutzergesteuert: Der Mensch wählt einen Prompt aus einem Slash-Command-Menü, der Server liefert eine vorlagenbasierte Nachrichtensequenz, die das LLM dann ausführt, als hätte der Nutzer sie eingetippt. analyze market position und draft outreach sind unsere beiden.

Warum es zählt

Tools sind modellgesteuert (das LLM entscheidet, wann es sie aufruft); Resources sind anwendungsgesteuert (der Host entscheidet, was angehängt wird); Prompts sind nutzergesteuert (aus einem Slash-Command-Menü gewählt) — drei genuin unterschiedliche Kontrollorte, keine austauschbaren Etiketten.
Logs müssen an stderr gehen, niemals an stdout, weil stdout ausschließlich für JSON-RPC-Frames reserviert ist — ein häufiger Anfängerfehler, der die Leitung korrumpiert.
Tool-Handler sollten nie werfen; { isError: true, content: [...] } zurückzugeben, lässt das LLM auf den Fehler reagieren, statt dass der Transport still bricht.

Kernpunkte

Tools = modellgesteuert — JSON-Schema-typisierte Funktionen, die das LLM aufruft (find_firms, get_firm_profile, search_news in der Plattform-Charter).
Resources = anwendungsgesteuert — URI-adressierbare, schreibgeschützte Dokumente, die der Host wählt (about.json, agent.json, llms-full.txt).
Prompts = nutzergesteuert — Slash-Command-Vorlagen, die der Mensch auslöst (analyze_market_position, draft_outreach).
Operative Invarianten — modulweiter Lazy-JSON-Cache, Logs nur an stderr bei stdio, Tool-Handler werfen nie (geben isError:true zurück).
_attribution bei jeder Antwort — Anti-Training-Ausnahmeregelungs-Durchsetzung gemäß agent.json.
SAPs eigene veröffentlichte MCP-Server (BTP-Administration, Integration Suite Gateway) folgen derselben Drei-Oberflächen-Disziplin; sie ist das richtige mentale Modell für einen Berater, der einen eigenen MCP-Server vor Datasphere, S/4HANA-OData oder einem BDC-Datenprodukt entwirft.
Die MCP-Spezifikation ist zur Revision vom 28.07.2026 fortgeschritten und hat eine clientseitige Elicitation-Fähigkeit sowie ein Extensions-Framework (Tasks, Skills over MCP, MCP Apps) hinzugefügt, die im ursprünglichen Drei-Primitive-Rahmen dieser Architektur nicht berücksichtigt sind — prüfen, welche Revision ein gegebener Server anvisiert.

Begriffe auf dieser Seite

Tool (MCP): Eine modellgesteuerte aufrufbare Oberfläche, deklariert mit einer JSON-Schema-Eingabespezifikation und einer natürlichsprachlichen Beschreibung; das LLM entscheidet während des Reasonings, wann und mit welchen Argumenten es aufgerufen wird.
Resource (MCP): Ein anwendungsgesteuertes, URI-adressierbares, schreibgeschütztes Dokument, das der Host in den Kontext des LLM aufnimmt; das LLM liest es als Hintergrundwissen, fordert aber keine bestimmten Resources namentlich an.
Prompt (MCP): Eine nutzergesteuerte, benannte Vorlage, die der Mensch auslöst (meist per Slash-Command); der Server liefert eine strukturierte Nachrichtensequenz zurück, die das LLM dann ausführt, als hätte der Nutzer sie eingetippt.
Lazy modulweiter Cache: Das MCP-Server-Muster, bei dem schwere JSON-Dateien beim ersten Tool-Aufruf, der sie benötigt, einmal gelesen und für den Rest der Sitzung gecacht werden; hält stdio-Server unter 50 ms p95 pro Aufruf.
Elicitation: Eine clientseitige Fähigkeit, hinzugefügt in der MCP-Revision vom 28.07.2026, die es einem Tool-Handler erlaubt, den Endnutzer mitten im Aufruf über den Client nach fehlenden oder mehrdeutigen Informationen zu fragen, statt den Aufruf fehlschlagen zu lassen und den aufrufenden Agenten um erneutes Nachfragen und einen erneuten Versuch zu bitten.
Data-Access-Control-gescoptes Tool: Ein Tool, dessen Eingabeschema und serverseitige Validierung dieselben Zeilen-/Spalten-Sicherheitsregeln (Data Access Controls in SAP Datasphere oder Berechtigungsobjekte in S/4HANA) durchsetzen, die für den aufrufenden Nutzer in jeder anderen SAP-Oberfläche gelten würden — der richtige Ort, um SAP-Autorisierung für eine über MCP offengelegte Aktion durchzusetzen.

Quellen

Vollständige Karte für Mitglieder. Was die vollständige Karte ergänzt: den vollständigen Entscheidungsrahmen · den Vergleich SAP · Snowflake · Databricks · Fabric · die häufigen Fallstricke und ihre Behebung · die Kurzreferenz · die Architekturschemata · die Codeblöcke · die zitierfähigen Kennzahlen.

In der App öffnen →

Offene SAP-Projekte

Aktuelle SAP-Analytics-Projekte und Stellen im DACH-Raum: SAP-Analytics-Projekte im DACH-Raum.