Was ist MCP-Tool-Metadaten-Injection?
MCP-Tool-Metadaten-Injection bezeichnet Einfluss, der ein Modell über beschreibendes Material erreicht, das ein MCP-Server liefert, bevor überhaupt ein Tool aufgerufen wird: Tool-Namen und Titel, Beschreibungen, Eingabeschemas samt Feldbeschreibungen, Annotationen, Server-Instruktionen und weiterer vom Server gelieferter Text, den ein Host dem Modell zeigt. Dieses Material kann beeinflussen, welches Tool der Planner wählt, wie er eine Aufgabe liest und wie er eine Fähigkeit deutet.
Der Name ist ein beschreibender Taxonomiebegriff dieser Website. Die Spezifikation des Model Context Protocol definiert keine formale Schwachstellenkategorie mit genau diesem Namen. In Forschung und Community finden sich überlappende Begriffe wie Tool Description Poisoning oder Tool Registration Poisoning; keiner davon ist ein allgemein standardisiertes Etikett.
Warum dies eine eigene Grenze ist
Die meisten Diskussionen über Prompt Injection konzentrieren sich auf Inhalte, die während einer Aufgabe ankommen: Nutzereingaben, abgerufene Seiten, Tool-Ergebnisse. Tool-Metadaten kommen früher an und liegen näher an der Steuerungsebene. Sie beschreiben, was der Agent tun kann, daher liest das Modell sie eher als Orientierung denn als zu prüfende Daten. Diese Position verschafft ihnen Hebel über Auswahl und Planung, selbst wenn jeder spätere Schritt gut kontrolliert ist.
Die eigene Grenze ist wichtig, weil sich die Kontrollen unterscheiden: Registry-Integrität, Katalogprüfung, Änderungskontrolle und aufgabenbezogene Tool-Freigabe wirken vor dem Aufruf, Ergebnisprovenienz und erneute Autorisierung danach.
Tool-Metadaten und Tool-Output
| Merkmal | MCP-Tool-Metadaten-Injection | Tool-Output-Injection |
|---|---|---|
| Eintritt in den Kontext | Vor dem Aufruf, bei Discovery oder Katalogaufbau | Nach einem Aufruf, wenn das Ergebnis zurückkommt |
| Träger | Namen, Beschreibungen, Schemas, Annotationen, Server-Instruktionen | Zurückgelieferter Ergebnisinhalt |
| Typischer Einfluss | Tool-Auswahl, Planform, Deutung einer Fähigkeit | Nächster Planschritt, nächster Aufruf, Zusammenfassung |
| Zentrale Kontrollen | Registry-Integrität, Katalogprüfung, Freigabe je Aufgabe, Änderungskontrolle | Ergebnisprovenienz, Feldminimierung, erneute Autorisierung |
Tool-Output-Injection beginnt nach einem Tool-Aufruf und betrifft das, was der Aufruf zurückliefert. Dieser Artikel betrifft die Beschreibung eines Tools, bevor irgendetwas aufgerufen wird. Ein Server kann beide Flächen bieten, und beide brauchen eigene Kontrollen: Tool-Metadaten sind kein Tool-Output.
Abgrenzung und verwandte Klassen
| Klasse | Bestimmender Mechanismus | Beziehung |
|---|---|---|
| MCP-Tool-Metadaten-Injection | Vom Server gelieferte modellsichtbare Metadaten beeinflussen Auswahl, Planung oder Deutung | Der hier behandelte Träger und die Grenze |
| AI-Agent-Prompt-Injection | Eingeschleuster Einfluss in einem Agenten wird zur Aktion | Breitere Klasse auf Systemebene; Metadaten-Injection ist ein Eintrittspfad |
| Tool-Output-Injection | Zurückgelieferter Ergebnisinhalt beeinflusst spätere Schritte | Gegenstück nach dem Aufruf |
| Kompromittierter oder bösartiger MCP-Server | Die Komponente oder ihre Lieferkette ist unterwandert | Ein Weg, auf dem Metadaten feindlich werden; nicht gleichbedeutend |
| Manipulation der Tool-Auswahl | Die Wahl des Tools wird gesteuert | Eine Wirkung oder ein Schritt; Metadaten-Injection kann ein Mechanismus sein |
| Autorisierungsschwächen in MCP | Schwächen bei OAuth, Token oder Scopes | Eigene Autorisierungsklasse; kann Auswirkungen verstärken |
Metadaten können ohne Kompromittierung problematisch sein: Ein Betreiber formuliert übertreibende Beschreibungen, ein harmloser Server ist unglücklich formuliert oder zwei Server überschneiden sich. Umgekehrt kann ein kompromittierter Server weit mehr als Metadaten verändern. Getrennte Klassen halten Befunde präzise.
Das MCP-Flächenmodell
MCP verbindet KI-Anwendungen mit Servern, die Tools, Ressourcen und Prompts bereitstellen. Der Host ist die KI-Anwendung; er betreibt einen oder mehrere Clients, die jeweils mit einem Server verbunden sind. Der Host entscheidet, welches vom Server gelieferte Material dem Modell gezeigt wird, in welcher Form und neben welchen Anwendungsanweisungen.
Der Server ist hier standardmäßig als nicht vertrauenswürdig markiert, weil sein natürlichsprachlicher Inhalt keine Anwendungsautorität ist, auch wenn seine Identität feststeht. Die Revision 2026-07-28 ändert Transport- und Sitzungsaspekte, etwa einen zustandslosen Kern, einen optionalen Discovery-Aufruf und cachebare Listenergebnisse. Wie ein bestimmter Host den Kontext zusammensetzt, bleibt implementierungsabhängig und muss je Host und Version geprüft werden.
Felder einer Tool-Definition
Bezeichner und Anzeigenamen. Strukturell ein Bezeichner, inhaltlich auch eine Aussage über den Zweck.
Freie natürliche Sprache. Die offizielle SDK-Dokumentation beschreibt sie als für das Modell sichtbar, sie kann also Auswahl und Nutzung prägen.
Struktur und Typen der Argumente. Feldbeschreibungen im Schema sind wiederum natürliche Sprache.
Sofern vorhanden, die erwartete Struktur der Ergebnisse; relevant für die Ergebnisverarbeitung, nicht für die Auswahl.
Verhaltenshinweise wie nur lesend oder destruktiv. Behauptungen, keine Durchsetzung.
Strukturelle Felder lassen sich deterministisch prüfen: Typen, Pflichtfelder, erlaubte Werte. Natürlichsprachliche Felder lassen sich nicht auf dieselbe Weise inhaltlich validieren. Ein Schema beschreibt die gültige Struktur von Argumenten; es erteilt keine Erlaubnis, einen Aufruf auszuführen.
Server-Instruktionen
Server können Instruktionen liefern, wie ihre Tools am besten genutzt werden. Hinweise der MCP-Maintainer halten fest, dass Hosts diese in den System-Prompt einfügen können, die genaue Behandlung aber beim Implementierer liegt und je Client geprüft statt vorausgesetzt werden sollte. Dieselben Hinweise empfehlen, Instruktionen für Nutzer sichtbar zu machen und sie prüfen, aktivieren oder deaktivieren zu lassen.
Tool-Annotationen sind Hinweise
Annotationen wie readOnlyHint, destructiveHint, idempotentHint und openWorldHint sind Hinweise. Der Artikel der MCP-Maintainer zu Annotationen hält fest, dass Annotationen das Tool-Verhalten nicht garantiert zutreffend beschreiben und Clients sie als nicht vertrauenswürdig behandeln müssen, sofern sie nicht von einem vertrauenswürdigen Server stammen. Ein nicht vertrauenswürdiger Server kann sie schlicht falsch angeben.
| Verwendung | Sinnvoll | Nicht sinnvoll |
|---|---|---|
| Benutzeroberfläche | Eine behauptete Risikostufe anzeigen | Die Behauptung als geprüft darstellen |
| Bestätigungsdialoge | Bei pessimistischem Hinweis häufiger nachfragen | Bei optimistischem Hinweis auf Bestätigung verzichten |
| Richtlinie | Als schwaches Signal eines vertrauenswürdigen Servers nutzen | Unabhängige Aktionsklassifizierung oder Autorisierung ersetzen |
| Eindämmung | Die Prüfung informieren | Sandboxing oder Netzwerkkontrollen ersetzen |
Eine Annotation beschreibt behauptetes Verhalten. Sie belegt nicht das tatsächliche Verhalten und ist keine Durchsetzung.
Discovery und Registrierung versus Autorisierung
Discovery teilt einem Client mit, was ein Server anbietet. Registrierung oder Onboarding nimmt einen Server in die Menge dessen auf, was ein Host nutzen darf. Laufzeitautorisierung entscheidet, ob ein bestimmter Principal jetzt eine bestimmte Operation auf einer bestimmten Ressource ausführen darf. Das sind drei Schritte mit unterschiedlichen Verantwortlichen und unterschiedlicher Evidenz.
Drei getrennte Fragen
| Frage | Evidenz | Was sie nicht beantwortet |
|---|---|---|
| Ist das der Server, den wir erwarten? | Transportsicherheit, Serveridentität, Autorisierungsablauf | Ob sein Text vertrauenswürdig oder maßgeblich ist |
| Kann man sich auf diese Metadaten stützen? | Provenienz, Prüfung, fixierte Version, Fingerprint | Ob ein bestimmter Aufruf erlaubt ist |
| Darf diese konkrete Aktion ausgeführt werden? | Deterministische Autorisierung, gebunden an Principal, Operation, Ressource und Parameter | Ob der Server ehrlich über sein Verhalten ist |
Server-Authentifizierung stellt Serveridentität und Transportvertrauen her, keine inhaltliche Anweisungsautorität. Die Revision 2026-07-28 härtet die MCP-Autorisierung, etwa durch Issuer-Validierung und Client-Metadatendokumente; das verbessert die erste Frage und lässt die zweite und dritte unverändert.
Auswahl, Aufruf und Ergebnis
| Phase | Was Metadaten beeinflussen können | Wo die Kontrolle hingehört |
|---|---|---|
| Auswahl | Welches Tool der Planner bevorzugt | Freigabe je Aufgabe, Auswahlrichtlinie, Katalogprüfung |
| Aufruf | Wie Argumente gefüllt und gedeutet werden | Schemavalidierung plus deterministische Autorisierung des konkreten Aufrufs |
| Ergebnis | Indirekt, wie Ergebnisse eingeordnet werden | Ergebnisprovenienz und erneute Autorisierung (Tool-Output-Injection) |
Die Modellausgabe bleibt in jeder Phase ein Vorschlag. Eine auffällige Auswahl ist ein Signal, aber für sich noch keine Sicherheitsauswirkung.
Modellsichtbare Darstellung
Nur Metadaten, die tatsächlich in den Modellkontext gelangen, können das Modell direkt beeinflussen. Hosts unterscheiden sich: Manche zeigen die vollständigen Beschreibungen aller verbundenen Tools, manche filtern oder fassen zusammen, manche laden Tool-Definitionen erst bei Bedarf, manche zeigen Server-Instruktionen und manche nicht. Befunde für einen Host lassen sich daher nicht automatisch auf einen anderen übertragen.
Harmlose synthetische Beispiele
Die Beispiele verwenden fiktive Server und neutrale Formulierungen. Sie enthalten keine wiederverwendbaren Beschreibungen oder Payloads.
Ein neu registrierter fiktiver Server search.example.test bietet zwei Such-Tools mit überlappendem Zweck; eine Beschreibung behauptet, sie solle immer bevorzugt werden.
Das Aufgabenprofil erlaubt nur das geprüfte Tool docs-search, daher wird das übertreibende Tool für diese Aufgabe unabhängig von seiner Beschreibung nicht angezeigt.
Ein weiteres Tool ist als nur lesend annotiert. Der Host behandelt die Annotation als nicht vertrauenswürdig und klassifiziert die Operation vor der Autorisierung selbst.
Server-Instruktionen schlagen einen breiteren Arbeitsablauf vor. Die Anwendung behält die Aufgabe des authentifizierten Nutzers und die deterministische Richtlinie als Grundlage.
Zwischen zwei Läufen ändert sich der Katalog-Fingerprint von tools.internal.example.test. Das neu beschriebene Tool bleibt bis zur Prüfung nicht verfügbar.
Registry-Integrität und Provenienz
Integritätskontrollen vor der Freigabe
- Serveridentität, Herkunft und Betreiber für jeden verbundenen Server festhalten.
- Paket, Image, Konfiguration oder Endpunkt fixieren, soweit das Bereitstellungsmodell es erlaubt.
- Eine geprüfte Momentaufnahme der Tool-Definitionen und Server-Instruktionen je Serverversion aufbewahren.
- Trennen, wer einen Server hinzufügen darf und wer seine Tools nutzen darf.
- Metadaten eines neu verbundenen oder geänderten Servers bis zur Prüfung als ungeprüft behandeln.
Provenienz zeigt, woher Metadaten stammen. Bekannte Herkunft ist keine Anweisungsautorität; sie unterstützt Prüfung und Zuordnung. Siehe Datenprovenienz.
Dynamische Kataloge und Änderungskontrolle
Tool-Kataloge können sich ändern: Server fügen Tools hinzu, entfernen oder formulieren sie um, und MCP unterstützt Benachrichtigungen über Listenänderungen. Die Revision 2026-07-28 ergänzt Listenergebnisse um Cache-Hinweise und eine deterministische Reihenfolge, damit Clients Kataloge zwischenspeichern können. Caching ist eine Performance-Funktion; es entscheidet nicht, ob eine geänderte Definition akzeptabel ist.
- 01Fingerprint
Jede Tool-Definition und jede Instruktionsmenge so hashen, wie sie dem Modell gezeigt wird.
- 02Diff
Bei jeder Aktualisierung mit der zuletzt geprüften Version vergleichen.
- 03Zurückhalten
Neue oder wesentlich geänderte Tools für geschützte Workloads bis zur Prüfung nicht freigeben.
- 04Protokollieren
Festhalten, welche Katalogversion jeder Lauf tatsächlich genutzt hat.
Minimierung von Fähigkeiten und Freigabelisten je Aufgabe
Je weniger ein Modell sieht, desto weniger können Metadaten es beeinflussen. Geben Sie nur die Tools frei, die ein Aufgabenprofil braucht, und nur von Servern, die für dieses Profil zugelassen sind. Ein Tool, das für eine Aufgabe nicht im modellsichtbaren Katalog steht, kann für sie nicht über seine eigene Beschreibung ausgewählt werden.
Minimierung legt auch fest, welche Fähigkeiten überhaupt existieren sollten; diese Frage behandelt Least Privilege.
Deterministische Autorisierung jedes Aufrufs
Eingaben der Aufrufautorisierung
- Initiierender Principal und Agenten- oder Workload-Identität
- Tool- und Serveridentität wie registriert, nicht wie beschrieben
- Operationsklasse, bestimmt vom Host, nicht von der Annotation
- Zielressource und Parameter nach der Validierung
- Beteiligtes Ziel und beteiligte Daten
- Aufgabenumfang und aktuelle Berechtigungen
Laufzeit- und nachgelagerte Autorisierung bleiben außerhalb des Modells. Metadaten können einen Vorschlag wahrscheinlicher machen; sie können einen nicht autorisierten Aufruf nicht erlauben. Siehe Agentenautorisierung.
Auswirkungen begrenzen
Enge Scopes und Zugangsdaten für jede Serververbindung.
Erreichbarkeit je Workload, unabhängig von Tool-Behauptungen.
Begrenzen, worauf ein lokaler Server oder ein Tool zugreifen kann.
Entscheiden, ob bestimmte Daten zu einem Tool oder Ziel fließen dürfen.
Bestätigung für folgenreiche Operationen mit klarer Sicht auf die konkrete Aktion.
Keine dieser Kontrollen ist eine vollständige MCP-Lösung. Jede begrenzt einen anderen Teil der Folgen. Siehe Netzwerk- und Egress-Beschränkungen, Sandboxing / Eindämmung, Informationsflusskontrolle und Human-in-the-Loop.
Erkennung und Telemetrie
- 01Serveridentität und Version
Welcher Server, welcher Betreiber und welche fixierte Version verbunden war.
- 02Registry- und Katalogversion
Katalog-Fingerprint und Diff gegenüber dem zuletzt geprüften Stand.
- 03Modellsichtbare Momentaufnahme
Die Metadaten, die der Host tatsächlich in den Kontext geschrieben hat.
- 04Vorgeschlagenes Tool
Welches Tool und welche Argumente das Modell vorgeschlagen hat.
- 05Autorisierungsentscheidung
Zulassen oder Ablehnen mit Begründungscode und Richtlinienversion.
- 06Ausführungsergebnis
Ob der Aufruf übermittelt und ausgeführt wurde und mit welcher Wirkung.
Detektoren können anweisungsähnliche Formulierungen in Beschreibungen markieren, wie unter Prompt-Injection-Erkennung beschrieben. Protokolle zeigen Korrelation, keine Kausalität im Modell: Eine geänderte Beschreibung, gefolgt von einer geänderten Auswahl, ist Evidenz für eine Untersuchung, kein Beweis, dass das eine das andere verursacht hat. Sequenzanalysen wie die Tool-Chain-Analyse helfen, wenn sich die Auswahl über mehrere Schritte verschiebt.
Hinweise für die Vorfallsreaktion
Begrenzte Reaktionsschritte
- Den betroffenen Server oder Katalogeintrag für die betroffenen Workloads deaktivieren oder unter Quarantäne stellen.
- Metadaten-Momentaufnahmen, Versionen, Konfiguration und Fingerprints sichern, bevor sie geändert werden.
- Läufe ermitteln, die die betroffene Katalogversion genutzt haben.
- Läufe mit geänderter Auswahl von Läufen mit autorisierten, ausgeführten Wirkungen trennen.
- Zugangsdaten nur rotieren, wenn Evidenz Offenlegung, Nutzung oder Kontrollverlust stützt.
- Die versagte Grenze reparieren; neue Prompt-Formulierungen reichen nicht, wenn eine deterministische Kontrolle versagt hat.
Siehe Incident Response für den übergreifenden Prozess.
Kontrolliertes Testen
Testen Sie mit synthetischen MCP-Servern und fiktiven Tool-Definitionen in einer isolierten Umgebung, ohne echte Aktionen bei Dritten. Messen Sie Ergebnisse getrennt statt als einzelnes Bestanden oder Nicht bestanden.
| Messgröße | Frage |
|---|---|
| Aufnahme in den Katalog | Wurde die Testdefinition dem Modell überhaupt gezeigt? |
| Einfluss auf die Auswahl | Haben sich Auswahl oder Plan gegenüber einer Baseline verändert? |
| Nicht autorisierter Vorschlag | Hat das Modell einen Aufruf außerhalb des Aufgabenumfangs vorgeschlagen? |
| Ergebnis der Autorisierung | Wurde der Vorschlag abgelehnt oder hat eine Kontrolle versagt? |
| Ausgeführte Wirkung | Wurde etwas ausgeführt und eine Ressource verändert? |
Siehe Adversariales Testen zu Autorisierung und Umfang von Testprogrammen.
Häufige Missverständnisse
| Missverständnis | Richtigstellung |
|---|---|
| Ein authentifizierter Server hat vertrauenswürdige Beschreibungen | Authentifizierung belegt Identität, keine inhaltliche Autorität. |
| Eine Nur-lesen-Annotation bedeutet, dass das Tool nur liest | Annotationen sind Behauptungen; Operationen unabhängig klassifizieren. |
| Ein gültiges Schema bedeutet, dass der Aufruf erlaubt ist | Schemas beschreiben Struktur, keine Berechtigung. |
| Die Registrierung eines Servers verleiht seine Fähigkeiten | Registrierung macht Beschreibungen sichtbar; Autorisierung erlaubt Aktionen. |
| Das ist dasselbe wie Tool-Output-Injection | Metadaten wirken vor dem Aufruf, Output danach. |
| Eine geänderte Auswahl beweist einen Vorfall | Modelleinfluss ist keine Sicherheitsauswirkung. |
Standards und Quellen
Einordnung in Frameworks
- MCP
- Spezifikation 2026-07-28 (Protokollkontext)
- OWASP
- LLM01:2026 Prompt Injection, Top 10 for Agentic Applications
- NIST
- AI 100-2e2025
OWASP und NIST liefern den breiteren Kontext zu Prompt Injection und Agenten. Sie definieren diese MCP-spezifische Kategorie nicht. MCP-spezifische Aussagen in diesem Artikel stützen sich auf offizielle Seiten der MCP-Spezifikation, Artikel der Maintainer und SDK-Dokumentation.
Die wichtigsten Punkte
Zusammenfassung
- Modellsichtbare Metadaten sind variabler Inhalt, auch über einen gültigen Protokollaustausch.
- Server-Authentifizierung ist keine inhaltliche Anweisungsautorität.
- Schemas beschreiben Struktur; Annotationen beschreiben behauptetes Verhalten.
- Discovery und Registrierung sind keine Autorisierung.
- Auswahl, Aufruf und Ergebnis sind getrennte Phasen mit getrennten Kontrollen.
- Modelleinfluss ist keine Sicherheitsauswirkung; Tool-Metadaten sind kein Tool-Output.
Zum breiteren Aktionspfad siehe AI-Agent-Prompt-Injection und AI Agents und Tool Calling.
FAQ
Ist MCP-Tool-Metadaten-Injection eine offizielle MCP-Schwachstellenkategorie?
Nein. Es ist ein beschreibender Begriff dieser Website. Verwandte Begriffe wie Tool Description Poisoning finden sich in Forschung und Community.
Löst die Autorisierung in MCP 2026-07-28 das Problem?
Nein. Die gehärtete Autorisierung verbessert Identität und Token-Behandlung. Sie macht natürlichsprachliche Metadaten nicht maßgeblich.
Sollten Hosts Annotationen ignorieren?
Hosts können sie als schwache Hinweise nutzen, vor allem von vertrauenswürdigen Servern, dürfen sich zur Durchsetzung aber nicht auf sie verlassen.
Setzt das einen kompromittierten Server voraus?
Nein. Auch übertreibende oder unglücklich formulierte Metadaten eines nicht kompromittierten Servers können die Auswahl beeinflussen. Kompromittierung ist ein Weg, nicht die Definition.
Wie hängt das mit indirekter Prompt Injection zusammen?
Es teilt das Kernproblem, dass externer Text in den Modellkontext gelangt, beschrieben unter Indirekte Prompt Injection, wirkt aber auf den Katalog statt auf Aufgabendaten.
Quellen
- The 2026-07-28 SpecificationModel Context Protocol Blog · Technical documentation · 2026-07-28Geprüft 2026-09-27
- Tools (Specification 2026-07-28)Model Context Protocol · Standard · 2026-07-28Geprüft 2026-09-27
- Tool Annotations as Risk Vocabulary: What Hints Can and Can't DoModel Context Protocol Blog · Guidance · 2026-03-16Geprüft 2026-09-27
- Server Instructions: Giving LLMs a user manual for your serverModel Context Protocol Blog · Guidance · 2025-11-03Geprüft 2026-09-27
- MCP TypeScript SDK v2 documentationModel Context Protocol · Technical documentationGeprüft 2026-09-27
- LLM01:2026 Prompt InjectionOWASP · StandardGeprüft 2026-09-27
- Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations, NIST AI 100-2e2025NIST · Standard · 2025-03Geprüft 2026-09-27