MCP testen & betreiben: Verträge, Änderungen & Rollouts

Ein erreichbarer Server ist noch keine funktionierende Integration

Ein erfolgreicher Health-Check beweist nur, dass ein Prozess antwortet. Eine MCP-Integration muss darüber hinaus Request-Metadaten, Discovery, Tool-Schemas, Fehlersemantik und die lokale Host-Policy zusammen einhalten. Ein Server kann HTTP-200 liefern und trotzdem ein Tool mit geändertem Pflichtargument veröffentlichen, eine nicht angeforderte Notification senden oder eine unerwartete Wirkung anbieten.

Betrieb bedeutet deshalb nicht, einzelne Tool-Calls gelegentlich gegen Produktion zu klicken. Behandle den beobachtbaren MCP-Vertrag als Release-Artefakt: Was darf ein bestimmter Host mit diesem Server verhandeln, entdecken, anzeigen und ausführen? Tests und Rollout-Gates vergleichen genau diese Grenze mit einer bewussten Erwartung.

Versioniere erwartete Verträge nicht als manuell gepflegte Screenshots, sondern als prüfbare Artefakte: normalisierte Discovery-Antwort, Schemadigests, erlaubte Clientprofile, Policyklassifikation und wenige kanonische Beispiele. Flüchtige Felder wie Beschreibungskorrekturen können separat bewertet werden; wirkungsrelevante Änderungen blockieren standardmäßig. Das Gate zeigt einen menschenlesbaren Diff und die maschinenlesbare Ursache. Damit lässt sich ein bewusst akzeptierter Wandel aktualisieren, ohne Drift einfach wegzugolden. Prüfe auch den Testcode selbst im Review, denn eine zu breite Erwartung kann einen Vertragsbruch unsichtbar machen. Reproduzierbare Serverkonfiguration und feste Testdaten sorgen dafür, dass derselbe Stand lokal und in CI dieselbe Grenze zeigt.

Der Vertrag hat mehrere Schichten

Protokoll

Version, _meta, Nachrichtenform und Transport verhalten sich vereinbarungsgemäß.

Capability

Optionale Funktionen werden nur bei passender Request-Deklaration verwendet.

Discovery

Serveridentität, Tools, Resources und Prompts haben erwartete Verträge.

Host-Policy

Entdeckte Fähigkeiten werden erst nach lokaler Prüfung sichtbar oder ausführbar.

Fachwirkung

Ein erlaubter Aufruf liefert korrekte Ergebnisse und erzeugt nur die erwarteten Seiteneffekte.

Nicht jede Schicht gehört in denselben Test. Ein Server kann seine Tool-Liste allein testen; ein Host muss zusätzlich prüfen, dass er neue Angebote nicht automatisch aktiviert. Ein Ende-zu-Ende-Test gegen ein echtes Testsystem zeigt Transport und Berechtigungen, sollte aber kein Ersatz für schnelle, deterministische Vertragsprüfungen sein.

Ordne Tests nach der billigsten Schicht, die den Fehler zuverlässig findet. JSON-Schema und Serialisierung laufen pro Commit. Server- und Host-Contract-Tests verwenden deterministische Fixtures. Authentisierung, Proxy und echte Backends werden in einer kontrollierten Umgebung geprüft. Last, Chaos und Canary folgen später, weil sie teurer und weniger deterministisch sind. Ein höherer Test ersetzt die unteren nicht: Ein End-to-End-Fall kann zufällig grün sein, obwohl ein ungetesteter Schemaast gebrochen ist. Jeder Befund nennt verletzte Invariante, verantwortliche Schicht und reproduzierbare Eingaben. So bleibt die Suite schnell genug für Entwickler und tief genug für Releaseentscheidungen.

Interoperabilitäts- und Contract-Tests prüfen die gemeinsame Sprache

Ein versionierter Interoperabilitäts- und Contract-Test ist nicht bloß ein Happy-Path-Call wie tools/call. Er prüft eine erwartete Interaktion von Client und Server: Protokollversion und Client-Capabilities pro Request senden, server/discover und Capability-Listen lesen, korrekte Requests bilden und Fehler ohne stilles Umdeuten behandeln. So werden Annahmen sichtbar, die ein SDK lokal kaschieren kann. Das Testartefakt gehört zur unterstützten Integration.

Prüfe negative Fälle bewusst: Ein Host darf eine nicht annoncierte Capability nicht aufrufen; ein Server darf kein ungültiges Argument als andere Aktion auslegen. Solche Tests testen die Grenze, nicht die Bequemlichkeit eines einzelnen Entwicklungsstands.

Fixture und echte Integration haben verschiedene Aufgaben

