Der MCP Contract spielt für KI-Agenten-Tools dieselbe Rolle wie ein OpenAPI-Contract für eine REST-API — eine einzige, maschinenlesbare Quelle der Wahrheit. Der Unterschied liegt darin, was diese Quelle der Wahrheit bringt: jedes Mal auf dieselbe Weise bewertet, sodass das Ergebnis als Nachweis dient, nicht als Momentaufnahme.
Ein MCP Contract funktioniert aus demselben Grund wie ein OpenAPI-Contract — alle hören auf, über unterschiedliche Versionen der Wahrheit zu streiten, und arbeiten stattdessen mit einer einzigen. Sicherheitsteams erhalten eine präzise, versionierte Deklaration dessen, was ein Server offenlegt und erlaubt, statt einer Wiki-Seite oder eines Slack-Threads. Der aufrufende KI-Agent erhält das, was einer Ground Truth darüber, wofür ein Tool tatsächlich gedacht ist, am nächsten kommt. Und weil der Contract maschinenlesbar ist, ist die Bewertung dagegen deterministisch: derselbe Server, zweimal bewertet, liefert denselben Score, dieselben Befunde und dasselbe Urteil — genau das macht aus einer Governance-Entscheidung einen Audit-Nachweis statt einer Momentaufnahme-Meinung.
Die Bewertung erfolgt gegen den deklarierten Contract, nicht gegen die Einschätzung eines Menschen an einem bestimmten Tag. Bewerten Sie einen Server zweimal, erhalten Sie zweimal dieselbe Antwort.
Ein deterministisches Urteil ist etwas, das Sie einem Regulator oder einer Kunden-Sicherheitsprüfung vorlegen können — kein Dashboard-Screenshot mit Zeitstempel.
Weil der Contract strukturiert ist, kann ein Security Quality Gate einen nicht konformen Server automatisch blockieren — niemand muss daran denken, ihn zu überprüfen.
Dasselbe Contract-Modell steuert zehn MCP-Server oder zehntausend, ohne dass die Governance-Qualität von der Disziplin einzelner Teams abhängt.
Der Contract muss nicht von Hand geschrieben werden. Verbinden Sie sich mit einer beliebigen Live-MCP-Server-URL, und der Discovery-Durchlauf generiert den Contract automatisch — jedes Tool, jede Ressource und jeden Prompt, den der Server bereitstellt, sowie bestmögliche Ableitungen für Risikostufe, Datenklassifizierung und Nebenwirkungen.
Alles, was sich nicht sicher ableiten lässt, wird als # STUB markiert statt geraten — sodass ein Mensch die Lücke bewusst schließt, anstatt ein falsches Gefühl von Vollständigkeit zu veröffentlichen.
Das Schema ist bewusst so aufgebaut, dass Freitextbeschreibungen — der Teil, den ein KI-Modell tatsächlich liest — in einem eigenen Abschnitt stehen, getrennt von den strukturellen Deklarationen, die Sicherheitsteams prüfen. Die strukturellen Abschnitte definieren das Schema, gegen das die 42Crunch-Plattform auditiert und bewertet.
contentDas vollständige description-Feld jedes Tools und Prompts — hinzugefügt in Schemaversion mcpContract: "0.2" neben dem bestehenden gekürzten title. Das ist es, was ein aufrufendes KI-Modell tatsächlich liest, und genau das analysiert die 42Crunch-Plattform automatisch auf Prompt Injection, Tool Poisoning, Data Exfiltration und Tool Shadowing.
server | Name, Version, Reverse-DNS-Identität |
initialize | Anweisungen an den aufrufenden Agenten |
integrity | Nachrichtensignierung, Rug-Pull-Schutz |
resolution | Audit-Invarianten |
capabilities | Tools, Ressourcen, Prompts und deren Risikostufen |
authentication | Schemata, Fail-Closed-Standardeinstellungen |
authorization | Rollen, Ablehnung von Wildcard-Freigaben |
throttling | Ratenbegrenzungen, Fail-Closed-Verhalten |
Das ist dieselbe Idee, die einen OpenAPI-Contract wertvoll macht — nur angewandt auf eine neue Art von Konsument.
Eine präzise, versionierte Deklaration dessen, was Ihr MCP-Server erlaubt und was nicht — die Grundlage für Governance, automatisierte Tests und ein CI/CD-Gate, das nicht davon abhängt, dass jemand daran denkt, einen Pull Request zu überprüfen.
Der Contract ist das, was einem KI-Modell am nächsten an eine Ground Truth darüber kommt, wofür ein Tool tatsächlich gedacht ist. Ein gut geschriebener, gehärteter content-Abschnitt ist das, was zwischen einem aufrufenden Agenten und einer Tool-Beschreibung steht, die versucht, ihn zu manipulieren.
Traffic-basierte Erkennung zeigt, was passiert ist; ein Contract zeigt, was erlaubt ist — sodass ein Sicherheitsteam einen Server testen und blockieren kann, bevor er überhaupt von einem Agenten aufgerufen wird, statt nur zu protokollieren, was ein Agent bereits getan hat.
Weil die Beweislast eine andere ist — ein Regulator oder Prüfer benötigt ein Ergebnis, das sich nicht danach ändert, wann man gefragt hat. Ein deterministisches, contractbasiertes Urteil ist reproduzierbar; ein Live-Traffic-Risikoscore ist es in der Regel nicht.
Nein — er ist die Deklaration, auf der die Laufzeit-Durchsetzung aufbaut. Der Contract legt fest, was erlaubt ist; eine Laufzeitschicht (MCP Runtime Protection) ist das, was einen Server, der davon abweicht, tatsächlich blockiert.
Sie werden als # STUB markiert statt stillschweigend geraten, sodass ein Mensch die Lücke bewusst schließt — der Contract beansprucht nie mehr Vollständigkeit, als er tatsächlich hat.