Tools, Resources, Prompts: Was ein MCP-Server wirklich anbietet

Die kurze Antwort: MCP Tools, Resources und Prompts sind die drei Primitiven, die ein MCP-Server anbieten kann, und sie gehören drei verschiedenen Chefs. Tools sind Aktionen, deren Aufruf das Modell entscheidet. Resources sind Daten, die die Anwendung an den Kontext anhängt. Prompts sind Vorlagen, die der Nutzer aus einem Menü wählt. Das ist die ganze Karte, und in der Praxis liefern die meisten Server, die du 2026 verbindest, nur Tools.

Falls dir die Server-Seite selbst noch unscharf ist, starte mit [Was ist ein MCP-Server?](/de/blog/what-is-an-mcp-server) und komm dann zurück. Hier geht es darum, was ein laufender Server konkret bereitstellen kann.

MCP Tools, Resources und Prompts: sortiert nach Entscheider

Die sauberste Art, die drei MCP-Primitiven auseinanderzuhalten, ist nicht ihr Inhalt, sondern wer sie benutzen darf.

Primitive	Wer entscheidet	Was es ist	Konkretes Beispiel
Tool	Das Modell	Eine Aktion mit typisiertem Eingabe-Schema	create_ticket auf einem Helpdesk-Server
Resource	Die Anwendung	Lesbare Daten hinter einer URI	Das Schema einer Datenbanktabelle
Prompt	Der Nutzer	Eine wiederverwendbare Vorlage mit Argumenten	Ein verpackter "Review dieses PRs"-Befehl

Diese Kontroll-Hierarchie ist die eigentliche Design-Idee des Protokolls, und sie entscheidet die meisten "Tool oder Resource?"-Debatten.

Tools: Das Modell drückt ab

Ein Tool ist eine Funktion, die der Server mit Namen, Beschreibung und einem JSON-Eingabe-Schema beschreibt. Der Client gibt diese Liste ans Modell, und das Modell entscheidet mitten im Gespräch, ob es eines aufruft und mit welchen Argumenten.

Konkretes Beispiel: Ein Helpdesk-Server bietet create_ticket mit Feldern für Betreff, Text und Priorität an. Du tippst "leg ein Ticket zum kaputten CSV-Export an, hohe Priorität", das Modell füllt das Schema, der Client führt den Aufruf aus, und das Ticket existiert. Die API hast du nie angefasst.

Du kannst heute ein echtes ausprobieren: Tulimoas Verzeichnis-Server auf [mcp.tulimoa.com](/de/mcp) bietet search_listings als Lese-Tool an, ganz ohne Account. Frag deinen Agenten nach "EU-gehostete CRMs mit MCP-Support" und schau zu, wie er die Filter selbst ausfüllt.

Resources: Die Anwendung hängt Kontext an

Eine Resource ist ein Stück Daten, das der Server hinter einer URI lesbar macht: eine Datei, eine Doku-Seite, ein Schema, ein Log. Entscheidend: Das Modell holt sich Resources nicht selbst. Der Client (oder du, über dessen Oberfläche) entscheidet, eine anzuhängen, und der Inhalt landet als Kontext im Gespräch.

Konkretes Beispiel: Ein Postgres-Server stellt jedes Tabellen-Schema als Resource bereit. Häng das orders-Schema an, bevor du nach einer Query fragst, und das Modell schreibt beim ersten Versuch korrektes SQL, ohne Tool-Aufruf und ohne Modell-Entscheidung. Der Kontext war einfach da, und genau das ist der Punkt.

Prompts: Der Nutzer wählt eine Vorlage

Ein Prompt ist eine wiederverwendbare Vorlage, die der Server mitliefert, meist mit Argumenten, und die im Client als Menüeintrag oder Slash-Befehl auftaucht. Der Server-Autor verpackt damit sein eigenes Prompt-Engineering, damit Nutzer es nicht neu erfinden müssen.

Konkretes Beispiel: Ein Code-Review-Server liefert einen review_pr-Prompt, der eine PR-Nummer nimmt. Der Nutzer wählt ihn, der Client zieht den Diff in die Vorlage, und das Modell bekommt eine sauber strukturierte Review-Anfrage statt "schau dir mal diesen PR an".

