Zum Inhalt springen

Blog

MCP Tools, Resources und Prompts: Unterschiede und Test

MCP Tools, Resources und Prompts unterscheiden: Methoden, Beispiele und Clientprüfung. Finden Sie heraus, warum eine Verbindung nicht alle Funktionen zeigt.

Veröffentlicht am · von tracevero · Lesezeit 4 Minuten (632 Wörter)

Ein MCP-Server kann ausführbare Werkzeuge, lesbare Ressourcen und vorbereitete Dialogvorlagen anbieten. Diese drei Angebote heißen Tools, Resources und Prompts. Sie erfüllen unterschiedliche Aufgaben und können im Client an verschiedenen Stellen erscheinen. Wer nur die Werkzeugliste prüft, sieht daher möglicherweise nur einen Teil des Angebots. Dieser Leitfaden hilft Ihnen, eine erwartete Funktion einzuordnen und gezielt zu testen, bevor Sie die gesamte Einrichtung ändern.

Welche Funktion brauchen Sie?

Stellen Sie die gewünschte Handlung an den Anfang: Möchten Sie eine Suche ausführen, ein bereitgestelltes Dokument lesen oder eine wiederverwendbare Vorlage auswählen? In der Protokollfassung 2025-11-25 gehören dazu verschiedene Methoden. Die folgende Tabelle zeigt die Zuordnung. Die Beispiele beschreiben mögliche Anwendungen; sie behaupten nicht, dass jeder Server diese Funktionen mitbringt.

Drei Angebote eines MCP-Servers
AngebotBeispielMethoden
ToolEine Suche ausführentools/list, tools/call
ResourceEin bereitgestelltes Dokument lesenresources/list, resources/read
PromptEine Vorlage mit Argumenten abrufenprompts/list, prompts/get

Eine Resource hat eine URI. Das muss keine öffentliche Webadresse sein: Ein Server kann ein eigenes URI-Schema verwenden. Parametrisierte Ressourcen werden über resources/templates/list beschrieben. Ein Prompt liefert eine Vorlage mit Nachrichten zurück; sein Abruf bedeutet nicht, dass darin beschriebene Werkzeuge bereits ausgeführt wurden. Bei einem Tool legen Name und Eingabeschema fest, welcher Aufruf möglich ist.

Serverfähigkeit und Clientoberfläche getrennt prüfen

Beim Verbindungsaufbau werden Fähigkeiten ausgehandelt. Ein Server muss nicht alle drei Angebote bereitstellen. Ebenso kann ein Client bestimmte Funktionen unterstützen, ohne sie im selben Menü zu zeigen. Halten Sie deshalb Serverfassung, Clientversion und erwartetes Angebot fest. Ein leeres Werkzeugmenü allein beweist keinen vollständigen Verbindungsausfall. Prüfen Sie zuerst, ob Sie tatsächlich ein Tool erwarten oder eine Resource beziehungsweise einen Prompt suchen.

Ein nachvollziehbarer Prüfweg 1. Erwartung Funktion zuordnen 2. Angebot Passende Liste lesen 3. Ergebnis Einen Aufruf prüfen
Vorgeschlagene Prüfung für Ihre Einrichtung; kein durchgeführter Anbietertest.

Für einen getrennten Test nutzen Sie den Inspector-Leitfaden. Vergleichen Sie dort das Serverangebot mit Ihrem Client. Die Clientübersicht hilft bei der passenden Einrichtung. Eine erfolgreiche Liste bestätigt zunächst nur, dass diese Liste abgerufen werden konnte. Die Operation selbst und ihr Ergebnis prüfen Sie anschließend.

Ein kleines Prüfprotokoll anlegen

  1. Wählen Sie eine unkritische Testdatei, einen Testbegriff oder eine Vorlage. Schreiben Sie das erwartete Ergebnis auf, bevor Sie beginnen.

  2. Lesen Sie die passende Liste. Berücksichtigen Sie Folgeseiten, falls die Antwort einen nextCursor enthält.

  3. Rufen Sie genau das gewählte Angebot ab: ein Tool mit den geforderten Argumenten, eine Resource mit ihrer URI oder einen Prompt mit seinen Parametern.

  4. Vergleichen Sie Inhalt und Erwartung. Notieren Sie Methode, Namen, Zeitpunkt und Ergebnis ohne Zugangsdaten.

Beispiel für Ihren eigenen Test: Ein Dokument enthält die Zeile „Prüfstand Oktober“. Wenn der Server dieses Dokument als Resource anbietet, lesen Sie dessen URI und suchen genau diese Zeile in der Antwort. Wenn stattdessen ein Dateilesewerkzeug angeboten wird, testen Sie dieses Tool. Ein gleicher Inhalt kann über unterschiedliche Angebote erreichbar sein; entscheidend ist die dokumentierte Schnittstelle Ihres Servers.

Fehlende und fehlerhafte Ergebnisse einordnen

Ein unbekannter Methodenname, eine leere Liste und ein fehlgeschlagener Werkzeugaufruf sind verschiedene Befunde. Lesen Sie bei Tools auch den Fehlerindikator isError im Ergebnis. Für fehlende Werkzeuge führt die gezielte Diagnose weiter. Falls die Verbindung gar nicht aufgebaut wird, beginnen Sie im Fehler-Navigator. Ändern Sie immer nur eine Einstellung und wiederholen Sie denselben Versuch.

Muss jeder MCP-Server alle drei Angebote haben?
Nein. Maßgeblich sind die angekündigten Fähigkeiten und die Dokumentation der konkreten Fassung.
Ist eine Resource immer eine Datei?
Nein. Ressourcen können unterschiedliche Inhalte mit einer URI adressieren. Das URI-Schema muss nicht HTTP sein.
Startet prompts/get automatisch Werkzeuge?
Der Abruf liefert die Vorlage. Die weitere Verarbeitung übernimmt der Client.
Beweist tools/list einen erfolgreichen Zugriff auf meine Daten?
Nein. Prüfen Sie zusätzlich einen passenden, begrenzten Werkzeugaufruf und dessen Ergebnis.

Offizielle Dokumentation geprüft am 1. Oktober 2026. Beispiele und Prüflisten sind redaktionelle Vorschläge.

  1. MCP tools
    Abrufbefehl anzeigencurl -s https://modelcontextprotocol.io/specification/2025-11-25/server/tools
  2. MCP resources
    Abrufbefehl anzeigencurl -s https://modelcontextprotocol.io/specification/2025-11-25/server/resources
  3. MCP prompts
    Abrufbefehl anzeigencurl -s https://modelcontextprotocol.io/specification/2025-11-25/server/prompts
  4. MCP architecture
    Abrufbefehl anzeigencurl -s https://modelcontextprotocol.io/specification/2025-11-25/architecture

Weiter zur Anwendung

Alle Beiträge

tracevero · https://tracevero.de/blog/mcp-tools-resources-prompts