MCP 2026-07-28 hinter HTTP-Load-Balancern: Routing und sichere Cache-Geltungsbereiche

Worum es geht

Stand: 25. Oktober 2026. In MCP 2026-07-28 kann jede HTTP-Anfrage den Kontext mitführen, der für ihre unabhängige Verarbeitung nötig ist. Vor Änderungen an Gateway-Regeln die versionierten Spezifikationen für Streamable HTTP, Caching und Werkzeuge erneut prüfen. Gewöhnliche Lastverteilung und korrektes Caching von Ergebnissen sind getrennte Entscheidungen beim Deployment.

Das Kernprotokoll erfordert keine Transportsitzungen mehr. Anwendungszustände, die über mehrere Anfragen hinweg bestehen, benötigen weiterhin explizite Kennungen und eine geeignete Speicherung. Eine Anfrage kann ausserdem eine Streaming-Antwort haben; Zustandslosigkeit macht nicht jede Verbindung kurzlebig.

Warum es wichtig ist

RFC 9111 definiert gewöhnliche HTTP-Cache-Schlüssel anhand der HTTP-Methode und der Ziel-URI, gegebenenfalls ergänzt um weitere Unterscheidungsmerkmale. MCP-Vorgänge teilen sich einen POST-Endpunkt, während ihre Methode und Parameter im JSON stehen. Daraus folgt: Ein allgemeiner Cache, der nur /mcp als Schlüssel verwendet, kann diese Vorgänge nicht sicher unterscheiden. Das JSON-Feld ttlMs ist kein HTTP-Header Cache-Control und konfiguriert einen Proxy nicht automatisch.

Werkzeuglisten dürfen je nach Autorisierung variieren, nicht jedoch aufgrund des bisherigen Verbindungsverlaufs. Wenn sich die verfügbare Menge nicht ändert, wird eine deterministische Reihenfolge empfohlen. Keine dieser Eigenschaften macht einen nach Berechtigungen gefilterten Katalog öffentlich.

So wird es angewendet

• Routing-Metadaten erhalten und validieren. MCP-Protocol-Version und Mcp-Method weiterleiten; für tools/call, resources/read und prompts/get ist Mcp-Name erforderlich. Server, die den Body verarbeiten, müssen Abweichungen oder fehlende erforderliche Header mit HTTP 400 und HeaderMismatch (-32020) ablehnen. Namen vor dem Vergleich gemäss der vorgegebenen Kodierung dekodieren. Diesen aus dem Body übernommenen Headern bei einer älteren Protokollvariante ohne entsprechende Validierungspflicht nicht vertrauen.
• Sensible Eingaben aus Routing-Headern fernhalten. Werkzeugschemata können Parameter über x-mcp-header zugänglich machen; die Werkzeugspezifikation rät davon ab, Passwörter, Tokens oder personenbezogene Daten entsprechend zu kennzeichnen, da zwischengeschaltete Komponenten sie sehen können. Zulässige Metadaten für das Routing verwenden und die Autorisierung unmittelbar vor der Ausführung beibehalten.
• Streaming erhalten. JSON- und SSE-Antworten unterstützen, ungeeignete Antwortpufferung deaktivieren und das Verhalten bei Inaktivitätszeitüberschreitungen prüfen. Die Transportspezifikation empfiehlt X-Accel-Buffering: no für SSE und Keep-alive-Kommentare für langlebige Streams. Für diese Revision keine Wiederaufnahme mit Last-Event-ID konfigurieren und Abonnementstreams nicht cachen.
• Cache-fähige Ergebnisse begrenzen. Cache-Hinweise sind für vollständige Discovery-Ergebnisse sowie für Ergebnisse der Auflistung von Werkzeugen, Prompts, Ressourcen und Ressourcenvorlagen und des Lesens von Ressourcen erforderlich. Zwischenergebnisse mit input_required und Anfragen mit inputResponses oder requestState dürfen nicht gecacht werden. Nicht allein aus einer Beschreibung als rein lesend ableiten, dass eine Werkzeugausführung gecacht werden darf.
• Aktualität und Trennung unabhängig voneinander umsetzen. ttlMs misst Millisekunden ab Empfang; null bedeutet sofort veraltet. Relevante Änderungsbenachrichtigungen machen noch aktuelle Einträge ungültig. public erlaubt die gemeinsame Nutzung ausschliesslich für Daten ohne Nutzerbezug; private beschränkt die Wiederverwendung auf denselben Autorisierungskontext, einschliesslich eines separaten Caches bei einem anderen Token. Einträge nach Server, Protokoll, Methode und ergebnisrelevanten Parametern unterscheiden; bei paginierten Ergebnissen jede Seite getrennt halten.
• Ergebnisse cachen, keine veralteten Nachrichtenhüllen. Eine zwischengeschaltete Komponente mit MCP-Unterstützung muss die JSON-RPC-ID der aktuellen Anfrage zurückgeben. Den ursprünglichen Zeitpunkt beibehalten, bis zu dem das Ergebnis als aktuell gilt, statt die Frist bei einem Cache-Treffer neu beginnen zu lassen. Bei einem gewöhnlichen HTTP-Proxy das POST-Caching deaktiviert lassen, sofern sein MCP-Verhalten nicht ausdrücklich implementiert und geprüft ist. Wo Speicherung untersagt sein muss, zusätzlich zur Anwendungsrichtlinie die HTTP-Direktive no-store verwenden; private allein erlaubt die Speicherung in privaten Caches.
• Mit getrennten Testidentitäten prüfen. Vorgeschlagene Staging-Prüfungen: zwischen Instanzen wechseln, dieselbe Liste mit unterschiedlichen Berechtigungen abrufen, einen Katalog ändern, einen Eintrag ablaufen lassen und ein zulässiges Ergebnis mit einer anderen Anfrage-ID wiederverwenden. Die rechtzeitige Auslieferung des Streams und das Ausbleiben nutzerübergreifender Wiederverwendung bestätigen.

Stolpersteine

TTL ist ein Hinweis auf die Aktualität, keine Garantie dafür, dass sich Daten nicht ändern können. Header-basiertes Routing ist keine Authentifizierung. Eine erfolgreich auf eine Instanz verteilte Anfrage belegt nicht, dass Wiederholungen bei Aktionen mit Nebenwirkungen sicher sind. Diese Entscheidungen auf Anwendungsebene beim Aktivieren von Infrastrukturoptimierungen ausdrücklich festhalten.