Füge die tools/list-Antwort eines MCP-Servers ein und prüfe die Qualität seines Katalogs: Kontextkosten, annotations, instructions und Konformität mit der offiziellen Registry. Das ist kein Zugriffssicherheits-Auditor und kein Live-Debugger — sieh in der Hilfe nach, was das ist und was nicht.
Bedienungsanleitung
Was das prüft
Füge die tools/list-Antwort eines MCP-Servers ein —deiner, oder irgendeiner— und prüfe die Qualität des Katalogs: fehlende Beschreibungen und annotations, Tools, deren Name auf Schreiben oder Löschen hindeutet, während ihre annotations das Gegenteil sagen, Kontextkosten pro Tool, ob das Feld instructions des Katalogs gesetzt ist und unter ~2 KB bleibt, und ob eine description eine Anweisung für das Modell versteckt (tool poisoning). Nichts verlässt deinen Browser.
Registry-Manifest (optional)
Füge auch server.json ein und prüfe die eigenen Grenzen der offiziellen MCP-Registry (Feldlängen, das Namespace-Muster) BEVOR sie deine Veröffentlichung mit einem 422 oder einem 403 ablehnt —die zwei Fehler, die wir schon beim Veröffentlichen unserer eigenen Pakete erlitten haben. Füge package.json hinzu, um zusätzlich eine Versionsabweichung zwischen beiden zu erwischen, die die Registry mit einem 400 ablehnt, nachdem du dich bereits authentifiziert hast.
Tool poisoning
Eine Tool kann eine versteckte Anweisung tragen: für dich unsichtbar —du siehst nur den Namen— aber für das Modell VOLLSTÄNDIG sichtbar (realer Fall: Invariant Labs, "MCP Tool Poisoning Attacks", April 2025 — eine add-Tool mit einem <IMPORTANT>-Tag, das darum bat, ~/.ssh/id_rsa zu lesen und in einen Parameter einzuschleusen). Es wird in der description und im ganzen Schema gesucht —Parameternamen, nicht standardmäßige Felder, default, enum, required—, wo CyberArk auch gezeigt hat, dass es sich versteckt (Full-Schema Poisoning), und auch in allem, was kodiert in base64, hex oder %xx ankommt. Es wird nur als «kritisch» markiert, wenn dieselbe Tool bittet, etwas Sensibles zu lesen UND es zu versenden. Und außerdem, «Gibt Anweisungen für eine andere Tool»: eine Beschreibung, die einer Tool eines ANDEREN Servers Bedingungen stellt (das send_email aus Invariants Beispiel). Engine von @seguridad, nicht von dieser Tool.
Rug Pull: der Katalog, der sich später ändert
Ein Server kann dir am Tag der Genehmigung einen harmlosen Katalog zeigen und ihn später ändern: Das Protokoll erlaubt es, im laufenden Betrieb einen neuen Katalog anzukündigen, und viele Clients fragen dich nie wieder. Füge in die optionalen Felder das tools/list ein, das du genehmigt hast, und es wird mit dem heutigen verglichen: neue oder entfernte Tools, Beschreibungen, die jetzt versteckte Anweisungen enthalten, neue Parameter (über die Daten abfließen könnten) und Annotations, die nicht mehr „nur lesen" sagen.
Was das NICHT prüft
Das prüft das DESIGN des Katalogs, nicht die Zugriffssicherheit. Für „Welchen MCP-Servern vertraut dieses Repository, und was dürfen sie tun?" nutze den Auditor für Agentendateien. Zum Live-Debuggen des Protokolls nutze den offiziellen @modelcontextprotocol/inspector von Anthropic. Tool-Namen, die miteinander verwechselbar sind, und unsichere Code-Muster in der QUELLE des Servers werden noch nicht geprüft.