Ein deterministischer Fixture-Server liefert festgelegte Capability-Profile, Tool-Listen, Antworten und kontrollierte Fehler. Er macht Host-Tests reproduzierbar: Ein Test kann gezielt eine nicht unterstützte Capability, eine geänderte Liste oder ein ungültiges Schema erzeugen, ohne auf Netzwerk, Datenbestand oder einen fremden Release-Zeitpunkt zu warten.

Fixture-Server

Schnelle, reproduzierbare Host- und Policy-Tests mit gezielten Protokollfällen.

Eigener Server-Contract-Test

Prüft das veröffentlichte Angebot des Servers gegen eine versionierte Erwartung.

Reale Integration

Prüft Transport, Authentisierung, Infrastruktur und fachliche Testdaten unter kontrollierten Bedingungen.

Ein Fixture ist kein Simulator der gesamten Welt und kein Produktionsersatz. Reale Integrationsprüfungen bleiben nötig, aber ihre Instabilität darf nicht die einzige Rückmeldung für Host-Logik sein. Halte Daten und Antworten der Fixture absichtlich klein, nachvollziehbar und frei von Geheimnissen.

Eine gute Fixture kann gezielt fehlerhafte Antworten erzeugen: falsche JSON-RPC-ID, unbekanntes resultType, abgelaufener Cursor, nicht schema-konformes structuredContent, input_required ohne passende Client-Capability, verspätete Nachricht nach Cancellation und unterbrochener Subscription-Stream. Sie besitzt eine virtuelle Uhr für TTL und Deadline und liefert dieselbe Sequenz bei gleichem Seed. Hosttests beweisen dadurch nicht nur Annahme gültiger Daten, sondern kontrollierte Ablehnung und Wiederherstellung. Halte Fixture-Profile wie öffentliche Testvektoren versioniert. Wenn ein Produktionsincident einen neuen Protokollrandfall zeigt, entsteht zuerst ein reproduzierendes Profil und danach der Fix.

Capabilities sind eine Matrix, keine Checkbox

MCP-Fähigkeiten sind optional und Client-Capabilities gelten für den konkreten Request. Ein Host kann mit lokalen stdio-Servern, entfernten HTTP-Servern, mehreren Protokollrevisionen und unterschiedlichen Capability-Kombinationen arbeiten. Ein einziger Referenzserver beweist deshalb nicht, dass alle unterstützten Profile funktionieren.

Achse

Beispiel für eine Testvariante

Transport

Lokaler Prozess oder entfernter HTTP-Dienst

Version

Unterstützte Revision oder kontrollierte Ablehnung

Client-Capability

Elicitation oder andere Option im Request vorhanden beziehungsweise nicht vorhanden

Serverangebot

Tools, Resources, Prompts und Subscription-Typen

Policy

Capability entdeckt, aber lokal nicht freigegeben

Die Matrix muss nicht kartesisch explodieren. Wähle repräsentative Profile nach Risiko: jede unterstützte Transport- und Capability-Grenze mindestens einmal, besonders die Kombinationen mit Berechtigung, dynamischer Discovery oder Seiteneffekt. Was nicht getestet wird, sollte auch nicht als verlässlich unterstützt gelten.

Verwende Pairwise-Auswahl für unabhängige Achsen und vollständige Kombinationen dort, wo Risiken interagieren. Ein wirkendes Tool über HTTP mit OAuth, MRTR und Responseverlust verdient mehr Tiefe als ein öffentlicher statischer Prompt. Halte ausdrücklich Profile ohne optionale Features bereit; Hosts scheitern oft, weil der Referenzserver alles unterstützt. Teste zwei parallele Requests mit verschiedenen Client-Capabilities über dieselbe Verbindung, damit kein Sessiondenken unbemerkt zurückkehrt. Jede unterstützte Version besitzt ein End-of-Support-Datum und einen Migrationspfad. Entfernt das Produkt ein Profil, wird auch sein Fixture und seine Produktionskonfiguration kontrolliert abgebaut.

Paginierte Discovery ist erst am letzten Cursor vollständig

tools/list kann paginiert sein. Eine Antwort mit nextCursor ist daher kein vollständiger Tool-Contract, sondern nur ein Fragment. Ein Host oder Contract-Test folgt jedem Cursor, bis keine nächste Seite mehr kommt, und bildet erst dann den Snapshot, der gegen erwartete Tools, Schemas und Policy geprüft werden darf.

Teste Pagination unter Veränderung und Berechtigungswechsel. Eine Fixture kann auf Seite zwei einen neuen Eintrag erzeugen, einen Snapshot ablaufen lassen oder einen Cursor für einen anderen Principal zurückspielen. Der Server muss seine dokumentierte Semantik halten und darf den Cursor nie als Berechtigung akzeptieren. Caches werden mit ttlMs und cacheScope geprüft: jede Seite besitzt eigene Hinweise, und eine frische Seite verspricht keinen konsistenten Gesamtsnapshot. Subscription-Notifications invalidieren betroffene Annahmen; nach Streamverlust wird erneut aus der Quelle gelesen. Contract-Tests unterscheiden daher Vollständigkeit eines einzelnen Durchlaufs, Frische eines Cacheeintrags und Änderungszustellung. Diese drei Begriffe zu vermischen erzeugt besonders schwer reproduzierbare Produktionsdrift.

