Wer einen MCP-Server nach einem Tutorial aus dem letzten Jahr baut, schreibt
heute gegen ein Protokoll, das es so nicht mehr gibt. Die Revision
2026-07-28 hat den Einstieg umgebaut: initialize und die Sitzungskennung
Mcp-Session-Id sind entfallen.
Fähigkeiten werden je Anfrage ausgehandelt
Statt einmal beim Verbindungsaufbau zu klären, wer was kann, trägt jetzt jede
einzelne Anfrage ihre Angaben im Feld _meta — Protokollversion und
Client-Fähigkeiten sind Pflicht. MCP ist damit zustandslos: Ein Server darf
aus vorherigen Anfragen derselben Verbindung nichts ableiten, weder Fähigkeiten
noch Identität. Eine offene Verbindung ist keine Sitzung und kein Gespräch.
Rückfragen haben keine Gegenrichtung mehr
Braucht ein Server eine Eingabe, fragt er nicht zurück. Er antwortet mit
resultType: input_required und benennt, was er braucht; der Client beschafft
es und wiederholt den ursprünglichen Aufruf. Das Muster heißt Multi
Round-Trip Request.
Das Detail, an dem es in der Praxis scheitert: Die JSON-RPC-ID muss sich zwischen Erstaufruf und Wiederholung unterscheiden. Dieselbe ID wird abgelehnt — und der Fehler sieht aus wie ein Problem der Gegenstelle.
Die teuerste Annahme
Sie steht selten im Code und fast immer im Kopf: Ein Server merkt sich den Nutzer aus der ersten Anfrage. Das funktioniert im Test mit einem Client und fällt im Betrieb auf. Ebenfalls im selben Zug abgekündigt: Roots, Sampling, Logging über das Protokoll, Dynamic Client Registration und der HTTP+SSE-Transport — weiterhin Teil der Spezifikation, aber mit Datum zum Entfall.
Mehr dazu im Seminar
Primitives, Fehlercodes und Migrationsfragen behandelt das Modul Primitives, Protokollmechanik und Spezifikationsstand — mit Video und Kapitelübersicht. Zum Nachschlagen daneben: das Cheat Sheet MCP-Server und Protokoll.