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

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.
• Elicitation (Spezifikation 2026-07-28) — ein vierter, eigenständiger Kontrollort: Der SERVER entscheidet mitten in der Aufgabe, dass er eine weitere Angabe braucht, aber der CLIENT entscheidet, wie und ob er sie beim Menschen einholt; weder Resource, noch Tool, noch Prompt.
• Skills over MCP (Community-Erweiterung, Spezifikation 2026-07-28) — strukturierte, vom Menschen auffindbare Playbooks oberhalb des bestehenden Dreiklangs; bezüglich des Auslösers näher am Prompt, strukturell reicher als Resource oder Prompt.

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.

Elicitation

Eine in der MCP-Spezifikation (2026-07-28) formalisierte Client-Funktion: Der Server löst mitten in der Aufgabe eine Anfrage nach einer weiteren Angabe des Nutzers aus; der Client — nicht das Modell, nicht der Server allein — entscheidet, wie und ob diese Anfrage angezeigt wird. Unterscheidet sich von den drei ursprünglichen Oberflächen, weil der Auslöser serverseitig, die Erfüllung aber clientvermittelt ist.

Skills over MCP

Eine optionale MCP-Erweiterung (Ergebnis einer Community-Arbeitsgruppe, Spezifikation 2026-07-28), die reichhaltige, strukturierte, von Menschen verfasste Anweisungen für Agenten-Workflows über das Protokoll bereitstellt — eine kuratierte Playbook-Schicht, auffindbar und vom Menschen ausgelöst wie ein Prompt, jedoch mit mehr innerer Struktur als eine Vorlage.

Completions utility

Ein MCP-Server-Utility (Spezifikation 2026-07-28, server/utilities/completion), mit dem ein Server gültige Argumentwerte für einen Prompt oder ein Ressourcen-Template vorschlägt, während der Nutzer tippt — eine anwendungsgesteuerte Erleichterung, keine Entscheidung des Modells.

Quellen

1. MCP specification — Architecture overview
2. Anthropic MCP examples repository
3. Model Context Protocol — Specification index, revision 2026-07-28
4. Model Context Protocol — Server Features: Tools (spec 2026-07-28)
5. Model Context Protocol — Server Features: Resources (spec 2026-07-28)
6. Model Context Protocol — Server Features: Prompts (spec 2026-07-28)
7. Model Context Protocol — Extensions overview (spec 2026-07-28)
8. Model Context Protocol — Skills extension overview
9. Model Context Protocol — MCP Apps extension overview
10. Model Context Protocol — Understanding MCP clients (elicitation, roots and sampling as client features)
11. Model Context Protocol — Client Best Practices (progressive discovery and context cost of tool definitions)
12. Claude Platform Docs — Tool search tool (native search over large tool catalogues)
13. CIO — If AI makes the decision, who owns the consequence? (decision rights and authority drift, 28 Sep 2026)
14. SiliconANGLE — Komprise combats ‘MCP bloat’ with a universal interface for AI agents to access enterprise data (metadata-first pattern, 29 Sep 2026)