MCP-2.0-Konformität

MCP Fusion verwendet standardmäßig die Protokollrevision 2026-07-28 und führt ein schriftliches Verzeichnis der Abkündigungen, denn ein Protokoll, das sich unter Ihrem Server verändert, ist ein Betriebsrisiko. Diese Seite ist die Konformitätsübersicht: was implementiert ist, was entfernt wurde und was das Framework nicht zulässt.

Strukturierte Inhalte

ToolResponse führt das MCP-2.0-Feld structuredContent neben dem Textinhalt. successStructured(data) setzt beides: das maschinenlesbare Objekt und einen JSON-Textblock für ältere Clients. Kombinieren Sie es mit .withOutputSchema(schema), um den Ausgabevertrag in der Tool-Definition zu veröffentlichen. Beachten Sie, dass Presenters die unter Wire format dokumentierte Textform erzeugen; structuredContent ist der parallel geparste Kanal, keine Presenter-Ausgabe.

Anfragen mit mehreren Hin- und Rückläufen

Das 2025 eingeführte, vom Server gestartete Anfragemodell funktioniert in serverlosen Umgebungen nicht. Die Antwort von 2026 basiert auf Rückgaben: Ein Handler gibt zurück, dass er Eingaben benötigt, der Client erfüllt die Anforderung und tritt erneut ein. MCP Fusion stellt dies als requireInput(), readInput(), die Felddeskriptoren ask.* und .interactive() bei einem Tool bereit, alles dokumentiert unter Streaming and cancellation. Der Treiber unterstützt beide Epochen: Bei einer Verbindung von 2026 gibt das Framework die Antwort mit erforderlicher Eingabe unverändert aus und das SDK steuert den erneuten Versuch; bei einer persistenten Verbindung von 2025 erfüllt es die Anfrage selbst über den aktiven Kanal; ohne Kanal wird der Aufruf zu ELICITATION_UNSUPPORTED herabgestuft und die Schleife ist begrenzt.

Listen-Cache (SEP-2549)

Listenergebnisse können Cache-Metadaten für jeden Proxy vor Ihrem Konnektor enthalten. Konfigurieren Sie ihn einmal:

attachToServer(server, {
  listCacheTtlMs: 300_000,   // default: 5 minutes
  listCacheScope: 'private', // or 'public' for shared data
});

Die Metadaten werden gemäß dem Layout dieser Revision an der Ergebniswurzel unter tools/list, prompts/list, resources/list und resources/templates/list abgelegt. Wenn Sie listCacheTtlMs auf null setzen, werden sie ohne zusätzlichen Aufwand entfernt. Dies ist ein Protokoll-Cache der Liste und nicht die Tool-Ebene-Signalisierung der Veraltung unter State sync.

Versiegelung des Request-Zustands (SEP-2322)

Wenn ein Server den Fortsetzungszustand über einen Client hin- und herleitet, darf dieser Zustand nicht fälschbar sein. Stellen Sie beim Start einen Schlüssel bereit:

startServer(registry, {
  transport: 'http',
  requestStateKey: process.env.REQUEST_STATE_KEY,  // 32 bytes or more
});

sealRequestState(payload) erstellt anschließend ein versiegeltes HMAC-SHA256-Token mit Ablaufzeit, und der Server prüft jeden eingehenden versiegelten Zustand, bevor er erneut in einen Handler eintritt. Ohne Schlüssel fällt das Framework auf einfache JSON-Serialisierung zurück und markiert den Zustand in der Dokumentation als nicht vertrauenswürdig: sicher für eine nicht sensible Fortsetzung, nicht für Identität.

Header-Routing und x-mcp-header

Der zustandslose Transport routet Anfragen über die Header Mcp-Method und Mcp-Name statt über eine Sitzung. Dadurch kann jede Instanz hinter einem Round-Robin-Load-Balancer jeden Aufruf bedienen. Ein Parameter kann außerdem in einen HTTP-Header gespiegelt werden: .withHeaderParam('tenant', 'X-Tenant') versieht das Schema mit x-mcp-header, und der Client sendet ihn als Mcp-Param-X-Tenant, sodass die Infrastruktur ohne das Parsen von Bodies routen kann. Auf diese Weise veröffentlichte Parameter dürfen keine Geheimnisse sein; das Framework löst bei einem leeren Header-Namen einen Fehler aus und dokumentiert die Token-Beschränkung der RFC 9110.

Änderungsbenachrichtigungen

Vier Listen- und Ressourcenereignisse sind verdrahtet: notifications/tools/list_changed (FSM-Übergänge, Handoff, Hot Reload), notifications/prompts/list_changed, notifications/resources/updated und notifications/resources/list_changed. In MCP 2.0 registriert der Stream subscriptions/listen einen Filter und bestätigt ihn, sodass sich ein Client einmal anmeldet und nur die angeforderten Ereignisklassen erhält.

Das Verzeichnis der Abkündigungen

Die Abkündigungspolitik ist stilistisch ehrlich: Funktionen ohne serverseitige Bedeutung fehlen einfach, nicht empfohlene Funktionen warnen bei der Validierung, und entfernte Funktionen sind verschwunden, statt stillschweigend eingeschränkt zu werden. Das veröffentlichte Entfernungsfenster für die abgekündigte Menge endet am 2027-07-28.

Artefakte für die Discovery

Unter http und stateless antwortet der Server auf /.well-known/mcp/server-card.json mit einer Serverkarte: Schema-URL, Version, Protokollversion, Serverinformationen, Transport (streamable-http mit Endpunkt /mcp oder stdio), deklarierte Fähigkeiten und Tool-Einträge. Sie wird einmal beim Start kompiliert und mit einem öffentlichen Cache-Header von fünf Minuten ausgeliefert. Lesen Sie die Interna unter Introspection.

Vom SDK behandelte Fehlercodes

Die Revision definiert Protokollcodes für eine Header-Abweichung, eine fehlende erforderliche Client-Fähigkeit und eine nicht unterstützte Protokollversion. Sie werden von der SDK-v2-Serverschicht unterhalb des Frameworks ausgegeben; der eigene Fehlervertrag des Frameworks ist der unter Errors dokumentierte <tool_error>-Umschlag.

Nächste Schritte

• Runtime architecture: die Transporte in der Praxis
• Introspection: Serverkarte und Manifest
• Streaming and cancellation: MRTR im Detail