Robuste Operationen, Fehler und Kontextbudget

Robuste Operationen, Fehler und Kontextbudget

0:00 Es gibt eine Größe, die beim Entwurf klassischer Schnittstellen kaum eine Rolle spielt und bei MCP über Erfolg und Misserfolg entscheidet: das Kontextbudget. Jede Antwort, die Ihr Server liefert, landet im Kontextfenster eines Sprachmodells und verdrängt dort etwas anderes. Wer alles zurückgibt, bezahlt mit der Aufmerksamkeit des Modells.

0:20 Dieses Modul behandelt die Eigenschaften, die eine Operation im Dauerbetrieb tragen: Wiederholbarkeit, Begrenzung und Sparsamkeit.

Robuste Operationen, Fehler und Kontextbudget

0:28 Damit schließen wir den ersten Tag ab. Vier Themen: Idempotenz und Teilerfolge, Pagination und Grenzen, das Kontextbudget mit den neuen Caching-Feldern und zum Schluss die Architekturfrage — wie verhält sich ein MCP-Server zu einer bereits vorhandenen API. Die letzte Frage stellt sich in jedem realen Projekt, und sie hat keine allgemeingültige Antwort. Aber sie hat drei brauchbare.

Idempotenz, Wiederholungen und partielle Fehler

0:52 Fangen wir mit einer Eigenschaft an, die bei Agenten wichtiger ist als bei Menschen — weil Agenten anders scheitern. Idempotent heißt: Zweimal ausgeführt wirkt wie einmal ausgeführt. Bei klassischen Oberflächen ist das ein Komfortthema — jemand klickt doppelt. Bei Agenten ist es die Grundannahme, und zwar aus zwei Gründen. Erstens wiederholt ein Agent Aufrufe nach unklaren Ergebnissen; das ist sein Normalverhalten.

1:17 Zweitens kann die Verbindung abbrechen, und dann weiß niemand, ob die Wirkung eingetreten ist. Ohne Idempotenz ist die Antwort auf „nochmal versuchen?" immer riskant. Der Trick steckt im dritten Parameter. Der Aufrufer schickt einen Schlüssel mit, und bei der Wiederholung denselben. Der Server merkt sich, dass er diesen Schlüssel schon gesehen hat, und liefert dasselbe Ergebnis zurück — ohne eine zweite Wirkung zu erzeugen.

1:43 Das ist ein etabliertes Muster aus dem Zahlungsverkehr, und es überträgt sich eins zu eins. Wichtig ist die Beschreibung des Parameters: Sie muss dem Modell sagen, dass bei einer Wiederholung derselbe Wert gehört — sonst würfelt es einen neuen. Eine Sammeloperation scheitert selten vollständig. Zwanzig Anfragen sollen geschlossen werden, achtzehn klappen, zwei nicht. Was antworten Sie?

2:06 Ein pauschales „fehlgeschlagen" zwingt zum vollständigen Wiederholen — und wenn die Operation nicht idempotent ist, richtet das Schaden an. Die brauchbare Antwort nennt je Eintrag, was gelang und was nicht. Und noch ein Hinweis für den HTTP-Betrieb: Dort gilt das Schließen des Antwortstroms als Abbruch. Der Server soll dann aufhören zu arbeiten.

2:28 Der erste Punkt ist die Folge fehlender Idempotenz in Reinform: Die Wiederholung legt einen zweiten Eintrag an. Im Anliegenbuch heißt das zwei identische Serviceanfragen, und irgendjemand bearbeitet beide. Der dritte Punkt ist ein Ressourcenthema, das man erst unter Last merkt — der Abbruch wird im Server ignoriert, und die Arbeit läuft weiter.

2:49 Bei einem Agenten, der viel abbricht, summiert sich das schnell. Und der vierte ist die ehrlichste Aussage der Folie: Idempotenz wird zugesichert, aber nie getestet.

Pagination, Timeouts und Rate Limits

2:59 Kommen wir zu den Grenzen. Große Ergebnismengen sind kein Betriebsproblem, sondern ein Entwurfsproblem. MCP paginiert über undurchsichtige Cursor, nicht über Seitennummern. Die Antwort enthält die aktuelle Seite und optional einen Zeiger auf die nächste; fehlt er, ist das Ende erreicht. Zwei Regeln, die man kennen sollte: Die Seitengröße bestimmt der Server, und Clients dürfen keine feste Größe annehmen.

