MCP-Tool-Schemata ändern: Prüfung vor der Ausführung
Prüfen Sie Änderungen an MCP-Tool-Schemata vor der Ausführung: fachliche Bedeutung, freigegebene Verträge, wartende Anfragen und unklare Ergebnisse.
Die Änderungskontrolle für MCP-Tool-Schemata muss erkennen, wenn der Werkzeugname gleich bleibt, sich aber Argumente, Beschreibung oder fachliche Wirkung verändern. Eine aktualisierte Werkzeugliste ist nur der erste Schritt. Vergleichen Sie die neue Definition mit dem freigegebenen Vertrag, prüfen betroffene Berechtigungen und Tests und entscheiden anschließend, ob bestehende Clients und wartende Anfragen das veränderte Werkzeug verwenden dürfen.
Dieser Artikel richtet sich an Gateway- und Integrationsteams, die MCP-Werkzeuge über Versionswechsel hinweg betreiben. Er beschreibt ein Kontrollmuster auf Anwendungsebene und keine zusätzliche MCP-Protokollpflicht. Im Beispiel erhält ein internes Werkzeug zur Entwurfserstellung einen Empfängerparameter. Auch ein optionaler Parameter kann durch seinen Standardwert verändern, wohin Informationen gelangen. Seine formale Optionalität sagt deshalb wenig über die fachlichen Auswirkungen aus.
Werkzeugerkennung und Freigabe getrennt behandeln
Die MCP-Werkzeugspezifikation beschreibt Werkzeugerkennung, Eingabeschemata und Benachrichtigungen über Listenänderungen. Eine Benachrichtigung weist auf eine veränderte Werkzeugliste hin. Sie belegt nicht, dass eine geänderte Geschäftsoperation freigegeben wurde. Auch Werkzeugannotationen müssen angemessen auf Vertrauenswürdigkeit geprüft werden. Allein die Tatsache, dass ein Server sie liefert, macht sie nicht zu einer belastbaren Erlaubnis.
Verwenden Sie einen freigegebenen Registereintrag mit Serveridentität, Werkzeugdefinition, Konnektorversion und verantwortlicher Person. Die neu erkannte Definition bleibt zunächst ein beobachteter Kandidat, bis die relevanten Prüfungen abgeschlossen sind. Ist die Erkennung nicht verfügbar, gilt die dokumentierte Aktualitätsregel der Bereitstellung. Ein fehlender Metadatenabruf darf nicht unbemerkt dazu führen, dass ein Werkzeug weitergehendes Verhalten erhält oder unbekannte Argumente akzeptiert.
Fachliche Bedeutung zusätzlich zur JSON-Struktur vergleichen
Ein Schemavergleich kann neue Eigenschaften, geänderte Typen und andere Pflichtfelder erkennen. Er ermittelt jedoch nicht jede fachliche Folge. Ein Zeichenkettenfeld kann dasselbe Schema behalten und trotzdem statt einer internen Referenz eine beliebige URL bedeuten. Eine Beschreibung kann zu einer weitergehenden Aktion auffordern, ohne dass sich die Struktur überhaupt verändert. Solche Änderungen verlangen eine eigene inhaltliche Prüfung.
| Änderung | Warum sie wichtig ist | Nachweis vor der Annahme |
|---|---|---|
| Neues optionales Ziel | Ein Standardwert kann Daten außerhalb der erlaubten Grenze leiten | Ausdrücklicher Standardwert, Zielprüfung und negative Fälle |
| Erweiterte Werteliste | Zusätzliche Operationen oder Ressourcen werden auswählbar | Aktualisierte Zuordnung der Befugnisse und geprüfter Fachumfang |
| Entferntes Pflichtfeld | Eine bisher ausdrückliche Einschränkung wird möglicherweise implizit | Definiertes Verhalten bei Auslassung und entsprechende Tests |
| Geänderte Beschreibung | Die Werkzeugauswahl des Modells kann sich ändern | Prüfung der Anweisungen und repräsentative Auswahltests |
| Neues Ausgabeschema | Nachgelagerte Systeme können Status oder Kennungen falsch verstehen | Vertragstests mit den empfangenden Komponenten |
| Gleiches Schema, neue Wirkung | Strukturelle Kompatibilität verdeckt eine betriebliche Änderung | Nachweise zur Konnektorversion und Beobachtung des Zielsystems |
Bewerten Sie Kompatibilität in zwei Dimensionen. Ein Client kann eine Anfrage weiterhin erfolgreich verarbeiten, obwohl die Aktion unter der bisherigen Befugnis unzulässig geworden ist. Umgekehrt kann ein zusätzliches Anzeigefeld eine Clientanpassung verlangen, ohne Berechtigungen zu erweitern. Halten Sie beide Schlussfolgerungen getrennt fest. Ein einziges Kästchen „kompatibel“ reicht für diese unterschiedlichen Fragen nicht aus.
Den für eine Anfrage freigegebenen Vertrag festhalten
Ordnen Sie einer Anfrage den Werkzeugvertrag zu, unter dem sie vorbereitet und autorisiert wurde. Erkennt der Ausführungspfad einen anderen Vertrag, muss er nach einer ausdrücklichen Regel stoppen oder neu bewerten. So vermeiden Sie eine Lücke zwischen Prüfung und Verwendung: Die Anfrage wird gegen eine bestimmte Bedeutung freigegeben, aber möglicherweise unter einer anderen Bedeutung ausgeführt.
Die Bindung kann eine stabile Versionskennung und eine Prüfsumme über eine vereinbarte Serialisierung verwenden. Definieren Sie enthaltene Felder und Berechnung. Eine Prüfsumme beweist nicht, dass der Server die Definition tatsächlich umsetzt. Für dieses Kontrollmuster bleiben Tests am Zielsystem, beschränkte Zugangsdaten und eine kontrollierte Konnektorbereitstellung erforderlich. Der Vertrag und das beobachtete Verhalten müssen zusammenpassen, nicht lediglich dieselbe Kennung tragen.
Entscheiden Sie für wartende Anfragen, ob sie unter dem bisherigen Konnektor beendet, abgebrochen oder erneut vorbereitet und freigegeben werden. Ersetzen Sie die Vertragsreferenz nicht einfach im vorhandenen Datensatz. Bewahren Sie die alte Anfrage und den Grund für eine neue Anfrage auf. Dadurch bleibt nachvollziehbar, welche Entscheidung sich auf welche Aktion bezog und weshalb eine erneute Prüfung nötig wurde.
Zuerst eine harmlose Schemaänderung testen
Erstellen Sie zwei synthetische Versionen eines Entwurfswerkzeugs. Version eins akzeptiert Fallreferenz und Text. Version zwei erlaubt zusätzlich ein Ziel, jedoch ohne impliziten externen Standardwert. Bereiten Sie eine Anfrage gegen Version eins vor und wechseln vor der Ausführung auf Version zwei. Erwartet wird ein sichtbarer Vertragskonflikt oder eine ausdrücklich freigegebene Migration, keine stillschweigende Annahme der alten Anfrage.
Übermitteln Sie danach ein unbekanntes Feld, ein Ziel außerhalb der erlaubten Menge und einen Wert, der zwar dem JSON-Typ entspricht, aber die fachliche Einschränkung verletzt. Diese Versuche trennen Schemavalidierung von Autorisierung. Ein gültiges JSON-Dokument ist keine Erlaubnis, auf einen bestimmten Kunden, ein bestimmtes System oder einen bestimmten Datensatz einzuwirken. Beide Prüfungen brauchen deshalb eigene erwartete Ergebnisse.
Lassen Sie schließlich eine geänderte Ausgabe den Status „abgeschlossen“ durch „angenommen, noch offen“ ersetzen. Der aufrufende Client darf die Annahme durch den Anbieter nicht als Abschluss behandeln. Dieser Versuch findet eine andere Fehlerklasse als eine ungültige Eingabe. Er gehört dennoch in dieselbe Migrationsprüfung, weil ein falsches Verständnis des Ergebnisses zusätzliche Aktionen oder unzutreffende Nachweise auslösen kann.
Auf eine unerwartete Änderung reagieren
Wird ein Vertrag unerwartet verändert, sperren Sie zunächst das betroffene Werkzeug für die relevante Nutzung. Deaktivieren Sie nicht ohne Prüfung alle unabhängigen Abläufe. Unterscheiden Sie vorbereitete, wartende und bereits übermittelte Anfragen. Laden Sie die Definition vom vertrauenswürdigen Server neu, vergleichen sie mit dem freigegebenen Stand und klären, ob die Änderung berechtigt, versehentlich oder nicht vertrauenswürdig ist.
Wiederholen Sie bereits übermittelte Operationen nicht nur deshalb, weil der Client das Ergebnis nicht lesen konnte. Fragen Sie das Zielsystem nach Möglichkeit über eine stabile Operationsreferenz ab. Bewahren Sie die Rohantwort geschützt auf und dokumentieren den Interpretationsfehler. Ein Parserfehler lässt den fachlichen Ausgang unklar. Er beweist nicht, dass die Operation ohne Wirkung geblieben ist oder gefahrlos erneut ausgeführt werden darf.
Die Prüfung für den nächsten Wechsel nutzbar machen
Der Änderungsdatensatz sollte betroffene Clients, Befugnisregeln, Evaluierungsfälle und Rollback-Grenzen nennen. Benennen Sie eine Person, die die fachliche Bedeutung erklären kann. Liegt lediglich ein Schemavergleich vor, kennzeichnen Sie die semantische Prüfung als unvollständig. Fehlende Informationen sind keine Belege für Unbedenklichkeit. Diese Unterscheidung sollte auch im Freigabestatus der Änderung erkennbar bleiben.
Führen Sie nach der Annahme eine kleine kontrollierte Menge repräsentativer Anfragen aus und untersuchen den Zustand des empfangenden Systems. Bewahren Sie den bisherigen Vertrag zur Interpretation älterer Nachweise auf. Das bedeutet nicht zwingend, dass das alte Werkzeug weiter ausführbar bleiben muss. Die Aufbewahrung der Definition und die Verfügbarkeit einer ausführbaren Version sind unterschiedliche Lebenszyklusentscheidungen.
Die Vorlage ist vollständig, wenn sie beobachtete Metadaten, freigegebenen Vertrag und bereitgestelltes Verhalten unterscheidet und eine abweichende Anfrage einen geprüften Ausgang hat. So wird Änderungskontrolle für eine reale Bereitstellung nutzbar. Benachrichtigungen über neue Werkzeuge werden dadurch nicht zu automatischen Änderungen der Entscheidungsbefugnisse.
Vorlage und ergänzende Umsetzungsleitfäden nutzen
Nutzen Sie den übergeordneten Leitfaden für die umfassendere Architektur und wenden Sie diesen Artikel auf eine klar begrenzte Umsetzung an. Die ergänzenden Artikel behandeln verwandte Entscheidungen, ohne diese Vorlage zu ersetzen.
Bearbeitbare Vorlage herunterladen. Nächster Schritt.
Technischer Entwurf vom 18. Oktober 2026. Primärquellen wurden an diesem Datum geprüft; die fachliche Prüfung steht noch aus. Die Vorlagen beschreiben vorgeschlagene Tests, keine gemessenen Kundenergebnisse. OATI bleibt eine Entwicklervorschau. Lokale Implementierungsnachweise belegen keine unabhängige Prüfung, Kundenabnahme oder Produktionsreife einer konkreten Bereitstellung.