MCP 2026-07-28 Migrationsleitfaden: Zustandslose Server

TL;DR: MCP 2026-07-28 entfernt Sitzungen auf Protokollebene und den verpflichtenden Initialisierungshandshake. Produktionsteams sollten versteckte Sitzungsabhängigkeiten identifizieren, pro Anfrage Protokoll-Metadaten übernehmen, Multi Round-Trip Requests implementieren, Gateway-Richtlinien aktualisieren und das neue Protokoll im Canary-Verfahren testen, bevor das Legacy-Verhalten außer Betrieb genommen wird.

Die am 28. Juli 2026 veröffentlichte Model Context Protocol-Spezifikation führt die größte architektonische Änderung von MCP seit der Unterstützung für Remote-Transport ein.

Das Protokoll nutzt nun einen zustandslosen Request‑Response‑Kern. Der erforderliche Austausch initialize und notifications/initialized entfällt, Mcp-Session-Id wurde entfernt und jede Anfrage trägt die zur Verarbeitung benötigten Protokollinformationen mit.

Die Veröffentlichung führt außerdem Multi Round-Trip Requests, HTTP‑Routing‑Header, cachefähige Listenantworten, strengeres Autorisierungsverhalten, ein Erweiterungs-Framework sowie einen formalen Ausmusterungs‑Lebenszyklus ein. Siehe die offizielle MCP 2026-07-28 Release-Ankündigung und das vollständige Spezifikations‑Changelog für Details auf Protokollebene.

Diese Änderungen erleichtern das Skalieren entfernter MCP‑Server hinter Standard‑HTTP‑Infrastruktur. Sie machen eine bestehende Anwendung nicht automatisch zustandslos.

Ein Produktionsserver kann weiterhin auf In‑Memory‑Workspaces, Sticky Routing, sitzungsgebundene Zugangsdaten, langlebige Streams oder vom Server initiierte Interaktionen angewiesen sein. Dieser Leitfaden konzentriert sich darauf, diese Abhängigkeiten zu finden und zu ersetzen.

Für eine einführende Implementierungsanleitung lies vor der Migration How to Create an MCP Server for Claude Code.

Wer muss migrieren?

Der Aufwand hängt davon ab, wie MCP in deinem System genutzt wird.

Ein lokaler Server, der keinen State über Anfragen hinweg beibehält, benötigt möglicherweise nur ein SDK‑Upgrade und Kompatibilitätstests.

Eine Remote‑Bereitstellung, die Sitzungen, OAuth, Streaming oder serverinitiierte Requests nutzt, benötigt eine gestaffelte Migration.

Was hat sich in MCP 2026-07-28 geändert?

1. Bestehende Implementierung prüfen

Suche vor dem Upgrade in Client, Server, Gateway und Deployment‑Konfiguration nach älteren Protokollannahmen.

Mcp-Session-Id
initialize
notifications/initialized
sessionId
ctx.sessionId
extra.sessionId
sticky_session
sticky-session
elicitation/create
sampling/createMessage
roots/list
resources/subscribe
resources/unsubscribe
logging/setLevel
tasks/result
tasks/list
Last-Event-ID

Beantworte anschließend die folgenden Fragen:

1. Lehnen Server Aufrufe ab, bis die Initialisierung abgeschlossen ist?
2. Wählt eine Session‑ID einen Benutzer, ein Credential, einen Workspace oder eine Konversation aus?
3. Kann eine andere Serverinstanz einen vom ersten gestarteten Workflow fortsetzen?
4. Erfordert der Load Balancer Sitzungsaffinität?
5. Führt ein Tool einen Seiteneffekt aus, bevor es eine Bestätigung anfordert?
6. Parst das Gateway den Body, um Methode oder Tool zu identifizieren?
7. Werden OAuth‑Credentials ohne ihren ausstellenden Authorization Server gespeichert?
8. Hängt der Client von SSE‑Reconnect oder Nachrichten‑Neuzustellung ab?
9. Variieren Tool‑ oder Ressourcenlisten je Verbindung?
10. Welche veralteten Features erhalten noch Produktions‑Traffic?

Entferne Mcp-Session-Id nicht, bevor du verstehst, was die Anwendung dahinter speichert.

Ein Server, der den Header entfernt, aber State im lokalen Speicher behält, kann in der Entwicklung funktionieren und später intermittierend ausfallen, sobald Anfragen über mehrere Instanzen verteilt werden.

