MCP-Ressourcen vs. Tools: Was ist der Unterschied und wann sollte welches verwendet werden?

Das Model Context Protocol (MCP) bietet KI-Anwendungen eine standardisierte Möglichkeit, Modelle mit externem Kontext und Funktionen zu verbinden. Für Entwickler, die MCP-Server entwickeln, ist die wichtigste Designentscheidung oft täuschend einfach: Sollte eine Funktion als Ressource oder als Tool bereitgestellt werden?

Die Unterscheidung prägt, wie ein Agent Informationen entdeckt, wann er Tokens verbraucht, was er ändern kann und wie Nutzer Risiken bewerten. Eine schlecht modellierte Funktion kann eine Integration schwerer nachvollziehbar machen: Statische Referenzdaten werden zu einem unnötigen Funktionsaufruf, oder eine folgenschwere Aktion erscheint als harmloser Kontext.

Praktisch gesehen stellen MCP-Ressourcen schreibgeschützte Informationen bereit, die eine Anwendung einem KI-System verfügbar machen kann. MCP-Tools stellen ausführbare Vorgänge bereit, die ein Modell anfordern kann. Das Verständnis der Grenze zwischen ihnen ist grundlegend für eine zuverlässige, sichere und token-effiziente Entwicklung von MCP-Servern.

Warum die Unterscheidung zwischen Ressourcen und Tools in MCP wichtig ist

KI-Agenten benötigen sowohl Informationen als auch die Fähigkeit zu handeln. Informationsabruf und Aktionsausführung haben jedoch unterschiedliche Vertrauensmodelle.

Ein Modell benötigt möglicherweise ein Datenbankschema, um zu verstehen, welche Abfragen möglich sind. Anschließend benötigt es möglicherweise eine separate Funktion, um eine genehmigte Abfrage auszuführen. Beide als denselben Integrationstyp zu behandeln, verschleiert die Absicht, verkompliziert Berechtigungen und kann zu übermäßigem Kontextverbrauch führen.

Die Unterscheidung zwischen Ressourcen und Tools ist wichtig, weil sie Folgendes verdeutlicht:

• Agentenverhalten: Das Modell kann stabilen Kontext prüfen, ohne gleichzeitig einen Vorgang anzufordern.
• Sicherheitsgrenzen: Lesezugriff und Schreibzugriff können unterschiedlich überprüft, eingegrenzt und verwaltet werden.
• Nutzervertrauen: Nutzer können unterscheiden, ob ein Agent etwas über ein System erfährt oder dieses System verändert.
• Token-Effizienz: Relevanter Kontext kann bei Bedarf abgerufen werden, statt wahllos in jeden Prompt eingefügt zu werden.
• Serverdesign: Funktionen lassen sich leichter benennen, dokumentieren, testen und warten.

MCP bedeutet nicht, dass jede verfügbare Ressource automatisch in den Modellkontext eingefügt wird. Ressourcen sind über das MCP-Funktionsmodell verfügbar, während die Host-Anwendung bestimmt, wie und wann sie bereitgestellt oder gelesen werden. Dieser hostgesteuerte Ansatz ist entscheidend, wenn die verfügbaren Informationen umfangreich, sensibel oder teuer zu laden sind.

Was sind MCP-Ressourcen?

MCP-Ressourcen sind schreibgeschützte, URI-basierte Kontextelemente, die von einem MCP-Server bereitgestellt werden. Sie sind für Informationen vorgesehen, die ein KI-System möglicherweise prüfen, zusammenfassen, analysieren oder zitieren muss, während es eine Aufgabe erledigt.

Eine Ressource ist nicht einfach irgendeine Datei oder ein allgemeiner API-Endpunkt. Innerhalb des Model Context Protocol ist sie eine auffindbare Einheit kontextbezogener Daten, die typischerweise durch eine URI identifiziert wird. Ein Server kann Ressourcen bereitstellen, die Dokumentation, Konfiguration, Schemas, Projektmetadaten, Wissensdatenbankseiten oder generierte Statusinformationen darstellen.

Häufige Beispiele sind ein Architekturleitfaden für ein Repository, eine `README`-Datei, ein OpenAPI-Schema, eine Datenbanktabellendefinition oder die aktuelle Konfiguration für eine Bereitstellungsumgebung. Sie sind nützlich, weil sie einem Agenten helfen, den Zustand und die Regeln eines Systems zu verstehen, bevor er Arbeit vorschlägt oder ausführt.

