Die drei MCP-Primitive verstehen, Tools, Resources und Prompts

Wenn Du Dir MCP-Server anschaust fällt Dir schnell was auf. Alle reden nur von Tools. Tool hier, Tool da, "mein Server hat 40 Tools". Dabei definiert das Model Context Protocol drei verschiedene Bausteine die ein Server anbieten kann, und Tools sind nur einer davon. Die anderen zwei, Resources und Prompts, werden fast überall ignoriert. Das ist schade, weil sie genau die Probleme lösen für die Leute sonst Tools missbrauchen.

Dieses Playbook bringt Dir das Modell bei. Nicht als Spec-Vorlesung, sondern so dass Du danach jeden fremden Server in dreißig Sekunden einordnen kannst und beim eigenen Bauen die richtige Wahl triffst. Zehn Schritte, jeder mit einem konkreten Beispiel. Am Ende weißt Du warum ein Kalender-Server "freie Termine finden" als Tool anbietet, "meine Kalenderregeln" als Resource und "Meeting zusammenfassen" als Prompt, und warum das kein Zufall ist.

Schritt 1, die eine Frage die alles entscheidet

Merk Dir eine Frage, dann hast Du das ganze Modell verstanden: Wer entscheidet, dass dieser Baustein gerade benutzt wird? Es gibt drei mögliche Antworten und genau drei Primitive.

Tools sind model-controlled. Das Modell selbst entscheidet mitten in einer Antwort, jetzt rufe ich das auf. Resources sind application-controlled. Die App drumherum, also Claude Code oder ein Chat-Client, entscheidet ob und wann sie geladen werden. Prompts sind user-controlled. Der Mensch wählt sie aktiv aus, meistens über ein Menü oder einen Slash-Command.

Diese drei Kontroll-Ebenen sind der ganze Trick. Wenn Du beim Bauen unsicher bist welchen Baustein Du nimmst, frag Dich einfach wer die Kontrolle haben soll. Die Antwort zeigt Dir das Primitiv.

Schritt 2, Tools sind Aktionen die das Modell auswählt

Ein Tool ist eine Funktion die das Modell aufrufen kann um etwas zu tun oder etwas nachzuschlagen. Wetter abfragen, eine Datei schreiben, eine Rechnung im CRM anlegen, eine Suche starten. Das Modell liest die Beschreibung des Tools, entscheidet selbst ob es passt, und ruft es mit Argumenten auf.

Das Entscheidende ist die Selbstständigkeit. Du sagst "leg mir den Kunden Meier an" und das Modell wählt aus zwanzig Tools das richtige, füllt die Felder und feuert. Niemand hat vorher gesagt welches Tool. Deshalb model-controlled.

Weil Tools Aktionen auslösen können die echte Folgen haben, brauchen sie in fast jedem Client eine Bestätigung bevor sie laufen. Das ist der Grund warum Claude Code Dich vor einem schreibenden Tool fragt. Ein Tool kann eine Mail rausschicken oder eine Zeile in einer Datenbank ändern, und das soll nicht lautlos passieren.

Schritt 3, warum alle nur Tools bauen

Tools sind das erste was jeder lernt, sie sind am einfachsten zu erklären, und ehrlich gesagt kann man mit Tools allein schon fast alles bauen. Genau das ist die Falle. Weil Tools so mächtig sind, stopfen Leute alles in Tools rein, auch Sachen die eigentlich Resources oder Prompts wären.

Ein typisches Beispiel. Jemand baut ein Tool namens get_company_guidelines das immer denselben Textblock zurueckgibt, die Firmenrichtlinien. Das Modell muss das Tool erst aktiv aufrufen, es kostet einen Roundtrip, und es steht in der Tool-Liste rum und lenkt ab. Dabei sind statische Richtlinien der Lehrbuchfall für eine Resource. Wer die drei Primitive kennt macht das sauberer.

Schritt 4, Resources sind Kontext den die App lädt

Eine Resource ist ein Stück Kontext das der Server bereitstellt und das die App ins Gespräch ziehen kann. Eine Datei, ein Datenbank-Auszug, ein Log, eine Konfiguration, ein Bild. Resources werden über eine URI identifiziert, sowas wie file:///projekt/readme.md oder db://kunden/meier.

Der Unterschied zum Tool ist die Kontrolle. Bei einer Resource entscheidet nicht das Modell, sondern die Anwendung, ob und wann der Inhalt geladen wird. In der Praxis heißt das oft, der Nutzer klickt in einem Menü "diese Resource anhängen", oder die App zieht sie automatisch weil sie zum Kontext passt. Das Modell bekommt den Inhalt dann serviert, es hat ihn nicht selbst geholt.

Warum ist das besser als ein Tool das denselben Text liefert? Weil eine Resource keinen Roundtrip kostet und keine Entscheidung vom Modell verlangt. Sie ist einfach da, sauber als Kontext markiert. Für alles was Nachschlage-Material ist und keine Aktion, ist die Resource die richtige Wahl.

Schritt 5, das Kalender-Beispiel für Resources

Stell Dir einen Kalender-Server vor. "Meine Verfügbarkeit die nächsten zwei Wochen" ist eine Resource. Sie ist Kontext, sie löst keine Aktion aus, und die App kann sie an ein Gespräch hängen wenn es um Terminplanung geht.

Der feine Unterschied zu einem Tool. "Freie Termine finden zwischen zwei Daten" wäre ein Tool, weil das Modell aktiv mit Parametern rechnet und filtert. "Hier ist mein voller Kalender als Kontext" ist eine Resource, weil es nur Material bereitstellt. Dasselbe Thema, zwei verschiedene Bausteine, je nachdem ob gehandelt oder nachgeschlagen wird.

Schritt 6, Prompts sind Vorlagen die der Mensch startet

Ein Prompt im MCP-Sinn ist nicht der Text den Du tippst. Es ist eine vordefinierte Vorlage oder ein Workflow den der Server anbietet und den der Nutzer bewusst auswählt. In vielen Clients tauchen sie als Slash-Commands auf oder in einem Menü mit den verfügbaren Aktionen.

Das ist der user-controlled Baustein. Der Mensch sagt "ich will jetzt den Code-Review-Ablauf", wählt den Prompt, gibt vielleicht ein paar Parameter ein, und der Server liefert eine fertig strukturierte Anweisung zurück die das Gespräch in Gang setzt. Das Modell hat den Prompt nicht selbst gewählt und die App auch nicht, sondern Du.

Ein Prompt kann Resources und Tools zusammenbinden. Der "Meeting zusammenfassen" Prompt zieht vielleicht das Transkript als Resource rein und ruft am Ende ein Tool auf das die Zusammenfassung ablegt. Prompts sind damit oft die Klammer um einen ganzen Ablauf.

Schritt 7, die drei nebeneinander an einem Server

Nimm den Kalender-Server nochmal und leg alle drei Primitive übereinander, dann siehst Du das Muster.

Tool, freie Termine finden, das Modell entscheidet und rechnet. Resource, meine Kalenderregeln und meine nächsten zwei Wochen, Kontext den die App anhängt. Prompt, plane mir ein Meeting mit Team X, ein Ablauf den ich als Mensch starte und der intern die Resource liest und am Ende das Tool feuert.

Das ist kein akademisches Konstrukt. Ein durchdachter Server nutzt bewusst alle drei, und wer die Aufteilung sieht versteht sofort wie der Server gedacht ist. Wer nur Tools sieht weiß, hier hat jemand die anderen zwei Bausteine liegen lassen.

Schritt 8, so ordnest Du einen fremden Server ein

Wenn Du einen neuen MCP-Server dazuklickst, schau Dir an was er anbietet und sortier es im Kopf. Die meisten Clients zeigen Dir Tools sowieso, viele auch Prompts als Slash-Commands, und Resources tauchen oft in einem Anhängen-Menü auf.

Frag Dich bei jedem Eintrag, was ist das. Löst es eine Aktion aus, model-controlled, dann Tool. Ist es Nachschlage-Material das reingezogen wird, application-controlled, dann Resource. Ist es ein Ablauf den Du selbst startest, user-controlled, dann Prompt. Nach drei, vier Servern machst Du das automatisch und verstehst fremde Server viel schneller.

Schritt 9, die Design-Regel fürs eigene Bauen

Wenn Du selbst einen Server baust, triff die Entscheidung bewusst statt reflexartig alles zu Tools zu machen. Die Faustregel ist kurz.

Handelt es, nimm ein Tool. Ist es statischer oder abfragbarer Kontext ohne Nebeneffekt, nimm eine Resource. Ist es ein wiederkehrender Ablauf den ein Mensch anstößt, nimm einen Prompt. Wenn Du merkst dass ein Tool eigentlich nur immer denselben Text zurueckgibt, ist das ein starkes Signal dass es eine Resource sein sollte. Und wenn Du dem Nutzer einen komplexen mehrstufigen Ablauf abnehmen willst, pack ihn in einen Prompt statt zu hoffen dass das Modell die Schritte von allein richtig zusammensetzt.

Ein Nebeneffekt dieser Sauberkeit ist weniger Tool-Sprawl. Jedes Tool das eigentlich eine Resource ist, verstopft die Tool-Liste und macht die Auswahl fürs Modell schwerer. Weniger, gezieltere Tools plus ordentliche Resources plus ein paar Prompts, das ist ein Server der sich gut anfühlt.

Schritt 10, was Clients tatsächlich unterstützen

Ein ehrlicher Hinweis zum Schluss. Nicht jeder Client kann alle drei Primitive gleich gut. Tools unterstützt praktisch jeder. Prompts als Slash-Commands sind weit verbreitet. Resources werden nicht überall gleich sichtbar gemacht, manche Clients zeigen sie prominent, andere kaum.

Für Dich heißt das, bau Deinen Server ruhig sauber mit allen drei Primitiven, aber verlass Dich beim Wichtigsten nicht darauf dass jeder Client die Resource auch anzeigt. Kern-Funktionalität die auf jeden Fall laufen muss, gehört in Tools, weil die überall gehen. Resources und Prompts sind die Kür die Deinen Server rund machen wo der Client mitspielt. Welcher Client was kann steht in der offiziellen Client-Übersicht, und die ändert sich schnell, also einmal nachschauen bevor Du Dich auf ein Feature verlässt.

Was als nächstes

Jetzt hast Du das Modell im Kopf und kannst Server einordnen. Der logische nächste Schritt ist selbst einen bauen. Dafür gibt es das Playbook Erster MCP-Server in 90 Minuten, wo Du das Ganze in Code gießt. Wenn Dein Server dann läuft aber der Client ihn nicht sauber anzeigt, hilft MCP debuggen wenn nichts geht. Und die konzeptionelle Grundlage warum MCP überhaupt so gebaut ist, steht in Level 4 Lesson Was ist MCP.

Quellen

• Model Context Protocol, Understanding MCP servers (Tools, Resources, Prompts und ihre Kontroll-Modelle): https://modelcontextprotocol.io/docs/learn/server-concepts
• Model Context Protocol, offizielle Spezifikation: https://modelcontextprotocol.io/specification