# MCP testen & betreiben: Verträge, Änderungen & Rollouts > Prüfe MCP-Host- und Serververträge mit reproduzierbaren Fixtures, kontrolliere Capability- und Berechtigungsänderungen und sichere den vollständigen Release-Weg in einer Abschlussmission ab. Track: [MCP Engineering](https://physar.tech/learn/mcp-engineering) Kanonische Fassung: https://physar.tech/learn/mcp-engineering/testing-operations Stand: 2026-07-26 Interaktiver Teil: 10 Checks (nur im Browser) ## MCP testen & betreiben: Der Vertrag bleibt auch nach dem Release gültig ### 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 Initialisierung, ausgehandelte Capabilities, 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 ausgehandelte 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. > **Leitfrage:** Welche Änderung wäre für den Host oder Nutzer gefährlich, obwohl der Server technisch gesund wirkt? ### Der Vertrag hat mehrere Schichten | | | | --- | --- | | Protokoll | Initialisierung, Version, Nachrichtenform und Transport verhalten sich vereinbarungsgemäß. | | Capability | Optionale Funktionen werden nur nach Aushandlung angeboten und genutzt. | | Discovery | Tools, Resources und Prompts haben erwartete Namen, Schemas und Beschreibungen. | | 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. > **Grenze:** Dieses Modul lehrt MCP-spezifische Vertrags- und Änderungsgrenzen. Allgemeine Retry-Strategien oder Modellqualität bleiben in den jeweiligen Agent- und LLMOps-Modulen. ### 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: initialisieren, nur annoncierte Features verwenden, Discovery lesen, korrekte Requests bilden und Fehler ohne stilles Umdeuten behandeln. So werden Annahmen sichtbar, die ein SDK lokal kaschieren kann. MCP schreibt dafür keinen einzelnen universellen Teststandard vor; das Testartefakt gehört zur unterstützten Integration. Feste Server- und Host-Erwartung beschreiben → Session initialisieren und Capabilities erfassen → **Discovery und Schema gegen Erwartung prüfen** → Erlaubte sowie absichtlich ungültige Requests ausführen → Antwort, Fehler und Notifications dem Vertrag zuordnen → Abweichung als Release-Blocker oder bewusste Änderung behandeln 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. **Kurzcheck:** Ein Health-Check und ein Happy-Path-Tool-Call sind grün. Was muss ein Release-Test zusätzlich beweisen, damit der Host keine nicht ausgehandelte Fähigkeit als leeres Ergebnis verschluckt? - [x] Initialisierung, ausgehandelte Capabilities, vollständige Discovery sowie erlaubte und absichtlich ungültige Requests inklusive Fehlersemantik. - [ ] Den gleichen Happy-Path häufiger gegen Produktion wiederholen. - [ ] Nur die Container-Readiness und Server-CPU beobachten. > Richtig. Der relevante Vertrag enthält Zustandsübergänge und Negativfälle, nicht nur eine erfolgreiche Fachantwort. ### 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. ### Capabilities sind eine Matrix, keine Checkbox MCP-Fähigkeiten sind optional und gelten für die konkrete Session. Ein Host kann mit lokalen `stdio`-Servern, entfernten Streamable-HTTP-Servern und unterschiedlichen Capability-Kombinationen arbeiten. Ein einziger Referenzserver beweist deshalb nicht, dass alle unterstützten Kombinationen funktionieren. | | | | --- | --- | | Achse | Beispiel für eine Testvariante | | Transport | Lokaler Prozess oder entfernter Streamable-HTTP-Dienst | | Rolle | Host- und Server-Capabilities nach Initialisierung | | Feature | Tools, Resources oder Notifications jeweils vorhanden beziehungsweise nicht vorhanden | | 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. ### 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. Erste `tools/list`-Seite lesen → `nextCursor` erkennen und unverändert fortsetzen → Alle Folgeseiten bis zum Ende lesen → **Vollständigen Snapshot bilden** → Namen, Ein- und Ausgabeschemas gegen Erwartung diffen → Ergebnis als Contract-Test bewerten > **Merksatz:** Ein Cursor ist kein Performance-Detail: Er entscheidet, ob dein Test den veröffentlichten Vertrag vollständig gesehen hat. ### 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. ### 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. > **Trade-off:** Fail-Closed begrenzt Schaden, kann Verfügbarkeit senken. Kontrollierte Fallbacks erhalten Funktion, verlangen aber eng getestete und klar begrenzte Alternativen. ### Traces erklären den Protokollpfad, ohne Daten weiterzugeben Bei einer Incident-Analyse müssen Host-Request, MCP-Session, Server, Tool-Name und Ergebnis zusammenfinden. Eine korrelierte Trace-Kette beantwortet, welche Session welchen Tool-Call ausgelöst hat, ob eine Capability ausgehandelt war 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, Session- oder Request-Kennung, Tool-Name, Vertrag- 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. | > **Merksatz:** Traceability erklärt die Herkunft einer Entscheidung; sie darf nicht selbst zum unkontrollierten Datenkanal werden. ### 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. _[Abbildung: Ein Release durchläuft Vertrags-, Freigabe- und Beobachtungs-Gates; bei Abweichung führt ein getesteter Rückweg zurück.]_ Versionierte Vertrags- und Matrix-Tests bestehen → Reale Testintegration mit kontrollierten Identitäten prüfen → **Tool- und Permission-Diff gegen die Freigabe prüfen** → Begrenzte Aktivierung für definierte Hosts oder Nutzer → Korrelierte Fehler- und Änderungsdaten beobachten → Bei Gate-Verstoß auf bekannte Freigabe zurückrollen oder Capability deaktivieren 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 alte Session oder unbekannte Capability weiterverwendet. ### 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. > **Abschluss:** Damit endet der Engineering-Track: Ein MCP-System bleibt nur dann integrierbar, wenn seine Schnittstellen auch unter Veränderung überprüfbar und kontrollierbar bleiben. ## Quellen - modelcontextprotocol.io/specification/2025-11-25/basic/lifecycle — https://modelcontextprotocol.io/specification/2025-11-25/basic/lifecycle - modelcontextprotocol.io/specification/2025-11-25/server/tools — https://modelcontextprotocol.io/specification/2025-11-25/server/tools - modelcontextprotocol.io/specification/2025-11-25/basic/transports — https://modelcontextprotocol.io/specification/2025-11-25/basic/transports - modelcontextprotocol.io/specification/2025-11-25/architecture — https://modelcontextprotocol.io/specification/2025-11-25/architecture - modelcontextprotocol.io/docs/tutorials/securit…urity_best_practices — https://modelcontextprotocol.io/docs/tutorials/security/security_best_practices - modelcontextprotocol.io/specification/2025-11-…utilities/pagination — https://modelcontextprotocol.io/specification/2025-11-25/server/utilities/pagination - modelcontextprotocol.io/specification/2025-11-25/basic/authorization — https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization