Initialisierung als obligatorischer Zustandsübergang
Der Client eröffnet mit initialize und nennt protocolVersion, clientInfo und ClientCapabilities. Der Server antwortet mit einer unterstützten Version, serverInfo, ServerCapabilities und optional instructions. Vor Abschluss sind nur eng begrenzte Nachrichten zulässig. Die initialized-Notification bestätigt anschließend die Betriebsbereitschaft.
Implementierungen sollten diesen Ablauf als expliziten Automaten modellieren. Ein boolesches initialized reicht oft nicht, weil Timeout, inkompatible Version und vorzeitiger Disconnect unterscheidbare Endzustände erzeugen. Zustandsübergänge gehören in Unit- und Integrationstests.
Versionsaushandlung
Der Client bietet seine bevorzugte unterstützte Version. Der Server bestätigt sie oder antwortet mit einer anderen unterstützten Version. Kann der Client diese nicht sprechen, beendet er die Verbindung. Eine automatische Interpretation unbekannter Versionen als kompatibel wäre ein Protokollfehler.
Protokollversion, Serverpaketversion und Tool-Vertragsversion sind drei unabhängige Achsen. Sie sollten separat in Telemetrie und Supportmatrix erscheinen. Ein Serverupdate kann Tools ändern, ohne die MCP-Protokollversion zu wechseln.
Client- und Server-Capabilities
ClientCapabilities können Roots, Sampling, Elicitation und Tasks ankündigen; ServerCapabilities unter anderem Tools, Ressourcen, Prompts und Logging. Untereigenschaften wie listChanged, subscribe oder Taskoperationen präzisieren die Unterstützung.
Capabilities sind positiv: Nicht angekündigte Funktionen gelten als nicht verfügbar. Experimentelle Felder benötigen Namensräume und dürfen stabile Features nicht stillschweigend verändern. Ein Server sollte seine effektiven Fähigkeiten aus Konfiguration und Nutzerkontext ableiten können.
Betriebsphase, Cancellation und Progress
In der Betriebsphase laufen Requests, Responses und Notifications parallel. Progress Tokens korrelieren Fortschrittsmeldungen, Cancellation signalisiert Abbruchwünsche. Ein Abbruch ist kooperativ: Der Empfänger muss definieren, welche Arbeit noch läuft und welche Nebenwirkung bereits eingetreten ist.
Für schreibende Operationen braucht der Fachstatus Vorrang vor dem Transportstatus. Ein abgebrochener Request kann eine Backendtransaktion bereits ausgelöst haben. Der Client muss den tatsächlichen Zustand abfragen können.
Shutdown und Wiederverbindung
Bei stdio wird der Prozess kontrolliert beendet; bei HTTP können Sitzungen über DELETE beendet werden, wenn der Server dies unterstützt. Ein Server darf Sessions terminieren, worauf ein Client nach 404 neu initialisieren muss.
Wiederverbindung darf keinen impliziten fachlichen Retry auslösen. Capability-Listen werden neu ausgehandelt, weil Deployment, Rechte oder Serverkonfiguration sich geändert haben können.
FAQ zu MCP-Lebenszyklus und Capability Negotiation
Warum ist Capability Negotiation notwendig?
Weil optionale Protokollfunktionen nicht von jeder Implementierung unterstützt werden und ihr Einsatz ohne Aushandlung zu undefiniertem Verhalten führen würde.
Sind instructions verbindlich?
Nein. Sie sind Hinweise für den Client beziehungsweise das Modell und keine Autorisierungs- oder Sicherheitskontrolle.
Primärquellen und wissenschaftliche Einordnung
Die Darstellung folgt der versionierten MCP-Spezifikation. Normative Anforderungen werden von Architektur- und Betriebsempfehlungen getrennt; experimentelle Funktionen sind entsprechend gekennzeichnet.