3:25 Und der Cursor ist undurchsichtig — er darf nicht ausgewertet, nicht geparst und nicht verändert werden. Auch nicht, wenn erkennbar eine Zahl darin steckt. Die Tabelle beantwortet eine Frage, die sich beim Bauen ständig stellt. Alle Listen paginieren. Das Lesen einer Ressource nicht — es liefert einen Inhalt, keine Menge —, darf aber zwischengespeichert werden.

3:47 Und der Werkzeugaufruf macht beides nicht: Er paginiert nicht, und er wird nicht zwischengespeichert. Das ist konsequent, denn ein Aufruf kann Wirkung haben, und Wirkung darf man nicht aus dem Zwischenspeicher bedienen. Wenn Ihre Suche also große Mengen liefert, müssen Sie die Begrenzung selbst in die Parameter bauen. Die Spezifikation ist an dieser Stelle ungewöhnlich direkt: Server müssen Werkzeugaufrufe begrenzen. Nicht sollten — müssen.

4:14 Dazu kommen Zeitgrenzen je Operation gegen hängende Schleifen und Rate Limits je Identität gegen kaskadierende Fehler. Und der vierte Punkt ist der, der am häufigsten falsch gemacht wird: Eine Kürzung muss gemeldet werden. Wenn Ihr Server stillschweigend die ersten fünfzig Treffer liefert, hält das Modell sie für alle — und trifft Entscheidungen auf einer Datengrundlage, die es für vollständig hält.

4:37 Der zweite Punkt ist genau der eben genannte und der folgenschwerste: Das Ergebnis wird stillschweigend gekürzt. Der dritte ist ein Verstoß gegen die Spezifikation, der lange gutgeht und dann bricht — der Cursor wird geparst, um die Seitenzahl zu erraten. Das funktioniert, bis der Server seine Cursor-Kodierung ändert. Und der vierte ist ein Diagnosethema: Ein Timeout im SDK sieht aus wie ein Fehler der Gegenstelle.

5:02 Die Spezifikation empfiehlt ausdrücklich, lokale Fehler so zu kennzeichnen, dass man sie nicht verwechselt.

Kontextbudget und progressive Bereitstellung

5:09 Jetzt zum Kernthema des Moduls. Und zu zwei Feldern, die mit der aktuellen Spezifikationsversion neu dazugekommen sind. Cachebare Ergebnisse tragen jetzt zwei Angaben. Die erste nennt in Millisekunden, wie lange der Client das Ergebnis als frisch ansehen darf — die Semantik ist dieselbe wie bei HTTP. Die zweite sagt, wer es aufbewahren darf: öffentlich für nicht nutzerbezogene Inhalte, privat für alles, was an einen Berechtigungskontext gebunden ist.

5:38 Und ein wichtiger Zusatz aus der Spezifikation: Die Lebensdauer ist ein Frischehinweis, keine Garantie. Die Daten dürfen sich vorher ändern. Fünf Schritte, und das Prinzip dahinter ist das eines guten Suchergebnisses im Web: Zuerst kommt die Trefferzahl mit ein paar Facetten, dann eine Seite auf Anforderung, und der Volltext nur, wenn jemand ihn wirklich will.

6:00 Große Dokumente gehen als Verweis statt eingebettet — auch das kennt MCP als eigenen Inhaltstyp. Und Listen bekommen eine Lebensdauer, damit der Client sie nicht dauernd neu holt. Die Fußzeile nennt den Unterschied: mehrere Zehntausend Token im Übungsfall. Hier ist eine Falle, die man kennen muss. Ein Ergebnis mit öffentlicher Zwischenspeicher-Kennzeichnung darf zwischen Aufrufern geteilt werden — und das gilt ausdrücklich auch dann, wenn es von einem authentifizierten Endpunkt stammt.

6:28 Die Spezifikation sagt das so deutlich, weil der Fehler naheliegt: Man denkt, ein authentifizierter Aufruf sei automatisch privat. Ist er nicht. Und der letzte Punkt schließt das ab: Diese Kennzeichnung ersetzt keine Zugriffskontrolle. Der Server muss die Rechte trotzdem je Primitive prüfen. Der erste Punkt ist genau dieser Fehler in seiner häufigsten Ausprägung: Die nach Rechten gefilterte Werkzeugliste eines Nutzers wird als öffentlich ausgeliefert — und ein anderer bekommt sie aus dem Zwischenspeicher.