Der Output gehört ebenfalls zum Tool-Contract

Ein inputSchema begrenzt nur den Call. Deklariert ein Tool zusätzlich ein outputSchema, ist auch die Ergebnisform Teil des veröffentlichten Vertrags: Der Server liefert konformes structuredContent, und der Host prüft es, bevor Code oder nachgelagerte Policy darauf baut. Freitext kann hilfreicher Modellkontext sein, ersetzt aber keine fehlenden Pflichtfelder.

Discovery-Test

Findet Tool und deklarierte Schemas über alle Seiten hinweg.

Positiver Output-Test

Prüft ein konformes structuredContent gegen das Output-Schema.

Negativer Output-Test

Beweist, dass Host und Downstream einen absichtlich verletzten Contract nicht still akzeptieren.

Freitext

Kann Erklärung liefern, ist aber keine maschinenprüfbare Ersatzstruktur.

Damit prüfst du einen anderen Fehler als bei Tool-Auswahl oder Eingabevalidierung: Ein Server kann einen gültigen Call empfangen und trotzdem ein Ergebnis liefern, das den eigenen veröffentlichten Output-Contract verletzt. Diese Grenze muss vor der probabilistischen Interpretation durch ein Modell greifen.

Generiere aus jedem Schema Grenzwerte und Gegenbeispiele: fehlende Pflichtfelder, zusätzliche Eigenschaften, falsche Typen, leere und maximale Arrays, Unicode, große Zahlen und verschachtelte Grenzen. Ergänze fachliche Invarianten, die JSON Schema nicht ausdrückt, etwa existierende IDs oder zulässige Statusübergänge. Bei MRTR wird jede inputResponse gegen die ursprüngliche Anforderung und den gebundenen requestState geprüft. Doppelte Wiederaufnahme darf keine zweite Wirkung erzeugen. Speichere reale Produktionspayloads nur redigiert und mit klarer Herkunft als Regressionstest; frei erfundene Fixtures allein übersehen häufig die ungewöhnlichen Kombinationen echter Clients.

Kompatibilität braucht eine explizite Ausfallentscheidung

Bei einer unbekannten oder inkompatiblen Serveränderung gibt es keine universell richtige Reaktion. Für Zahlungs-, Identitäts- oder Schreibtools ist Fail-Closed oft angemessen: nicht aktivieren und Nutzer transparent informieren. Für rein lesende, klar begrenzte Funktionen kann ein kontrollierter, vorher getesteter Fallback auf eine bekannte Capability-Version vertretbar sein.

Definiere die Regel vor dem Incident: welche Versionen und Vertragsformen werden unterstützt, wer gibt neue Formen frei, wann wird eine alte Fähigkeit deaktiviert und welche Nutzerkommunikation begleitet einen Fallback? Ein erneuter Call mit geratenen Parametern ist kein Fallback, sondern ein neuer unkontrollierter Vertrag.

Erstelle eine Kompatibilitätstabelle pro Capability statt nur pro Serverversion. Ein neues Release kann Reads kompatibel halten und ein einzelnes Schreibtool brechen. Der Host deaktiviert dann gezielt die unbekannte Wirkung, während getestete Pfade weiterlaufen. Vertrag-Diffs klassifizieren hinzugefügte Tools, gelockerte Inputs, geänderte Outputs, neue Scopes, andere Datenziele und semantische Beschreibung. Automatische Klassifikation beschleunigt Review, entscheidet aber bei hoher Wirkung nicht allein. Nutzerhinweise nennen konkret, welche Funktion fehlt und ob Daten oder bestehende Vorgänge betroffen sind. Ein Fallback darf weder breitere Rechte noch geratenes Feldmapping verwenden.

Traces erklären den Protokollpfad, ohne Daten weiterzugeben

Bei einer Incident-Analyse müssen Host-Request, Server, Tool-Name, Protokollprofil und Ergebnis zusammenfinden. Eine korrelierte Trace-Kette beantwortet, welcher Principal welchen Tool-Call auslöste, welche Request-Capabilities galten und an welcher Grenze ein Fehler entstand. Sie ist keine Einladung, Prompts, Tool-Argumente, Tokens oder vollständige Ressourcendaten dauerhaft zu speichern.

Sinnvoll korrelieren

Zeit, Server-Identität, Request-Kennung, Tool-Name, Vertrags- oder Policy-Version, Ergebnis-Klasse.