Die meisten echten Server liefern nur Tools. Das ist okay.

Geh ein beliebiges MCP-Verzeichnis durch und zähl die Primitiven: Die große Mehrheit bietet Tools an, keine Resources, keine Prompts. Drei Gründe, und keiner davon ist Faulheit.

Client-Support ist ungleichmäßig. Jeder große Client führt Tools von Anfang bis Ende aus. Resources und Prompts werden von manchen Clients gut behandelt und von anderen ignoriert, und ein Server-Autor hat wenig davon, Primitiven zu bauen, die die Hälfte seiner Nutzer nie auslösen kann. Die Aufteilung zählt, weil Primitiven ein Vertrag zwischen zwei Seiten sind, und [Client und Server besitzen je eine Hälfte davon](/de/blog/mcp-client-vs-mcp-server).

Tools können den Rest nachbilden. Ein Lese-Tool wie get_document liefert dieselben Bytes wie eine Resource. Der Unterschied ist, wer den Anstoß gibt, und in einer Agenten-Schleife willst du meist ohnehin das Modell am Steuer, weil niemand daneben sitzt und auf Anhängen klickt.

Der Agenten-Anwendungsfall belohnt Modell-Kontrolle. Wenn das Ziel ein Agent ist, der mehrschrittige Arbeit selbstständig erledigt, trägt die modellgesteuerte Primitive die Last. Resources und Prompts glänzen in Chat-Oberflächen mit Mensch in der Schleife, und das ist ein anderes Produkt.

Ein Nur-Tools-Server ist also kein halbfertiger Server. Für Agenten-Arbeit ist er der Hauptjob, ordentlich gemacht.

Der Haken: Tool-Schemas kosten Kontext, bevor irgendetwas passiert

Hier ist die Asymmetrie, die man kennen sollte. Resources und Prompts kosten nichts, bis jemand sie anhängt oder aufruft. Tool-Definitionen sind anders: Name, Beschreibung und das volle JSON-Schema jedes Tools werden vorab in den Kontext des Modells geladen, in jeder Session, genutzt oder nicht.

Die Rechnung summiert sich schnell. Ein Server mit 20 Tools bei grob 350 Tokens pro Schema sind etwa 7.000 Tokens vor deinem ersten Wort. Verbinde fünf solcher Server, und du trägst rund 35.000 Tokens Katalog in jede Session. Diese Standgebühr ist der Grund, warum es beim [Senken des MCP-Token-Verbrauchs](/de/blog/reduce-mcp-token-usage) vor allem darum geht, welche Tool-Definitionen geladen werden, nicht um kürzere Prompts.

Häufige Fragen

Was ist der Unterschied zwischen MCP Tools und Resources?

Kontrolle. Ein Tool ruft das Modell auf, wenn es eines braucht; eine Resource hängt die Anwendung oder der Nutzer an. Dieselben Daten können durch beides fließen, also entscheide nach Auslöser: Modell-initiiert heißt Tool, Mensch-oder-App-initiiert heißt Resource.

Warum haben die meisten MCP-Server nur Tools?

Weil Tools die einzige Primitive sind, die jeder große Client voll unterstützt, ein Lese-Tool alles liefern kann, was eine Resource kann, und Agenten-Workflows das Modell am Steuer wollen. Resources und Prompts zu bauen, die viele Clients ignorieren, lohnt sich für die meisten Server-Autoren nicht.

Verbrauchen Resources und Prompts Kontext wie Tool-Schemas?

Erst bei Benutzung. Tool-Schemas laden in jeder Session in den Kontext; eine Resource kostet erst Tokens, wenn sie angehängt wird, ein Prompt erst beim Aufruf. Eine riesige angehängte Resource kann dein Kontextfenster trotzdem fluten, aber im Voraus wird nichts berechnet.

Woran erkenne ich, welche Primitiven ein Server unterstützt?

Beim Initialize-Handshake tauschen Client und Server ihre MCP-Capabilities aus, danach ruft der Client tools/list, resources/list und prompts/list für alles Deklarierte auf. Praktisch heißt das: Doku des Servers lesen, oder verbinden und schauen, was dein Client anzeigt.