2. Verdeckten Sitzungszustand ersetzen

MCP 2026-07-28 entfernt Sitzungen auf Protokollebene, nicht den Anwendungsstate.

State, der über Calls hinweg benötigt wird, sollte eines von drei Mustern nutzen.

Explizite Handles

Gib aus einem Tool ein serverseitig erzeugtes Handle zurück und verlange es in späteren Calls.

{
  "resultType": "complete",
  "content": [
    {
      "type": "text",
      "text": "Workspace created."
    }
  ],
  "structuredContent": {
    "workspaceHandle": "ws_7f93a2"
  }
}

Eine spätere Anfrage übergibt das Handle als gewöhnliches Argument:

{
  "name": "update_workspace",
  "arguments": {
    "workspaceHandle": "ws_7f93a2",
    "status": "approved"
  }
}

So wird die Abhängigkeit im Tool‑Vertrag sichtbar und jede kompatible Serverinstanz kann die Anfrage verarbeiten.

Gemeinsamer Speicher (Shared Storage)

Nutze eine Datenbank, einen verteilten Cache, einen Objektspeicher oder ein dauerhaftes Task‑System, wenn:

• mehrere Worker denselben State benötigen;
• der Workflow einen Neustart überstehen muss;
• der State zu groß für ein Handle ist;
• der Workflow länger als eine einzelne Anfrage dauert;
• transaktionales oder Einmal‑Verhalten erforderlich ist.

Geschütztes requestState

MRTR kann einen undurchsichtigen requestState‑Wert zurückgeben, den der Client beim Retry der ursprünglichen Anfrage spiegelt.

Da der Wert durch den Client läuft, schütze ihn mit einem HMAC oder authentifizierter Verschlüsselung. Binde ihn an den authentifizierten Principal, die ursprüngliche Operation, wichtige Parameter, eine Ablaufzeit und eine Nonce, wenn Wiedergabeschutz erforderlich ist.

Vertraue einem unsignierten requestState niemals allein, weil der Client ihn unverändert zurückgegeben hat.

3. Selbstenthaltende Anfragen und Discovery übernehmen

Moderne MCP‑Anfragen enthalten Protokollkontext in _meta.

Ein Streamable‑HTTP‑Tool‑Call kann so aussehen:

POST /mcp HTTP/1.1
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: search
Content-Type: application/json
Authorization: Bearer <token>
{
  "jsonrpc": "2.0",
  "id": "req-101",
  "method": "tools/call",
  "params": {
    "name": "search",
    "arguments": {
      "query": "stateless MCP migration"
    },
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientInfo": {
        "name": "example-client",
        "version": "2.0.0"
      },
      "io.modelcontextprotocol/clientCapabilities": {
        "elicitation": {}
      }
    }
  }
}

Server, die das neue Protokoll anvisieren, müssen server/discover implementieren, das unterstützte Versionen, Fähigkeiten und Server‑Identität bekanntgibt. Clients können dies vor einer anderen Operation aufrufen oder zur Ermittlung nutzen, ob ein Legacy‑Fallback erforderlich ist.

Lies die offizielle server/discover documentation für den Response‑Vertrag.

TypeScript‑SDK‑Versionsverhandlung

Allein das Upgrade auf das TypeScript‑SDK schaltet einen Client nicht automatisch auf das neue Protokoll.

Ein Client, der das v2‑SDK nutzt, muss explizit opt‑in:

const client = new Client(
  {
    name: "my-client",
    version: "1.0.0"
  },
  {
    versionNegotiation: {
      mode: "auto"
    }
  }
);

await client.connect(transport);

Im automatischen Modus tastet das SDK mit server/discover vor und kann auf den älteren Initialisierungsfluss zurückfallen, wenn es auf einen Legacy‑Server trifft.

Teams, die noch @modelcontextprotocol/sdk v1 nutzen, sollten zuerst die offizielle TypeScript SDK v1‑zu‑v2 Migrationsanleitung befolgen. Teams, die bereits v2 einsetzen, sollten die separate 2026-07-28 Protocol Support‑Anleitung verwenden.

4. Vom Server initiierte Anfragen durch MRTR ersetzen

Frühere MCP‑Implementierungen konnten Requests wie elicitation/create, sampling/createMessage oder roots/list vom Server an den Client senden.

Das neue Protokoll ersetzt dieses Modell durch Multi Round‑Trip Requests.

Der Ablauf ist:

