Konzeptkarte

MCP-Server-Architektur — Tools, Resources, Prompts

Stand 2026-07-23

Redaktion: Cédric-Olivier Mâry, 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 — Tools, Resources, Prompts?

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.
„MCP-Server-Architektur — Tools, Resources, Prompts" ist erst dann beherrscht, wenn es eine benannte Kaufentscheidung verändert.
Beginnen Sie mit dem semantischen Vertrag und dem Steuerungsmodell, bevor Sie das Tool demonstrieren.
Nutzen Sie aktuelle SAP-, Analysten-, Studien-, KG- und News-Signale als Beleg, nicht als Dekoration.
Trennen Sie verifizierte Fakten von richtungsweisenden Trends und modellierten Annahmen.
Definieren Sie Verantwortlichen, Kennzahl, Schwellenwert, Support-Pfad und Rollback, bevor Sie skalieren.

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.
Entscheidungsverantwortlicher: Die verantwortliche Person, die den Kompromiss akzeptiert und die nächste Maßnahme finanziert.
Semantischer Vertrag: Die gemeinsame Definition von Geschäftsbegriffen, Kennzahlen, Entitäten und Zugriffsregeln, die von Tools und Teams verwendet wird.
Control Plane: Die Schicht, die Policy, Zugriff, Lineage, Monitoring und Eskalation über das Betriebsmodell hinweg durchsetzt.
Evidenzgrad: Eine Kennzeichnung, die verifizierte Fakten, Richtungssignale, modellierte Annahmen und Feldbeobachtungen unterscheidet.

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.

In der App öffnen →