MCP Roots, Sampling und Logging: Migrationswege nach der Abkündigung mit 2026-07-28

Worum es geht

Stand: 25. Oktober 2026. Mit der Revision 2026-07-28 werden Roots, Sampling und Logging abgekündigt. Vor dem Entfernen von Kompatibilitätscode die jeweiligen Hinweise, das Verzeichnis abgekündigter Funktionen und die Lebenszyklusrichtlinie erneut prüfen. Laut Verzeichnis können sie frühestens mit der ersten Revision entfernt werden, die am oder nach dem 2027-07-28 erscheint. Ab diesem Zeitpunkt ist eine künftige Änderung der Spezifikation zulässig; es handelt sich nicht um ein automatisches Abschaltdatum.

Abgekündigte Funktionen bleiben Bestandteil der Spezifikation. Neue Implementierungen sollten sie nicht mehr einführen; bestehende Implementierungen sollten migrieren. Für die Entfernung aus SDKs gelten separate Zeitpläne. Die allgemeine Richtlinie erlaubt ausserdem ein dokumentiertes beschleunigtes Verfahren für Sicherheitsrisiken, die die entsprechenden Kriterien erfüllen. Die übliche Frist von zwölf Monaten ist daher keine bedingungslose Zusage für jede Situation.

Warum es wichtig ist

Die drei Funktionen erfüllen unterschiedliche Aufgaben. Roots übermittelt relevante Orte im Dateisystem, Sampling delegiert eine Modellanfrage an den Client, und Logging liefert Protokollbenachrichtigungen mit Logmeldungen. Ihr Ersatz kann Zuständigkeiten zwischen Client, Server und Betreiber verschieben. Eine Migration, die lediglich Fähigkeitskennzeichen entfernt, kann dazu führen, dass erforderliche Aufgaben nicht mehr implementiert sind.

Roots dient ausdrücklich nur der Information: MCP erzwingt keine Begrenzung des Dateisystemzugriffs. Sampling gibt dem Client derzeit die Kontrolle über Modellzugriff und Berechtigungen. Logging auf Protokollebene ist von den Betriebslogs des Servers zu unterscheiden. Diese Unterschiede bei der Auswahl von Alternativen berücksichtigen.

So wird es angewendet

• Roots durch expliziten Kontext ersetzen. Als Möglichkeiten sind Werkzeugparameter, Ressourcen-URIs oder eine Serverkonfiguration dokumentiert, die Verzeichnisse und Dateien beschreiben. Pfade und Berechtigungen in der zugreifenden Komponente validieren. Die Zustimmung der Nutzer und geeignete Zugriffskontrollen erhalten; ein übergebenes Verzeichnis belegt nicht, dass der Aufrufer es lesen darf. Solange Roots in dieser Revision beibehalten wird, die Fähigkeit bei jeder Anfrage bekannt geben und roots/list über den Mechanismus für Eingabeanforderungen austauschen.
• Sampling durch direkte Anbieterintegration ersetzen. Die Spezifikation empfiehlt die direkte Integration mit APIs von Sprachmodellanbietern. Dies als Wechsel der Zuständigkeit behandeln: Es ist mehr als eine Umbenennung ohne Auswirkungen. Dokumentieren, welche Komponente den Modellzugriff erhält und welche Daten sie sendet. Die bisherige Sampling-Schnittstelle bot Kontrolle auf Clientseite und empfahl eine menschliche Prüfung. Eine gleichwertige Prüfung erhalten, wo die Anwendung sie erfordert, und den Ablauf bei einer Ablehnung testen. Während des Übergangs Sampling-Fähigkeiten pro Anfrage deklarieren und die abgekündigten Optionen für serverübergreifenden Kontext vermeiden.
• Betriebslogs an ein geeignetes Ziel leiten. Dokumentiert sind stderr für stdio-Transporte und OpenTelemetry für strukturierte Beobachtbarkeit. Geheimnisse und personenbezogene Informationen aus Logmeldungen fernhalten und den Zugriff auf gesammelte Logs kontrollieren. Falls die Kompatibilität weiterhin Logging auf Protokollebene erfordert, deklariert der Server logging; Clients fordern über io.modelcontextprotocol/logLevel in _meta eine Protokollierungsstufe an.
• Anfragebezogenes Logging testen. Ein Server darf keine notifications/message ausgeben, wenn die betreffende Anfrage keine Protokollierungsstufe enthält. Zulässige Meldungen gehören in den Antwortstream dieser Anfrage, niemals in den Abonnementstream. Prüfen, dass die Wahl des Protokollierungsumfangs durch einen Client die Anfrage eines anderen Clients nicht beeinflussen kann.
• Jede Abhängigkeit separat ablösen. Als vorgeschlagenes Einführungsverfahren zunächst die nutzenden Komponenten erfassen, die Alternative einführen, denselben zulässigen Ablauf prüfen und erst dann die abgekündigte Fähigkeit nicht mehr bekannt geben. Nachweise darüber aufbewahren, welche Clients sie weiterhin benötigen.

Stolpersteine

Eine direkte Modellintegration übernimmt nicht automatisch die bisherige Oberfläche des Clients zur Einholung der Zustimmung. Ein anderes Ziel für Logs erhält nicht automatisch die Schwärzung sensibler Daten. Ein Pfadparameter erzeugt keine Sandbox. Die Abkündigung ist ein Anlass, diese Änderungen sorgfältig zu planen, und keine Erlaubnis, ihre Schutzmassnahmen abzuschwächen.