Leitfrage und Entscheidungsgrenze

Welche Protokollversion, Transporte und optionalen Capabilities unterstützt ein konkreter Client tatsächlich und nachweisbar?

Die Übersicht trennt den offenen Standard von der jeweils tatsächlich implementierten Produktunterstützung.

Architektur und Verantwortlichkeiten

MCP ist der Standard; Produkte implementieren jeweils einen Ausschnitt. Der Host erzeugt Clientinstanzen und entscheidet über Tooldarstellung, Freigaben, Sampling, Elicitation und Roots. Server dürfen optionale Funktionen nur verwenden, wenn sie in der Sitzung ausgehandelt wurden.

Analytische Methode

Die Matrix nennt Clientversion, Betriebssystem, Protokollversion, Transport, Authmodell und jede Capability mit Testdatum. Marketingangaben werden von reproduzierten Tests getrennt. Der aktuelle produktive Standard bleibt bis zur finalen Veröffentlichung einer Nachfolgeversion 2025-11-25; ein Release Candidate ist keine Current-Spezifikation.

  • Protokollversion
  • stdio und Streamable HTTP
  • Tools, Ressourcen und Prompts
  • Sampling, Elicitation und Roots
  • Autorisierung und Erweiterungen

Travel-Fallstudie

Ein Server darf Elicitation nicht voraussetzen, wenn der verwendete Travel-Client diese Capability nicht aushandelt; der Prozess benötigt dann einen alternativen Eingabekanal.

Das Beispiel gilt erst dann als belastbar, wenn Quellen, Zustände, Rechte und Fehlerpfade genauso konkret dokumentiert sind wie der gewünschte Normalfall.

Typische Fehlkonstruktionen

Eine statische Ja/Nein-Tabelle veraltet schnell und verschweigt Einschränkungen. Toolunterstützung kann etwa vorhanden sein, während strukturierte Ergebnisse, Icons oder Elicitation fehlen. Ebenso kann ein Client lokale stdio-Server, aber keine geschützten Remote-Server unterstützen.

Erforderliche Evidenz

Jeder Eintrag verweist auf Primärdokumentation oder einen reproduzierbaren Test mit Client- und Serverversion. Unbekannt ist eine zulässige Antwort. Produktnamen allein reichen nicht, weil Varianten und Rolloutkanäle abweichen können.

Messgrößen und Abnahmekriterien

Erfasst werden erfolgreiche Initialisierung, Capability-Abdeckung, Schema- und Ergebnisdarstellung, Freigabeverhalten, Authfehler, Regressionen und Zeit bis zur Unterstützung neuer Current-Spezifikationen.

Ergebnis und weiterführende Analyse

Eine versionierte Prüfliste hilft, Architekturannahmen gegen konkrete Clients zu testen.

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.