MCP Tools vs Resources vs Prompts: die richtige Wahl

Ein MCP Tool beschreibt eine Operation, deren Aufruf das Modell mit typisierten Argumenten vorschlagen kann, etwa eine Bestellung suchen, einen Tarif berechnen oder einen Entwurf erstellen. Eine Resource liefert Kontext, den die Host-Anwendung über eine URI lesen und in die Unterhaltung aufnehmen kann: Datei, Schema, Nachschlagewerk oder Snapshot. Ein Prompt ist eine parametrisierte Nachrichtenvorlage, die der Nutzer bewusst für einen wiederholbaren Workflow auswählt. Das sind drei unterschiedliche Control Planes und nicht drei Varianten derselben Funktion.

Wählen Sie das Primitive danach, wer den nächsten Schritt steuert. Für eine externe Operation oder einen autoritativen Lookup mit Runtime-Parametern eignet sich ein Tool. Wenn Nutzer oder Anwendung Material als Kontext auswählen und lesen sollen, ist eine Resource passend. Für eine sichtbare Startaktion mit Argumenten und vorbereiteten Messages eignet sich ein Prompt. Ein Server kann alle drei kombinieren: Prompt strukturiert die Aufgabe, Resource liefert Policy-Kontext, Tool führt den erlaubten Lookup aus. Prompt oder Resource dürfen keinen Side Effect verstecken, und ein Tool sollte nicht nur statischen Text transportieren.

• Ändert oder berechnet Zustand aus Runtime-Input → Tool.
• Liefert adressierbaren Inhalt als Kontext → Resource.
• Startet eine vom Nutzer gewählte wiederverwendbare Interaktion → Prompt.
• Benötigt zwei Rollen → Primitives mit getrennten Verträgen kombinieren.

Die Spezifikation beschreibt Tools als model-controlled: Ein Client kann sie dem Modell anbieten und es einen Aufruf wählen lassen. Bei sensiblen Operationen sollte der Client Inputs anzeigen und eine Ablehnung ermöglichen. Resources sind application-driven; der Host entscheidet über Picker, Suche, automatische Einbindung oder andere Oberflächen. Prompts sind user-controlled und als nutzerzugängliche Befehle oder Templates gedacht, auch wenn das Protokoll keine konkrete UI vorschreibt.

Diese Labels sind keine Autorisierung. Die Wahl eines Tools durch das Modell gewährt kein Recht auf einen Side Effect; die Wahl einer Resource beweist keinen Zugriff auf jede URI; ein gestarteter Prompt autorisiert nicht alle darin beschriebenen Aktionen. Client und Server prüfen Identity, Scopes, Tenant, Target und aktuellen Zustand getrennt. Für folgenreiche Aktionen braucht es beim Ausführen Preview, Confirmation oder Policy Gate statt Vertrauen in eine frühere Prompt-Auswahl.

Eine Tool-Definition braucht einen stabilen Namen, eine klare Beschreibung und ein gültiges JSON Schema für den Input. Ein optionales outputSchema erlaubt dem Client, structuredContent zu validieren; das hilft Downstream-Automation, beweist aber nicht die Richtigkeit der Daten. Der Server validiert Schema und Business Constraints, prüft die Berechtigung für das konkrete Objekt und liefert bei behebbaren Domain-Fehlern einen Tool-Execution-Error. Protocol Errors bleiben fehlerhaften Requests oder unbekannten Tools vorbehalten.

Trennen Sie Read- und Write-Operationen. `orders.get` kann ein risikoarmer Lookup sein, während `orders.refund` Betrag, Währung, Order-Version, Begründung, Idempotency Key und Approval Receipt verlangen sollte. Vermeiden Sie ein universelles `execute_api` mit beliebigem Path und Body, weil es Authority für Modell, Reviewer und Audit Log versteckt. Tool Annotations sind nützliche UX-Hinweise, aber ohne Vertrauen in den Server keine Security Policy.