1. Der Client sendet die ursprüngliche Anfrage.
2. Der Server gibt resultType: "input_required" zurück.
3. Der Client sammelt die angeforderten Informationen oder die Freigabe ein.
4. Der Client versucht die ursprüngliche Operation mit einer neuen JSON‑RPC‑ID erneut.
5. Der Retry enthält inputResponses und den ursprünglichen requestState.
6. Der Server schließt die Anfrage ab oder startet eine weitere Runde.

Beispiel‑Response:

{
  "jsonrpc": "2.0",
  "id": "delete-1",
  "result": {
    "resultType": "input_required",
    "inputRequests": {
      "confirm_delete": {
        "method": "elicitation/create",
        "params": {
          "mode": "form",
          "message": "Delete project project_123?",
          "requestedSchema": {
            "type": "object",
            "properties": {
              "confirmed": {
                "type": "boolean"
              }
            },
            "required": ["confirmed"]
          }
        }
      }
    },
    "requestState": "protected-expiring-state"
  }
}

Der Client versucht die ursprüngliche Operation erneut:

{
  "jsonrpc": "2.0",
  "id": "delete-2",
  "method": "tools/call",
  "params": {
    "name": "delete_project",
    "arguments": {
      "projectId": "project_123"
    },
    "inputResponses": {
      "confirm_delete": {
        "action": "accept",
        "content": {
          "confirmed": true
        }
      }
    },
    "requestState": "protected-expiring-state"
  }
}

Eine produktionsreife MRTR‑Implementierung sollte definieren:

• maximale Runden;
• Ablaufzeit des Request‑State;
• Cancel‑ und Ablehnungsverhalten;
• Validierung des Response‑Schemas;
• Autorisierungsprüfungen bei jedem Retry;
• Wiedergabeschutz;
• Idempotenz für Seiteneffekte;
• Verhalten, wenn ein Client die angeforderte Fähigkeit nicht unterstützt.

Vermeide, einen Kauf, eine Löschung, eine Gutschriftabbuchung oder einen externen Schreibvorgang abzuschließen, bevor input_required zurückgegeben wurde.

Nutze eine gestufte Operation oder einen Idempotenz‑Key, damit Retries die Aktion nicht duplizieren können. Siehe die offizielle MRTR‑Spezifikation für das vollständige Interaktionsmodell.

5. Gateways, Caching und Autorisierung aktualisieren

Die Infrastrukturänderungen sind eng miteinander verbunden und sollten gemeinsam getestet werden.

MCP‑Routing‑Header validieren

Streamable‑HTTP‑POST‑Requests enthalten nun:

• MCP-Protocol-Version
• Mcp-Method
• Mcp-Name

Diese Header ermöglichen es Gateways, Traffic zu routen, zu messen, zu autorisieren und zu rate‑limiten, ohne jeden JSON‑Body zu parsen.

Sie können Kontrollen unterstützen wie:

• tool‑spezifische Rate Limits;
• getrennte Richtlinien für List‑ und Ausführungs‑Methoden;
• dedizierte Worker‑Pools für teure Tools;
• eingeschränkten Zugriff auf risikoreiche Operationen;
• Latenz‑ und Fehlermetriken pro Tool;
• Zuordnung von Infrastrukturkosten.

Die Werte werden weiterhin vom Client geliefert. Vergleiche sie mit dem JSON‑RPC‑Body, bevor du Richtlinien anwendest.

Eine Anfrage darf nicht in Mcp-Name ein risikoarmes Tool behaupten, während im Body ein anderes Tool aufgerufen wird. Abweichungen zwischen Header und Body sollten abgelehnt und protokolliert werden.

Autorisierungsbewusste Cache‑Keys verwenden

Das neue Protokoll ergänzt ttlMs und cacheScope für cachefähige Ergebnisse, darunter:

• tools/list
• prompts/list
• resources/list
• resources/templates/list
• resources/read

Ein Cache‑Key sollte in der Regel Folgendes enthalten:

protocol version
server identity
method
request parameters
authenticated principal or tenant
authorization scope
cacheScope
server configuration version

Nutze einen privaten Cache‑Eintrag nicht erneut über Benutzer oder Mandanten hinweg, nur weil die TTL noch nicht abgelaufen ist.

Deterministische Tool‑Reihenfolge ist ebenfalls wichtig. Ein stabiler Katalog vermeidet unnötige Cache‑Misses und kann die Prompt‑Cache‑Wiederverwendung von Modellen verbessern, wenn Tool‑Definitionen in Prompts eingefügt werden.

