Primitives, Protokollmechanik und Spezifikationsstand

Primitives und Protokollmechanik

0:00 Drei Bausteine tragen das gesamte Protokoll: Tools, Resources und Prompts. Alles andere in der Spezifikation regelt, wie man sie findet, wie man sie aufruft und wann man ihnen glauben darf. In diesem Modul geht es um diese drei Bausteine — und um eine ganze Reihe von Änderungen, die mit der Version vom 28. Juli 2026 gekommen sind.

0:20 Wenn Sie älteren Beispielcode im Netz finden, ist dieses Modul der Grund, warum er bei Ihnen nicht mehr läuft.

Primitives, Protokollmechanik und Spezifikationsstand

0:28 Ein Hinweis vorab, der Ihnen Arbeit spart: Die MCP-Spezifikation bewegt sich schnell. Was wir hier besprechen, ist der Stand vom Juli 2026, und der hat mit dem, was in vielen Blogartikeln steht, an mehreren Stellen nichts mehr zu tun. Nehmen Sie aus diesem Modul vor allem eine Gewohnheit mit: Bei MCP lohnt sich der Blick in die Spezifikation mehr als bei fast jeder anderen Technologie, weil Halbwissen hier besonders schnell veraltet.

Tools, Resources und Prompts

0:54 Fangen wir mit den drei Primitives an. Die Unterscheidung wirkt beim ersten Mal willkürlich und ist es überhaupt nicht — sie folgt einer einzigen Frage. Die Frage lautet: Wer entscheidet, wann das hier benutzt wird? Bei Tools ist es das Modell — es sieht die Liste und wählt aus. Bei Resources ist es die Anwendung, also der Host; er entscheidet, was in den Kontext kommt. Bei Prompts ist es der Mensch, der eine Vorlage bewusst auswählt.

1:21 Die Spezifikation nennt das die Kontrollhierarchie. Und diese Frage — wer löst es aus — ist die einzige, die Sie brauchen, um eine neue Funktion richtig einzuordnen. Nicht, wie kompliziert sie ist, und nicht, ob sie Daten liest oder schreibt. Am Anliegenbuch wird die Zuordnung anschaulich. Die Suche in den Anforderungen ist ein Tool: Das Modell entscheidet selbst, wann es suchen muss, und niemand kann das vorher wissen.

1:47 Das Architekturhandbuch ist eine Resource: Es ist Kontext, und die Anwendung entscheidet, ob sie ihn beilegt. Die Vorlage für den Änderungsbericht ist ein Prompt: Der Mensch wählt sie aus, wenn er sie braucht — in vielen Clients erscheint sie als Schrägstrich-Befehl. Drei Funktionen, dieselbe Anwendung, drei völlig verschiedene Auslöser.

2:07 Das Namensschema ist erfreulich langweilig, und das ist ein Kompliment. Jedes Primitive hat ein Verfahren zum Auflisten, erkennbar an der Endung. Werkzeuge werden aufgerufen, Prompts geholt, Ressourcen über ihre Adresse gelesen. Wer das Muster einmal verstanden hat, muss die Methodennamen nicht mehr nachschlagen. Wichtig ist der letzte Punkt: Die Listen sind dynamisch und dürfen sich ändern.

2:30 Ein Server darf morgen andere Werkzeuge anbieten als heute — was er nicht darf, ist sie je Verbindung unterschiedlich ausliefern. Der dritte Punkt ist der, der in eigenen Implementierungen am ehesten unabsichtlich passiert: Die Liste der Werkzeuge wechselt je Verbindung. Das verbietet die Spezifikation ausdrücklich — mit einer Ausnahme, die man kennen sollte: Sie darf sich nach der vorgelegten Autorisierung richten.

2:55 Ein Nutzer mit Leserechten sieht weniger Werkzeuge als ein Administrator, und das ist erlaubt, weil Zugangsdaten je Anfrage mitkommen und kein Verbindungszustand sind. Der Unterschied ist fein und in der Praxis wichtig.

Elicitation, Notifications und Fortschritt

3:08 Jetzt zur ersten großen Änderung. Bisher konnte ein Server zurückfragen. Das geht so nicht mehr — und der Ersatz ist besser, als er zunächst klingt. Stellen Sie sich einen Sachbearbeiter vor, der einen Antrag bearbeitet und merkt, dass eine Unterschrift fehlt. Früher hätte er angerufen und gewartet. Jetzt schickt er den Antrag zurück mit dem Vermerk, was fehlt — und Sie reichen ihn komplett neu ein. Genau das ist der Multi Round-Trip Request.

3:36 Der Server antwortet nicht mit einer Frage, sondern mit einem Zwischenergebnis, das benennt, was ihm fehlt. Der Client besorgt es und stellt den Aufruf neu. Der Gewinn: Der Server muss zwischendurch nichts offenhalten und nichts sich merken. Zwei Nachrichten, und worauf es ankommt, sind zwei Felder. Oben der Ergebnistyp, der sagt: noch nicht fertig, mir fehlt etwas.