Auf Protokollebene können Server verfügbaren Kontext mit `resources/list` bekannt geben. Ein Client kann dann ein bestimmtes Element über `resources/read` abrufen. Diese Trennung ermöglicht es dem Host und dem Agenten, zu prüfen, was verfügbar ist, bevor der Inhalt selbst geladen wird.

Ressourcen sind besonders nützlich, wenn die Antwort aus vorhandenen, stabilen Informationen abgeleitet werden sollte. Beispielsweise kann ein Agent, der einen unbekannten Dienst prüft, eine Ressource mit dem API-Vertrag des Dienstes lesen, bevor er eine Integration vorschlägt. Die Ressource liefert Belege und Kontext; sie führt keine Änderung aus.

Was sind MCP-Tools?

MCP-Tools sind ausführbare Funktionen, die ein Modell über einen MCP-Server entdecken und aufrufen kann. Sie stellen Vorgänge dar: Aufgaben, deren Ausführung der Agent von einem verbundenen System anfordern kann.

Ein Tool kann eine API-Anfrage stellen, ein Ticket erstellen, eine Bereitstellungsprüfung ausführen, einen Bericht generieren, eine Nachricht senden oder in eine Datenbank schreiben. Viele Tools können Nebenwirkungen haben, aber Nebenwirkungen sind keine Voraussetzung. Eine schreibgeschützte Datenbankabfrage kann beispielsweise dennoch korrekt als Tool modelliert werden, wenn sie ein Vorgang mit Eingaben, Ausführungslogik und einem strukturierten Ergebnis ist.

Server stellen Tool-Definitionen über `tools/list` bereit. Jede Definition sollte einen klaren Namen, eine Beschreibung und ein Eingabeschema vermitteln. Das Modell ruft eine ausgewählte Funktion über `tools/call` auf und übergibt dabei Argumente, die der erwarteten Eingabe des Tools entsprechen.

Das zentrale Designprinzip lautet, dass ein Tool den Server auffordert, Arbeit zu erledigen. Seine Ausgabe kann Daten sein, aber diese Daten sind das Ergebnis einer Ausführung und kein direkt adressierbares Kontextartefakt.

Beispielsweise ist `create_linear_ticket` ein Tool, weil es einen externen Workflow veranlasst, ein neues Ticket zu erstellen. `get_deployment_status` kann ebenfalls ein Tool sein, wenn der Server ein Live-System unter Verwendung übergebener Umgebungs- und Dienstparameter abfragen muss. Beide Vorgänge benötigen einen expliziten Aufruf, auch wenn nur einer davon zwingend den Zustand verändert.

MCP-Ressourcen vs. Tools: Wichtige Unterschiede

Die Tabelle verdeutlicht eine praktische Grenze: Ressourcen beschreiben oder stellen Informationen bereit, während Tools Verhalten ausführen. In einem gut konzipierten MCP-Server bleibt die Unterscheidung sichtbar, selbst wenn beide Funktionen denselben übergeordneten Workflow unterstützen.

So wählen Sie zwischen einer Ressource und einem Tool

Beginnen Sie mit einer Frage: Muss der Agent Informationen prüfen oder muss der Server einen Vorgang ausführen?

Verwenden Sie eine Ressource, wenn die Informationen schreibgeschützt, natürlich adressierbar und als Kontext nützlich sind. Eine Konfigurationsdatei, Produktspezifikation, ein Richtliniendokument oder ein Datenbankschema passt in der Regel zu diesem Modell. Der Client kann das Element erkennen, entscheiden, ob es relevant ist, und es lesen, ohne Geschäftslogik auszulösen.

Verwenden Sie ein Tool, wenn die Aufgabe Eingaben, Ausführung oder ein Ergebnis erfordert, das nicht als statischer Kontext dargestellt werden kann. Das Erstellen eines Support-Tickets, Abrufen eines gefilterten Berichts, Starten eines Builds oder Aktualisieren eines Datensatzes gehört hinter ein Tool.

Einige Workflows benötigen beide Grundelemente. Betrachten Sie eine Integration für das Release-Management:

