Konzeptkarte

MCP Resources vs. Prompts vs. Tools — wann welche Oberfläche die richtige ist

Stand 2026-07-24T14:00:00Z

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 Resources vs. Prompts vs. Tools — wann welche Oberfläche die richtige ist?

Der häufigste Designfehler bei MCP besteht darin, jede Fähigkeit in ein Tool zu zwingen — die richtige Oberfläche ergibt sich daraus, wer wann entscheidet: Das Modell wählt Tools, die Host-Anwendung hängt Resources an, der Mensch löst Prompts aus.

Worum es geht

Der häufigste Designfehler beim Aufbau eines Model-Context-Protocol-Servers besteht darin, jede Fähigkeit in ein Tool zu zwingen. Die Spezifikation stellt bewusst drei unterschiedliche Oberflächen bereit — Tools, Resources und Prompts —, genau damit drei verschiedene Parteien, das Sprachmodell, die Host-Anwendung und der menschliche Nutzer, jeweils das kontrollieren, wofür sie am besten geeignet sind. Alle drei zu „mach einfach ein Tool daraus" zusammenzufassen ist zu Beginn bequem, kostet aber Tokens, verlangsamt die Antwortzeit und beeinträchtigt vor allem die Fähigkeit des Modells, überhaupt das richtige Tool auszuwählen — denn jede fehlplatzierte Resource oder jeder fehlplatzierte Prompt in der Tool-Liste ist eine weitere Option, die das Modell bei jedem einzelnen Aufruf lesen und verwerfen muss.

Warum es zählt

Die falsche Oberfläche kostet Tokens, verlangsamt Antworten und verschlechtert die Auswahl-Genauigkeit — selbst wenn jeder Handler korrekt implementiert ist.
Resources (Konfiguration, Manifeste, Glossare) werden vom Host bei Sitzungsbeginn angehängt, sind günstig zu lesen und benötigen keinen LLM-Aufruf.
Prompts sind nutzergesteuerte, deterministische Vorlagen (z. B. „Marktposition analysieren") — keine vom Modell selbst entschiedenen Funktionen.

Kernpunkte

Tool — modellgesteuerte Aktion (Suche, Abruf, Schreiben); das LLM entscheidet, wann und mit welchen Argumenten.
Resource — anwendungsgesteuerter Kontext (Konfiguration, Manifest, Glossar); der Host hängt ihn bei Sitzungsbeginn an, das LLM liest ihn passiv.
Prompt — nutzergesteuerte Vorlage (Slash-Command); der Mensch löst aus, der Server liefert eine Mehrschritt-Anweisung zurück.
Entscheidungsregel — wer entscheidet, wann? Modell → Tool. Anwendung → Resource. Mensch → Prompt.
Kosten einer Fehlklassifizierung — Tokens werden verbrannt, die Latenz steigt, die Auswahl-Genauigkeit sinkt; der Produktionsfehler Nr. 1 bei MCP-Servern.
MCP Resources vs. Prompts vs. Tools — wann welche Oberfläche die richtige ist, ist erst dann beherrscht, wenn es eine konkret benannte Kaufentscheidung verändert.
Zunächst den semantischen Vertrag und das Kontrollmodell klären, bevor das Tool demonstriert wird.
Aktuelle SAP-, Analysten-, Studien-, KG- und News-Signale als Beleg nutzen, nicht als Dekoration.
Verifizierte Fakten von richtungsweisenden Trends und modellierten Annahmen trennen.
Owner, Metrik, Schwellenwert, Support-Pfad und Rollback festlegen, bevor skaliert wird.

Begriffe auf dieser Seite

Modellgesteuerte Oberfläche: Eine MCP-Server-Oberfläche (Tools), bei der das LLM zur Reasoning-Zeit anhand der Beschreibung und der JSON-Schema-Eingabespezifikation entscheidet, ob und wie der Aufruf erfolgt.
Anwendungsgesteuerte Oberfläche: Eine MCP-Server-Oberfläche (Resources), bei der die Host-Anwendung (Claude Desktop, Cursor, Claude Code) entscheidet, welche über URI adressierbaren Dokumente sie an das Kontextfenster des LLM anhängt.
Nutzergesteuerte Oberfläche: Eine MCP-Server-Oberfläche (Prompts), bei der der menschliche Nutzer explizit eine benannte Vorlage auslöst — meist über ein Slash-Command-Menü — und der Server eine strukturierte Mehrschritt-Nachrichtenfolge zurückgibt.
Alles-als-Tool-Anti-Pattern: Der häufigste Design-Fehler bei MCP-Servern: Konfigurationsdokumente, Methodik-Notizen und schablonisierte Workflows in Tools zu packen, was den Tool-Auswahlraum aufbläht und die LLM-Genauigkeit verschlechtert.
Entscheidungsverantwortlicher: Die verantwortliche Person, die den Trade-off akzeptiert und die nächste Maßnahme finanziert.
Semantischer Vertrag: Die gemeinsame Definition von Geschäftsbegriffen, Metriken, Entitäten und Zugriffsregeln, die von Tools und Teams verwendet wird.
Kontrollebene: Die Ebene, die Policies, Zugriff, Lineage, Monitoring und Eskalation im gesamten Betriebsmodell durchsetzt.
Evidenzgrad: Eine Kennzeichnung, die verifizierte Fakten, richtungsweisende Signale, 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 · die zitierfähigen Kennzahlen.

In der App öffnen →