3:58 Und der Zustandsschlüssel, den der Server mitgibt — damit muss er sich selbst nichts merken, der Client trägt den Kontext zurück. Unten die Wiederholung mit derselben Aufgabe plus den Antworten. Die Fußzeile enthält die Falle, in die jeder einmal tappt: Die Kennung der Nachricht muss sich zwischen Erstaufruf und Wiederholung unterscheiden.

4:18 Sonst lehnt die Gegenstelle ab, weil sie die Kennung noch für die offene Anfrage führt. Auch hier hat sich die Richtung gedreht. Benachrichtigungen kommen nicht mehr einfach, man abonniert sie. Der Client öffnet einen langen Strom und sagt dabei ausdrücklich, welche Ereignisse er überhaupt will; der Server bestätigt und liefert dann nur das Abonnierte.

4:39 Das ist sparsamer und lässt sich betreiben. Wichtig für die Fehlersuche ist der letzte Punkt: Fortschrittsmeldungen laufen nicht über diesen Strom, sondern über die Antwort der Anfrage, zu der sie gehören. Wer sie im falschen Kanal sucht, sucht lange. Der erste Punkt betrifft jeden, der eine ältere Implementierung migriert: Der Server versucht weiterhin, eine eigene Anfrage zu senden — das gibt es nicht mehr.

5:03 Der dritte ist subtiler und sicherheitsrelevant: Ergebnisse aus einer Wiederholung dürfen nicht zwischengespeichert werden. Der Grund leuchtet sofort ein, wenn man ihn hört — sie hängen von Eingaben ab, die gar nicht im Zwischenspeicher-Schlüssel stehen. Und der vierte Punkt ist eine Haltung, keine Regel: Benachrichtigungen sind nach bestem Bemühen.

5:22 Ein Client, der sich auf sie verlässt statt gelegentlich nachzusehen, verpasst irgendwann etwas.

Zustandsloser Kern und Aushandlung

5:28 Und jetzt die Änderung, die alles andere nach sich zieht. Sie ist der Grund, warum der Verbindungsaufbau, wie Sie ihn vielleicht kennen, verschwunden ist. MCP ist ein zustandsloses Protokoll. Alles, was zur Bearbeitung nötig ist, steht in der Anfrage selbst — Protokollversion, Fähigkeiten, Identität. Ein Server darf aus vorherigen Anfragen derselben Verbindung nichts ableiten, und zwar ausdrücklich nichts.

5:53 Das ist ein radikaler Schnitt, und er hat eine ungewöhnliche Konsequenz, die die Spezifikation eigens hervorhebt: Eine offene Verbindung ist kein Gespräch. Ein Client darf unabhängige Anfragen über denselben Prozess schicken, und der Server darf daraus keinen Zusammenhang konstruieren. Hier sehen Sie das Metadatenfeld, das jede Anfrage begleitet.

6:14 Drei Einträge: Protokollversion, Angaben zum Client und die Fähigkeiten, die dieser Client für diese Anfrage mitbringt. Zwei davon sind Pflicht, die Angabe zum Client soll gesetzt werden. Und hier eine Warnung aus der Spezifikation, die man leicht überliest: Diese Angaben sind Selbstauskunft und werden vom Protokoll nicht geprüft.

6:34 Sie sind für Anzeige, Protokollierung und Fehlersuche gedacht — für Sicherheitsentscheidungen ausdrücklich nicht. Vier Konsequenzen, und die letzte ist die im Alltag angenehmste. Eine Verbindung ist keine Sitzung. Der Client darf unabhängige Anfragen mischen. Discovery ist optional — man kann Fähigkeiten vorab abfragen, muss aber nicht. Und Listen tragen jetzt eine Lebensdauer und eine Angabe, wer sie zwischenspeichern darf.

7:01 Zusammen bedeutet das: Ein MCP-Server skaliert wie ein gewöhnlicher zustandsloser Webdienst. Keine Sitzungsbindung, keine klebrigen Verbindungen. Das ist die Art Entscheidung, die man im Betrieb erst zu schätzen lernt. Der erste Punkt ist der Migrationsfehler schlechthin: Der Server merkt sich den Nutzer aus der ersten Anfrage.

7:22 Das funktioniert in der Entwicklung tadellos und bricht, sobald zwei Menschen denselben Prozess nutzen. Der dritte ist der gefährlichste: cacheScope steht auf öffentlich, obwohl die Liste nutzerabhängig ist. Dann darf ein Zwischenspeicher sie an jemand anderen ausliefern — auch wenn die ursprüngliche Anfrage authentifiziert war.