Ein Tool Result kann Text, Structured Content, einen Resource Link oder eine eingebettete Resource enthalten. Dadurch wird das Tool nicht zur Resource: Der Aufruf bleibt eine Operation mit Inputs, Timeout, Fehlersemantik und Audit Event. Hat ein großes Ergebnis eine stabile URI oder wird wiederverwendet, liefern Sie eine kurze strukturierte Zusammenfassung plus Resource Link statt den gesamten Corpus bei jedem Result zu kopieren.

• Input Schema prüft Form; Policy prüft Recht und Absicht.
• Output Schema prüft Struktur; das autoritative System prüft den Fakt.
• Write Tool → exaktes Target, Confirmation, Idempotency und Postcondition.
• Unklarer Timeout → vor Retry reconciliieren.

Eine Resource besitzt eine eindeutige URI und kann Text oder Binärdaten mit MIME Type enthalten. Resource Templates veröffentlichen parametrisierte URIs, optionale Completion kann beim Argument helfen. Ein Client ruft zuerst resources/list oder templates/list und danach resources/read auf. Subscriptions und listChanged sind separate optionale Capabilities; Resource-Support bedeutet keine automatische Aktualisierung.

Für Production sollten Source Owner, Data Classification, Revision oder lastModified, erlaubtes Publikum, Size Budget und Cache Policy festgehalten werden. Annotations wie `audience`, `priority` und `lastModified` sind Hinweise für den Client, keine Access-Control-Entscheidungen. Der Server prüft URI, Authorization und Resource Permission bei jedem Read. Legen Sie keine Secrets in vorhersehbare URIs und nehmen Sie nicht an, dass ein nicht gelistetes Element nicht direkt gelesen werden kann.

Eine Resource eignet sich für Kontext, garantiert aber nicht, dass das Modell sie korrekt verwendet oder zitiert. Evals sollten aktuelle Revision, Passage Support, Conflict Disclosure, No-Answer-Verhalten und Cross-Scope-Canaries prüfen. Für häufig wechselnde Business Facts ist ein Read-only Tool mit autoritativem Lookup zur Request-Zeit oft besser; für browsable Dokumentation mit stabilen Identifiers bietet eine Resource einen besseren Discovery- und Cache-Vertrag.

• Stabiler browsable Content → Resource oder Resource Template.
• Live parametrisierter Fakt → häufig Read-only Tool.
• Subscription ersetzt keinen Revision Check vor wichtigen Entscheidungen.
• URI-Sichtbarkeit ist keine Berechtigung.

Eine Prompt-Definition hat Name, optionalen Titel und Beschreibung sowie eine Liste von Argumenten. prompts/get liefert Beschreibung und Messages, in die der Server validierte Argumente einsetzt. Messages können Text, Bild, Audio oder eingebettete Resources enthalten. Ein guter Prompt beschreibt Ergebnis und erwartete Inputs: `review_incident` mit Incident ID und Review-Tiefe ist nützlicher als ein unpräzises `analyze`.

Ein Prompt eignet sich für discoverable Slash Commands, Onboarding oder standardisierte Analyseabläufe. Er ist keine serverseitige Automation und garantiert nicht die Ausführung der Instruktionen durch das Modell. Verstecken Sie keine Approval, Credentials oder irreversible Aktion im Template. Braucht der Workflow ein Tool, kann der Prompt Messages vorbereiten und Analyse anfordern, aber der Client wendet weiterhin Tool Policy an und der Server autorisiert den Call erneut.

Versionieren Sie den Template-Inhalt oder speichern Sie mindestens dessen Hash in Evaluation Evidence. listChanged meldet eine Katalogänderung, doch eine aktive Unterhaltung kann bereits alte Messages enthalten. Regression Tests sollten Argument Escaping, Prompt Injection in nutzergegebenen Feldern, fehlende Argumente, Locale, Embedded-Resource-Permissions und Verhalten nach einer Template-Änderung prüfen.