Umgang mit OAuth‑Issuer stärken

Während der Autorisierungs‑Migration:

• validiere einen zurückgegebenen iss‑Wert gegen den für den Flow erfassten Issuer;
• schlüssel gespeicherte Client‑Credentials nach Issuer;
• verwende Credentials niemals bei einem anderen Authorization Server wieder;
• setze einen passenden application_type während DCR;
• bereite neue Integrationen auf Client ID Metadata Documents vor.

Dynamic Client Registration bleibt zur Rückwärtskompatibilität verfügbar, ist jedoch als bevorzugter Registrierungsansatz veraltet.

6. Benachrichtigungen, Tasks und veraltete Funktionen migrieren

Der ältere HTTP‑GET‑Benachrichtigungspfad sowie resources/subscribe oder resources/unsubscribe wurden durch subscriptions/listen ersetzt.

Clients öffnen einen langlebigen POST‑Response‑Stream und optieren in die benötigten Benachrichtigungskategorien ein. Request‑spezifische Fortschritts‑ und Log‑Benachrichtigungen bleiben an den Response‑Stream der jeweiligen Anfrage angehängt.

Für Multi‑Instanz‑Deployments nutze einen gemeinsamen Event‑Bus, wenn Benachrichtigungen, die auf einer Serverinstanz erzeugt wurden, eine Subscription auf einer anderen erreichen müssen.

Tasks‑Extension

Langanhaltende Arbeit wurde aus dem experimentellen Kernprotokoll in folgende Extension verschoben:

io.modelcontextprotocol/tasks

Die Extension nutzt:

• tasks/get für Polling;
• tasks/update für Client‑zu‑Server‑Updates;
• dauerhafte Task‑Handles;
• subscriptions/listen für opt‑in‑Updates.

Die älteren Muster tasks/result und tasks/list sollten nicht in eine neue Implementierung übernommen werden.

Veraltete Funktionen

Die folgenden Funktionen sind veraltet:

Veraltete Funktionalität bleibt während des Ausmusterungsfensters verfügbar, neue Implementierungen sollten sie jedoch nicht übernehmen. Die MCP‑Lifecycle‑Policy bietet eine mindestens zwölfmonatige Ausmusterungsperiode; das bedeutet nicht, dass jede Funktion dasselbe bestätigte Entfernungsdatum hat.

Sieh dir das offizielle deprecated‑features‑Register an, bevor du einen Außerdienststellungs‑Zeitplan festlegst.

7. Migration sicher ausrollen

Ändere Clients, Server, Gateways, Caching und Autorisierung nicht in einem unbeobachteten Release.

Empfohlene Migrationsreihenfolge

1. Protokollversionen, SDKs, Sitzungen, SSE‑Traffic, DCR‑Clients und veraltete Methoden inventarisieren.
2. SDKs in Nicht‑Produktionsumgebungen upgraden.
3. server/discover und Versionsverhandlung ergänzen.
4. Versteckte Sitzungsabhängigkeiten ersetzen.
5. MRTR implementieren und absichern.
6. Validierte Routing‑Header und Scoped Caches ergänzen.
7. Issuer‑Grenzen in der Autorisierung testen.
8. Das moderne Protokoll neben dem Legacy‑Pfad im Canary ausrollen.
9. Älteres Verhalten erst nach Sichtung der Telemetrie außer Betrieb nehmen.

Kompatibilität während des Canary

Modern client + modern server
→ Use MCP 2026-07-28

Modern client + legacy server
→ Probe and fall back when supported

Legacy client + dual-version server
→ Continue on the legacy path

Unsupported combination
→ Return a clear protocol-version error

Die Veröffentlichung einer neuen MCP‑Spezifikation ist kein Ökosystem‑weiter Schalter. Clients, Server, SDKs und Hosted‑Plattformen migrieren mit unterschiedlicher Geschwindigkeit.

Aufzuzeichnende Telemetrie

Erfolgreiche One‑Shot‑tools/call‑Requests reichen nicht aus, um die Migration zu messen. Ein Workflow, der wiederholt in Timeouts läuft, unnötige Eingaben verlangt oder einen externen Schreibvorgang dupliziert, ist weiterhin ein Produktionsfehler.

Wie CometAPI in eine MCP‑Architektur passt

MCP ersetzt keine Model‑API. Die beiden Schichten lösen unterschiedliche Integrationsprobleme.