1. Stellen Sie Release-Richtlinien und Umgebungsdefinitionen als Ressourcen bereit. 2. Bieten Sie ein Tool an, um den Live-Bereitstellungsstatus für einen ausgewählten Dienst abzurufen. 3. Bieten Sie ein separates Tool an, um eine genehmigte Bereitstellung auszulösen.

Dieses Design ermöglicht es dem Agenten, zunächst Richtlinien und Umgebungsbeschränkungen zu verstehen, dann aktuelle Betriebsdaten anzufordern und erst danach eine folgenreiche Aktion zu beantragen. Die Trennung ist für Benutzer leichter zu prüfen und für Produktteams leichter abzusichern.

Vermeiden Sie es, jede Abfrage in eine Ressource umzuwandeln. Wenn die Informationen dynamisch, parametrisiert oder rechnerisch aufwendig sind, ist ein Tool in der Regel besser geeignet. Umgekehrt sollten Sie einfache, stabile Referenzinhalte nicht in ein Tool verpacken, wenn eine URI-basierte Ressource ihren Zweck deutlicher machen würde.

Praktische Beispiele für das Design von MCP-Servern

Ein Server für Repository-Dokumentation könnte Codierungsstandards, Architekturentscheidungsprotokolle und Karten der Service-Verantwortlichkeiten als Ressourcen bereitstellen. Diese Elemente sind nützliche Referenzmaterialien mit vorhersehbaren Adressen. Eine `search_repository_docs`-Funktion könnte ein Tool sein, wenn sie Schlüsselwörter akzeptiert und eine gezielte Suche in einem großen Dokumentationsbestand ausführt.

Bei Datenbankintegrationen eignen sich Tabellenschemata und genehmigte Datenwörterbücher gut als Ressourcen. Eine `run_readonly_query`-Funktion lässt sich besser als Tool modellieren, weil sie eine Abfrage oder strukturierte Filter akzeptiert, diese validiert, sie gegen ein Live-System ausführt und ein Ergebnis zurückgibt. Ein separates Schreib-Tool sollte niemals hinter derselben mehrdeutigen Schnittstelle verborgen werden.

Projektmanagement-Integrationen folgen demselben Muster. Eine Ressource kann die Workflow-Definitionen eines Sprint-Boards oder die Taxonomie von Issue-Labels bereitstellen. Ein Tool kann ein Ticket erstellen, seinen Status aktualisieren oder einen Verantwortlichen zuweisen. Die Informationen helfen dem Agenten, eine fundierte Anfrage zu stellen; das Tool führt die angeforderte Änderung aus.

Die Berichtserstellung ist ein weiterer nützlicher Sonderfall. Eine feste Vorlage für einen Quartalsbericht kann eine Ressource sein. Eine `generate_quarterly_report`-Operation ist ein Tool, weil sie einen Zeitraum akzeptiert, Live-Daten auswählt, Geschäftslogik anwendet und eine Ausgabe erstellt. Der generierte Bericht kann später als Ressource bereitgestellt werden, wenn er zu einem stabilen Artefakt wird, das andere Agenten prüfen sollen.

Pi MCP für Workflows von Technik zu Präsentation nutzen

Presentation Intelligence (Pi) unterstützt MCP-Workflows für Teams, die technische Arbeit in klare Kommunikation mit Stakeholdern umwandeln müssen. Pi MCP ist kein Ersatz für Code-Editoren, Versionskontrolle, Datenbanken oder andere MCP-Server. Es adressiert einen eigenständigen Schritt im Bereitstellungsprozess: die Übersetzung genehmigter technischer Kontexte in eine strukturierte, geschäftsfähige Präsentation.

1. Geschäftslogik kommt vor Foliengestaltung

In einer KI-gestützten Coding- oder Agent-Umgebung wie Claude Code verfügen Teams häufig bereits über das Rohmaterial für eine starke Präsentation: technische Briefings, Projektnotizen, Architekturerklärungen, Release-Zusammenfassungen und aus der Codebasis abgeleitete Erkenntnisse. Die Herausforderung besteht darin, dieses Material in eine zielgruppengerechte Erzählung zu verwandeln, statt in eine Sammlung unverbundener Folien.

Mit Pi MCP kann ein Agent-Workflow ein definiertes Briefing oder einen genehmigten Kontext an Presentation Intelligence übergeben, um eine präsentationsstruktur zu erstellen, bei der die Logik im Vordergrund steht. Dies ist nützlich für Aktualisierungen von Engineering-Roadmaps, Projektprüfungen für Führungskräfte, technische Vertriebspräsentationen, Beratungsberichte und Produktlaunch-Narrative, bei denen die Storyline genauso glaubwürdig sein muss wie die zugrunde liegende Umsetzung.