6:57 Der zweite ist ein Betriebsfehler mit spürbaren Folgen: Die Lebensdauer wird als Abfrageintervall missverstanden. Die Spezifikation warnt ausdrücklich davor, daraus einen Wecker zu machen; wer trotzdem pollt, soll wenigstens Streuung und Rückzug einbauen.

MCP neben einer vorhandenen API

7:12 Bleibt die Architekturfrage, die sich in jedem Bestandsprojekt stellt — und die niemand pauschal beantworten kann. Drei Wege. Der Adapter reicht die bestehende API weitgehend durch — schnell gebaut, erbt aber deren Granularität. Die Fassade bündelt mehrere Aufrufe zu Absichten — mehr Entwurfsarbeit, deutlich besseres Ergebnis.

7:32 Und die eigene Schnittstelle entsteht unabhängig daneben — beste Passung, doppelte Pflege. Die Wahl entscheidet über drei Dinge: Pflegeaufwand, Granularität und die Frage, wo die Autorisierung sitzt. Die drei Schichten sind bewusst übereinander gezeichnet, denn in der Praxis wandert man von oben nach unten. Man beginnt mit dem Adapter, weil er in einem Nachmittag steht.

7:55 Dann merkt man, dass das Modell für eine Frage drei Aufrufe braucht, und baut eine Fassade darüber. Und in seltenen Fällen stellt sich heraus, dass die bestehende API gar nicht passt — dann entsteht etwas Eigenes. Wichtig ist nur, dass man diesen Weg bewusst geht und nicht beim Adapter stehen bleibt, weil er schon da ist.

8:15 Der zweite Punkt ist der, den man im Betrieb spürt: Drei API-Aufrufe für eine Frage kosten drei Runden im Modell — und jede Runde kostet Zeit, Token und eine weitere Gelegenheit, eine falsche Entscheidung zu treffen. Der dritte Punkt ist der architektonisch schwierigste: Die Autorisierung der bestehenden API kennt den Agenten als Rolle nicht.

8:34 Sie wurde für Menschen und für Systeme entworfen, nicht für etwas dazwischen. Darauf kommen wir an Tag drei ausführlich zurück. Der erste Punkt ist die Adapter-Falle in Reinform: Jeder Endpunkt wird eins zu eins zum Werkzeug, und der Katalog explodiert. Fünfzig Werkzeuge kann kein Modell sinnvoll auseinanderhalten. Der zweite ist der Fassaden-Fehler: Die Fassade bekommt Fachlogik, die es in der API nicht gibt — und damit haben Sie eine zweite fachliche Wahrheit.

9:01 Und der vierte ist die Konsequenz daraus, wenn man es schleifen lässt: Beide Schnittstellen behaupten unterschiedliche Dinge, und niemand weiß, welche recht hat.

Übung

9:11 Zum Abschluss des ersten Tages wird gemessen — und dann umgebaut. Die Reihenfolge ist wichtig: erst messen, dann umbauen, dann wieder messen. Ohne die erste Messung ist der Umbau eine Behauptung, und Sie können hinterher nicht sagen, ob er etwas gebracht hat. Das Ziel ist eine Operation, deren Antwort mit der Fragestellung wächst — und nicht mit der Datenmenge im Bestand.

9:34 Die Testanfrage trifft rund viertausend Serviceanfragen. Lassen Sie sie zuerst in der Ausgangsvariante laufen und halten Sie fest, was das an Kontext kostet. Dann bauen Sie um: Trefferzahl und Facetten zuerst, Seiten auf Anforderung, Volltext über einen zweiten Aufruf. Und messen Sie erneut. Beide Zahlen gehören in die Dokumentation — sie sind das Argument, mit dem Sie den Aufwand im eigenen Team begründen.

10:00 Der zweite Punkt ist die typische Überkorrektur: Die neue Variante braucht jetzt fünf Aufrufe für den Normalfall. Progressive Bereitstellung heißt nicht, alles so klein wie möglich zu schneiden — der häufige Fall soll in einem Aufruf beantwortet sein. Der dritte ist ein Implementierungsfehler, der den ganzen Gewinn auffrisst: Die Facetten werden berechnet, indem doch alle Treffer geladen werden.

10:22 Damit ist zwar die Antwort klein, die Last aber unverändert. Damit ist Tag eins abgeschlossen — morgen geht es um die Arbeit mit dem Agenten.