Eine typische Produktionsarchitektur sieht so aus:

Application or agent
        ↓
MCP clients and servers
Tools, resources, approvals, tasks
        ↓
Unified model API
GPT, Claude, Gemini, DeepSeek, and other models

MCP standardisiert, wie Agenten mit Tools und Kontext interagieren. Es standardisiert nicht Modellpreise, Provider‑Credentials, Inference‑Endpoints oder Provider‑Failover.

Diese Trennung ist besonders nützlich bei der Migration weg von der veralteten Sampling‑Funktion. Wenn ein MCP‑Server oder der ihn konsumierende Agent weiterhin Modell‑Inference benötigt, kann die Anwendung direkt eine Model‑API aufrufen, anstatt vom ehemaligen MCP‑Sampling‑Flow abzuhängen.

Wann ein einheitliches Model‑Gateway hilft

Ein einheitliches Model‑Gateway kann den Betrieb vereinfachen, wenn:

• mehrere MCP‑Server Zugriff auf unterschiedliche Model‑Provider benötigen;
• verschiedene Tools unterschiedliche Modelle erfordern;
• Teams Modelle wechseln wollen, ohne Provider‑spezifische Integrationen neu zu schreiben;
• Credentials, Nutzung und Abrechnung zentral verwaltet werden müssen;
• der Modellzugriff unabhängig von MCP‑Transportänderungen bleiben soll.

CometAPI stellt einen OpenAI‑kompatiblen Endpunkt bereit, der als Model‑Access‑Layer hinter MCP‑Anwendungen genutzt werden kann. So bleibt die Logik zum Model‑Provider getrennt von MCP‑Tools, Ressourcen und Task‑Orchestrierung.

Beispielsweise kann ein MCP‑Tool ein Modell über denselben OpenAI‑kompatiblen Client aufrufen, der anderswo in der Anwendung verwendet wird:

import OpenAI from "openai";

const client = new OpenAI({
  apiKey: process.env.COMETAPI_KEY,
  baseURL: "https://api.cometapi.com/v1"
});

export async function summarizeResource(content: string) {
  const response = await client.chat.completions.create({
    model: "your-selected-model",
    messages: [
      {
        role: "system",
        content: "Summarize the supplied resource clearly and concisely."
      },
      {
        role: "user",
        content
      }
    ]
  });

  return response.choices[0]?.message?.content ?? "";
}

Der MCP‑Server bleibt verantwortlich für Tool‑Vertrag, Autorisierung, State und Ergebnisbehandlung. Das Model‑Gateway übernimmt Modellauswahl, Provider‑Zugriff und Inference‑Responses.

Diese Trennung bringt zwei praktische Vorteile:

1. MCP‑Clients und ‑Server können auf das neue Protokoll migrieren, ohne die Model‑Integrationsschicht zu ändern.
2. Model‑Provider können gewechselt werden, ohne MCP‑Tools oder Transportverhalten neu zu gestalten.

Weitere Implementierungsdetails findest du im CometAPI Quickstart, in der API‑Dokumentation und im Leitfaden für Multi‑Model‑AI‑Anwendungen.

MCP 2026-07-28 Migrations‑Checkliste

Client

• SDK auf eine kompatible Version aktualisieren.
• Moderne Versionsverhandlung aktivieren.
• server/discover unterstützen.
• Bei jeder Anfrage Protokoll‑Metadaten einschließen.
• resultType handhaben.
• MRTR unterstützen oder explizit ablehnen.
• Für Retries eine neue JSON‑RPC‑ID verwenden.
• requestState beibehalten und zurückgeben.
• OAuth‑Issuer validieren.
• Credentials nach Issuer speichern.
• Cache‑Hinweise respektieren.
• subscriptions/listen bei Bedarf unterstützen.

Server

• Modern‑Request‑Initialisierungsschranken entfernen.
• Abhängigkeiten von Mcp-Session-Id entfernen.
• server/discover implementieren.
• Versteckten State durch Handles oder Shared Storage ersetzen.
• resultType zurückgeben.
• Vom Server initiierte Requests durch MRTR ersetzen.
• requestState schützen.
• Alle inputResponses validieren.
• Idempotenz für Seiteneffekte ergänzen.
• Deterministische Listen zurückgeben.
• Konservative Cache‑Hinweise veröffentlichen.
• Langanhaltende Arbeit auf die Tasks‑Extension migrieren.