2. Die Erstellung bleibt im bestehenden Workflow sichtbar

Die Erstellung von Präsentationen kann Entwickler und Produktteams andernfalls dazu zwingen, ihre Arbeitsumgebung zu verlassen, technische Notizen manuell neu zu organisieren und wiederholt einen separaten Produktionsprozess zu überprüfen. Pi MCP ermöglicht Teams, die Präsentationsarbeit zu starten und den Erstellungsfortschritt innerhalb ihres bestehenden Agent-Workflows zu verfolgen.

Diese Kontinuität ist wichtig, wenn die Präsentation von sich entwickelndem Projektkontext abhängt. Ein Team kann das Briefing verfeinern, die Anforderungen der Zielgruppe klären und den Präsentations-Workflow überwachen, ohne Kommunikation als nachträglichen Einfall zu behandeln. Pis Multi-Agent-KI-Ansatz unterstützt den Übergang von komplexen Eingaben zu professioneller Struktur und hochwertigen Geschäftspräsentationen, während das Team die Kontrolle darüber behält, welche Kontexte geteilt werden.

Best Practices für sichere und token-effiziente MCP-Integrationen

Gute MCP-Serverentwicklung beginnt mit klar abgegrenzten, verständlichen Funktionen. Begrenzen Sie Ressourcen auf Informationen, die ein Agent wirklich benötigt. Eine riesige, undifferenzierte Wissenssammlung kann Tokens verbrauchen, ohne Entscheidungen zu verbessern. Bevorzugen Sie kleinere Ressourcen mit aussagekräftigen URIs, klaren Beschreibungen und vorhersehbaren Grenzen.

Verwenden Sie für Tools präzise Namen und explizite Eingabeschemas. `create_customer_ticket` vermittelt mehr als `manage_ticket`, und ein Schema, das Titel, Priorität und Kunden-ID trennt, reduziert Mehrdeutigkeit. Geben Sie strukturierte, umsetzbare Ergebnisse zurück, damit ein Agent bestimmen kann, was passiert ist, ohne dasselbe Tool wiederholt aufzurufen.

Trennen Sie Lese- und Schreibvorgänge, wann immer möglich. Ein Tool, das sowohl ein System prüft als auch verändert, erschwert die Überprüfung von Berechtigungen. Wenn eine Aktion folgenreich ist – etwa das Löschen von Datensätzen, das Senden externer Nachrichten oder das Auslösen von Produktionsbereitstellungen –, wenden Sie das Prinzip der geringsten Berechtigung an und verlangen Sie im Host-Erlebnis eine angemessene Benutzerbestätigung.

Entwerfen Sie schließlich für schrittweise Offenlegung. Lassen Sie Agenten zunächst Funktionen entdecken, nur relevante Ressourcen abrufen und Tools nur aufrufen, wenn ein Vorgang erforderlich ist. Dieser Ansatz reduziert Token-Verschwendung, begrenzt die Offenlegung sensibler Daten und macht den Denkweg eines Agenten verständlicher.

Das praktische Fazit: Modellieren Sie Kontext als Ressourcen, Vorgänge als Tools

Die zuverlässigste Regel für das MCP-Design ist unkompliziert: Stellen Sie dauerhaften, schreibgeschützten Kontext als Ressourcen und ausführbare, parametrisierte Arbeit als Tools bereit. Diese Grenze verbessert Sicherheitsprüfungen, hält das Verhalten von Agenten nachvollziehbar und hilft Teams, Kontextbudgets zu verwalten, ohne auf nützlichen Zugriff zu verzichten.

Für komplexe Workflows kombiniert das stärkste Design häufig beides. Ressourcen liefern die Fakten und Einschränkungen, die ein Agent benötigt; Tools bieten sorgfältig geregelte Möglichkeiten, darauf zu handeln. Pi MCP wendet dasselbe Muster auf technische Kommunikation an und hilft Teams, genehmigten Projektkontext in strukturierte Präsentationen umzuwandeln, während sie in den KI-Umgebungen bleiben, in denen die Arbeit bereits stattfindet.