Betrachten wir einen Support Server. `support://policies/refunds/2026-09` ist eine Resource, weil es versionierter Policy-Content zum Lesen ist. `draft_refund_review` ist ein Prompt, weil der Nutzer ein wiederverwendbares Review Template mit Ticket ID auswählt. `tickets.get` und `refunds.create_draft` sind Tools, weil sie Runtime Lookup und kontrollierten Draft erzeugen. Das finale `refunds.submit` sollte mit stärkerem Scope und Confirmation getrennt werden. So bleiben Source, Reasoning Workflow und Authority als eigene Grenzen sichtbar.

Typische Fehler sind: jede Datenbankzeile als Tool veröffentlichen, einen Write Request in einer Resource URI verstecken, stale Policy ohne Revision über ein Tool liefern, einen Prompt als System Policy verwenden, denselben Content in Prompt, Resource und Tool Description duplizieren oder ein Mega-Tool für alle APIs anbieten. Das verschlechtert Discovery, erhöht Context, verwischt Permissions und verhindert eine saubere Failure-Lokalisierung.

Vor der Implementierung sollte eine kurze Contract Card ausgefüllt werden: User Outcome, Controller, Data Owner, Freshness, Input/Output Shape, Side Effects, Permission Check, Audit Event, Failure Semantics, Context Cost und Rollback. Haben zwei Entitäten unterschiedliche Authority oder Lifecycle, sollten sie unterschiedliche Primitives erhalten, selbst wenn der Backend Endpoint gemeinsam ist.

• Context Failure → Resource Revision und Selection prüfen.
• Instruction Failure → Prompt Version und Argument Handling prüfen.
• Execution Failure → Tool Schema, Policy, Effect und Reconciliation prüfen.
• Gemischter Failure → separate Receipts für jede Grenze speichern.

Beginnen Sie die Contract Suite mit Capability-Kombinationen: Server mit jedem Primitive einzeln, allen drei zusammen und Katalogänderungen. Testen Sie Pagination, unbekannte Names oder URIs, ungültige Argumente, MIME Handling, Structured Output, listChanged und Resource Subscriptions nur bei deklarierter Capability. Negative Security Cases tauschen Tenant, Target, URI, Prompt Argument und Tool Result aus, fügen indirekte Injection in eine Resource ein und wiederholen einen Write nach unklarem Timeout.

Führen Sie einen End-to-End-Eval auf einem synthetischen Support Case durch: Der Nutzer wählt einen Prompt, der Client liest eine konkrete Policy Revision, das Modell schlägt ein Read Tool vor und der Write Draft benötigt separate Confirmation. Das Evidence Pack enthält Protocol Version, Capability Manifest, Catalog Hashes, Resource Revision, gerenderten Prompt, Tool Inputs/Results, Approval Receipt, Final State und Reviewer Verdict. So lässt sich die fehlerhafte Grenze bestimmen, ohne einer flüssigen Final Answer zu vertrauen.

Starten Sie den Rollout mit einer Read-only Resource, einem Prompt und einem Read-only Tool. Nach Prüfung von Scope und Audit folgt ein reversibler Draft Write; irreversible Aktionen bleiben bis zu einem separaten Approval Contract außerhalb der Model Authority. Rollback deaktiviert die betroffene Capability oder das Tool, widerruft Scope, pinnt die letzte geprüfte Resource- oder Prompt-Revision und erhält Read-only Diagnostics. Reaktivierung verlangt Regression Tests für das geänderte Primitive und die gesamte Komposition.

• Hard Gate → Cross-Tenant Read, versteckter Side Effect oder unautorisierter Write.
• Quality Gate → stale Revision, unbelegte Aussage oder unklarer Prompt Outcome.
• Compatibility Gate → deklarierte Capability passt nicht zum Method Behavior.
• Recovery Gate → Retry dupliziert keinen Effect und unterbricht die Audit Chain nicht.