Gateway und Infrastruktur

• MCP‑Request‑Header validieren.
• Header mit dem Request‑Body vergleichen.
• Unnötiges Sticky Routing entfernen.
• Requests über mehrere Instanzen testen.
• Caches entlang der Autorisierungsgrenzen partitionieren.
• Einen gemeinsamen Notification‑Bus bei Bedarf ergänzen.
• Legacy‑ und veralteten Traffic nachverfolgen.
• Während des Canary einen Rollback‑Pfad vorhalten.

FAQ

Was ist MCP 2026-07-28?

MCP 2026-07-28 ist die am 28. Juli 2026 veröffentlichte Model Context Protocol‑Spezifikation. Sie führt einen zustandslosen Protokoll‑Kern, Multi Round‑Trip Requests, HTTP‑Routing‑Header, cachefähige Ergebnisse, Änderungen bei der Autorisierung, Extensions und einen formalen Ausmusterungs‑Lebenszyklus ein.

Ist Mcp-Session-Id entfernt?

Ja. Das neue Streamable‑HTTP‑Protokoll verwendet Mcp-Session-Id nicht mehr.

Anwendungen können weiterhin State durch explizite Handles, Shared Storage, dauerhafte Tasks oder geschützte Request‑State‑Werte beibehalten.

Ist der MCP‑Initialisierungshandshake entfernt?

Ja. Moderne Anfragen erfordern den Austausch initialize und notifications/initialized nicht mehr.

Server müssen server/discover implementieren, allerdings müssen Clients dies nicht vor jeder Operation aufrufen.

Bedeutet zustandsloses MCP, dass Tools keinen State behalten können?

Nein. Zustandslos bezieht sich auf die Protokollebene.

Ein Tool kann weiterhin State speichern, aber die Request‑Verarbeitung sollte nicht von versteckter Transport‑Affinität oder einem spezifischen Serverprozess abhängen.

Was ist MRTR?

Multi Round‑Trip Requests ermöglichen es einem Server, zusätzliche Client‑ oder Nutzereingaben anzufordern, ohne einen vom Server initiierten Request über eine dauerhaft offene bidirektionale Verbindung zu senden.

Der Server gibt input_required zurück, und der Client versucht die ursprüngliche Operation mit den angeforderten Antworten erneut.

Wird HTTP+SSE sofort entfernt?

Nein. Es ist veraltet, aber nicht sofort entfernt.

Neue Server sollten Streamable HTTP nutzen, während bestehende Systeme verbleibenden HTTP+SSE‑Traffic messen und migrieren sollten.

Nutzen TypeScript‑SDK‑v2‑Clients automatisch MCP 2026-07-28?

Nein. Das TypeScript‑v2‑SDK erfordert eine explizite Konfiguration der Versionsverhandlung, um das moderne Protokoll zu verwenden.

Nutze die automatische Verhandlung, wenn der Client sowohl mit modernen als auch mit Legacy‑Servern funktionieren muss.

Abschließende Empfehlungen

MCP 2026-07-28 erleichtert das Skalieren, Routen, Cachen und Beobachten entfernter MCP‑Infrastruktur. Das Hauptrisiko der Migration ist nicht das Entfernen eines Headers oder Handshakes, sondern der versteckte Anwendungsstate und die Interaktionslogik, die weiterhin davon abhängen können.

Bevor du das neue Protokoll einsetzt:

Finde jede Abhängigkeit von Initialisierung und Mcp-Session-Id.

1. Verschiebe den benötigten State in explizite Handles oder Shared Storage.
2. Implementiere MRTR mit Ablauf, Wiedergabeschutz und Idempotenz.
3. Validere MCP‑Header gegenüber dem JSON‑RPC‑Body.
4. Partitioniere Caches nach Mandant und Autorisierungs‑Scope.
5. Härte die OAuth‑Issuer‑Validierung.
6. Miss veraltete Methoden und Legacy‑Transport‑Traffic.
7. Rolle moderne und Legacy‑Protokollpfade im Canary aus, bevor du sie außer Betrieb nimmst.

Behandle die Migration als Infrastrukturänderung, nicht als routinemäßiges SDK‑Upgrade.

Sobald die MCP‑Schicht zustandslos und beobachtbar ist, halte den Modellzugriff hinter einer separaten Schnittstelle. So können sich Tool‑Protokoll und Model‑Provider‑Schicht unabhängig weiterentwickeln.