7:40 Das steht so in den Sicherheitshinweisen der Spezifikation, und es ist eine der Stellen, an denen Bequemlichkeit unmittelbar zum Datenabfluss führt.

Erweiterungen und SDK-Komfort

7:49 Bleibt der Blick auf das, was neben dem Kern existiert — und auf das, was demnächst verschwindet. Neben dem Kern gibt es Erweiterungen. Sie sind ausdrücklich freiwillig und müssen von beiden Seiten unterstützt werden, sonst gelten sie nicht. Drei sind derzeit bemerkenswert: Tasks für lange Operationen mit einem dauerhaften Handle, über das man den Stand abfragt. Skills over MCP für strukturierte Arbeitsanweisungen.

8:15 Und MCP Apps für eingebettete Oberflächenelemente. Man muss sie nicht kennen, um loszulegen — aber man sollte wissen, dass sie existieren, bevor man anfängt, Vergleichbares selbst zu bauen. Diese Tabelle ist der Grund, warum ältere Beispiele nicht mehr funktionieren. Fünf Dinge sind abgekündigt, nicht zwei oder drei. Besonders bemerkenswert ist Sampling — die Möglichkeit, dass ein Server das Modell des Clients mitbenutzt. Die Idee war elegant: Der Server bleibt modellunabhängig.

8:46 Der empfohlene Weg ist jetzt die direkte Anbindung an die Modell-API. Und das Protokoll-Logging ist ebenfalls Geschichte; stattdessen schreibt man bei lokalen Servern auf stderr und nutzt sonst OpenTelemetry. Die Frist steht in der Fußzeile: frühester Entfall ist die erste Revision ab dem 28. Juli 2027. Ich finde den Umgang der Spezifikation damit vorbildlich, und zwar aus einem praktischen Grund: Abgekündigt heißt nicht weg.

9:14 Das Feature bleibt Teil der Spezifikation, es ist nur zum Entfall vorgesehen. Neue Implementierungen sollen es nicht mehr aufnehmen, bestehende sollen vor dem frühesten Entfall migrieren. Das gibt Ihnen ein Datum, mit dem sich planen lässt — und einen Hinweis, was Sie in einem Review eines neuen Servers beanstanden sollten.

9:34 Wer 2026 noch auf Sampling setzt, baut mit Ansage Migrationsarbeit für 2027 ein. Der erste Punkt beschreibt genau das Problem: Ein neuer Server setzt auf Sampling, weil ältere Beispiele es zeigen. Es steht in jedem zweiten Blogartikel, und der ist eben von letztem Jahr. Der dritte Punkt ist eine Unterscheidung, die man sich früh angewöhnen sollte: SDK-Komfortfunktionen sind nicht das Protokoll.

9:58 Was Ihr SDK anbietet, kann über die Spezifikation hinausgehen — und dann läuft es nur bei Clients, die dasselbe SDK nutzen. Wer das nicht trennt, entdeckt es beim ersten fremden Client.

Übung

10:10 Zwei Aufgaben zum Abschluss: einmal die Zuordnung zu den Primitives, und einmal ein ehrlicher Blick auf einen Bestand. Der erste Teil ist Handwerk: Sechs geplante Funktionen des Anliegenbuch-Servers, jede muss ein Primitive bekommen. Der zweite Teil ist der interessantere — ein Migrationscheck. Nehmen Sie einen bestehenden Server oder ein Beispiel aus der Dokumentation und prüfen Sie, was bei einer Umstellung auf die aktuelle Version zu ändern wäre.

10:37 Das ist die Art Aufgabe, die man einmal gemacht haben sollte, bevor sie im Projekt ansteht. Die sechs Funktionen stehen auf der Folie: offene Anfragen suchen, Architekturhandbuch lesen, betroffene Komponenten ermitteln, Tests ausführen, Änderungsbericht entwerfen, Status einer Anfrage setzen. Zu jeder gehört ein Primitive und ein Satz Begründung. Die Frage, an der Sie sich festbeißen werden, ist der Änderungsbericht — und das ist Absicht.

11:03 Beim Migrationscheck achten Sie nicht nur auf den Code, sondern auch auf die Konfiguration: Abgekündigtes versteckt sich gern dort. Der erste Punkt ist der, der die ganze Zuordnung kippt: Die Entscheidung folgt der Frage, was technisch geht, statt der Frage, wer sie auslöst. Technisch ließe sich jede der sechs Funktionen als Tool bauen — nur eben schlecht. Der zweite ist die Auflösung des Änderungsberichts: Er ist eine Vorlage, kein Werkzeug.

11:30 Und der vierte betrifft die Migration: Prüfen Sie die Fristen, bevor Sie hektisch alles umbauen. Sie haben in der Regel ein Jahr. Im nächsten Modul bauen wir den Server dann endlich selbst.