Redigieren oder minimieren

Authorization-Header, Tokens, Secrets, personenbezogene Tool-Argumente, Resource-Inhalte und vollständige Modellkontexte.

Zugriff begrenzen

Nur Incident- und Betriebsrollen erhalten zeitlich und organisatorisch begrenzten Diagnosezugriff.

Teste die Telemetrie wie eine Schnittstelle. Für einen synthetischen Request muss genau eine korrelierbare Kette entstehen; für zwei parallele Nutzer dürfen Attribute nicht vertauschen. Fehler-, Timeout-, Cancellation- und unbekannte Fachausgänge erhalten unterschiedliche Statuswerte. Metriklabels bleiben begrenzt und enthalten keine Request-ID. Ein markiertes Testsecret darf weder Logexport noch Tracebackend erreichen. Simuliere Ausfall des Telemetrie-Collectors: Der MCP-Datenpfad darf nicht blockieren, doch verlorene Signale werden als eigene Betriebsstörung sichtbar. Aufbewahrung und Zugriff werden mit denselben Fixtures regelmäßig geprüft wie Funktionalität.

Ein Release braucht fachliche Gates und einen Rückweg

Ein Deployment ist erst dann sicher ausgerollt, wenn die veröffentlichte Capability-Oberfläche und ihre Freigaben geprüft sind. Stufe die Einführung: erst Contract- und Fixture-Tests, dann eine kontrollierte Umgebung mit Permission-Diff, anschließend begrenzte Aktivierung und beobachtbare Rückrollentscheidung. Eine grüne Container-Readiness ersetzt keinen dieser Schritte.

Der Rückweg kann ein vorheriges Server-Release, eine Host-Policy, die ein Tool ausblendet, oder die Trennung eines problematischen Servers sein. Entscheidend ist, dass er vor dem Incident getestet ist und keine veraltete Registry oder unbekannte Capability weiterverwendet.

Ein Canary definiert Population, Dauer, Erfolgsmetriken und automatisches Stoppsignal vor dem Start. Er nutzt kontrollierte Principals und begrenzt reale Wirkung. Beobachte neben HTTP-Fehlern Contract-Verletzungen, Policy-Ablehnungen, Tail-Latenz, Kontextmenge, doppelte Wirkungen und neue Egressziele. Feature Flags trennen Serverdeployment von Capability-Aktivierung. Beim Rollback wird geprüft, ob laufende Jobs, Caches und Schemaänderungen mit dem alten Stand verträglich sind. Nach erfolgreicher Promotion bleibt der Vertragsfingerabdruck Teil kontinuierlicher Driftüberwachung; Releaseprüfung ist kein einmaliger Freibrief.

Die acht Betriebsgrenzen im Check

• Vertrag prüfen: Fähigkeiten und Fehlerpfade vor dem Release sichtbar machen.
• Änderung begrenzen: Discovery niemals mit Aktivierung verwechseln.
• Betrieb erklären: Nur die nötigen Metadaten korrelieren und einen getesteten Rückweg behalten.

Vor Freigabe müssen neun Beweise auffindbar sein: unterstützte Request-Profile, vollständiger Discovery-Snapshot, Schema- und Negativtests, MRTR- und Cancellation-Races, Autorisierungsfälle, Lastgrenzen, Telemetrie-Redaction, Capability-Diff und geprobter Rückweg. Jeder Beweis besitzt Owner, Version und Erstellungszeit. Ein rotes Gate wird nicht durch einen Kommentar überstimmt, sondern durch eine dokumentierte, zeitlich begrenzte Risikoentscheidung mit Kompensation. Nach einem Incident wird der reproduzierende Fall in die passende Schicht der Suite aufgenommen. So wächst die Prüfung mit realer Erfahrung, ohne jede Regression nur als langsamen End-to-End-Test abzubilden.

Pflege eine Evidenzmatrix, die jede Produktionsinvariante mit Test, Metrik und Reaktion verbindet. „Keine Doppelwirkung“ besitzt einen Paralleltest mit gleichem Idempotency-Key, eine Deduplizierungsmetrik und einen Incident-Runbookschritt. „Keine Cross-Tenant-Sicht“ besitzt Negativtests für Read, Liste, Cache und Stream sowie einen Alarm auf Policyverletzung. „Keine unbekannte Capability“ besitzt Discovery-Diff und Host-Allowlist-Gate. Dadurch ist sichtbar, welche Zusage nur getestet, welche kontinuierlich beobachtet und welche im Vorfall eindämmbar ist. Lücken werden bewusst priorisiert. Ein grünes Release bedeutet dann nicht Fehlerfreiheit, sondern belegte Grenzen und einen vorbereiteten Umgang mit den verbleibenden Risiken.