Tools aus Sicht des Sprachmodells entwerfen

Tools aus Sicht des Sprachmodells entwerfen

0:00 Wenn Sie eine Bibliothek entwerfen, denken Sie an einen Entwickler, der Dokumentation liest, Beispiele sucht und im Zweifel nachfragt. Beim Entwurf von MCP-Werkzeugen ist Ihr Gegenüber ein anderes: Es liest keine Dokumentation, hat kein Gedächtnis für Konventionen und entscheidet in Sekundenbruchteilen allein anhand dessen, was im Schema steht.

0:19 Dieser Perspektivwechsel ist der Inhalt des Moduls — und er ändert erstaunlich viel an dem, was ein guter Entwurf ist.

Tools aus Sicht des Sprachmodells entwerfen

0:27 Vier Themen: der Zuschnitt der Operationen, die Sprache in Namen und Beschreibungen, die Zusicherungen rund um einen Aufruf und — das wichtigste für Tag drei — die Trennung in lesende, vorbereitende und verändernde Operationen. Diese letzte Trennung ist die Grundlage dafür, dass man Berechtigungen und Bestätigungen überhaupt sinnvoll vergeben kann. Ohne sie wird jede Absicherung zur Pauschale.

Kleine, eindeutige Operationen

0:50 Beginnen wir beim Zuschnitt. Er ist die Entscheidung, die alle anderen nach sich zieht. Die Regel ist schlicht: eine Absicht je Werkzeug, eine Art von Ergebnis. Dazu eine praktische Randnotiz aus der Spezifikation: Namen sind nur innerhalb eines Servers eindeutig. Wenn ein Client mehrere Server bündelt, kann es zu Kollisionen kommen — zwei Server mit einer Suche.

1:12 Die Spezifikation empfiehlt Clients, dann eine eigene Unterscheidung einzuführen, und warnt ausdrücklich davor, dafür den Servernamen zu verwenden: Der ist nämlich auch nicht garantiert eindeutig. Links das, was man beim ersten Entwurf baut: ein Werkzeug, das alles kann, mit der Aktion als Parameter. Rechts das, was daraus werden sollte.

1:33 Vergleichen Sie die beiden Seiten nicht nach Aufwand — der ist ähnlich —, sondern nach dem, was man damit regeln kann. Links gibt es genau eine Berechtigung für lesen, ändern und löschen. Rechts gibt es vier, und Sie können die schreibenden weglassen, wenn der Auftrag sie nicht braucht. Diese Möglichkeit haben Sie links schlicht nicht.

1:53 Der erste Grund ist der grundsätzliche: Ein Aktionsparameter verlagert die Entscheidung ins Modell. Sie geben dem probabilistischen Teil des Systems die Wahl zwischen lesen und löschen — und genau das wollten wir in Modul 1 nicht. Der dritte Grund ist der, den man beim Schreiben merkt: Die Beschreibung muss alle Fälle abdecken und wird dadurch unscharf.

2:12 Und der vierte ist der, der im Ernstfall zählt: Ein Fehlgriff trifft im schlimmsten Fall die löschende Variante. Der erste Punkt ist die Gegenbewegung, und sie ist real: Der Werkzeugsatz wächst auf mehrere Dutzend, und die Auswahl wird unsicher. Zerlegen ist also kein Selbstzweck — es geht um Absichten, nicht um Kleinteiligkeit.

2:32 Der zweite Punkt nennt den häufigsten Fehler dabei: Die Zerlegung folgt der internen Schnittstelle statt den Absichten des Aufrufers. Und der dritte ist besonders tückisch: Zwei Werkzeuge überschneiden sich, und das Modell wählt abwechselnd. Das sieht in den Protokollen aus wie Zufall und ist ein Entwurfsfehler.

Namen, Beschreibungen und Parameter

2:50 Kommen wir zur Sprache. Sie ist bei MCP nicht Dokumentation, sondern Benutzeroberfläche. Ein Tool trägt Name, optional einen Anzeigetitel, eine Beschreibung, ein Eingabeschema und optional ein Ausgabeschema sowie Annotationen. Und jetzt der Satz, den man sich unterstreichen sollte — er steht als ausdrückliche Warnung in der Spezifikation: Clients müssen Tool-Annotationen als nicht vertrauenswürdig behandeln, solange sie nicht von einem vertrauenswürdigen Server stammen.

3:20 Annotationen sind also Hinweise, keine Zusicherungen. Ein Server kann behaupten, ein Werkzeug sei harmlos. Prüfen kann das niemand. Drei Parameter, und jeder zeigt eine andere Technik. Der Status ist eine Aufzählung — drei erlaubte Werte, mehr gibt es nicht, und das Modell kann gar nichts anderes schicken. Die Nummer hat ein Muster, das die Form erzwingt und gleich das Beispielformat mitliefert. Und der Grund ist optional, aber die Beschreibung sagt, wann er Pflicht wird.

3:49 Das ist der Punkt: Was Sie ins Schema schreiben, muss das Modell nicht raten. Und was es nicht raten muss, kann es nicht falsch raten. Die erste Regel ist die, gegen die am meisten verstoßen wird: Der Zweck gehört in den ersten Satz, nicht die Implementierung. Die dritte ist die mit dem besten Verhältnis von Aufwand zu Wirkung — Beispielwerte in der Parameterbeschreibung wirken stärker als jede Erklärung.

4:12 Und die vierte klärt eine häufige Verwirrung: Ein Titel ist für Menschen, der Name für die Maschine. Sie müssen technische Namen also nicht schön machen; dafür gibt es ein eigenes Feld. Der zweite Punkt ist handwerklich und häufig: Ein Datumsfeld nimmt eine freie Zeichenkette entgegen. Dann bekommen Sie fünf verschiedene Formate, und die Hälfte der Fehlversuche geht auf Ihr Konto.

4:35 Der dritte Punkt ist ein Konsistenzthema, das im Team auffällt: deutsche und englische Benennung im selben Server. Das verwirrt nicht nur Menschen. Und der vierte ist die Konsequenz aus der vorigen Folie — Annotationen sind Hinweise, keine verlässlichen Zusicherungen.

Vorbedingungen, Nachbedingungen und Invarianten

4:51 Jetzt zu den Zusicherungen rund um einen Aufruf. Der Begriff klingt akademisch, die Sache ist sehr praktisch. Drei Fragen: Was muss vorher gelten? Was ist danach garantiert? Was wird nie verletzt? Bei einer Bibliothek stehen die Antworten im Handbuch, und ein Entwickler liest sie. Hier muss alles sichtbar in Beschreibung und Schema stehen, sonst existiert es nur im Kopf des Entwicklers.

5:16 Und es reicht nicht, es hinzuschreiben — was der Server zusichert, muss er auch prüfen. Eine Beschreibung setzt nichts durch. An unserem Statuswerkzeug wird das konkret: Die Anfrage muss existieren und offen sein — das ist die Vorbedingung. Danach ist der Status gesetzt und die Historie ergänzt — das ist die Nachbedingung, und beachten Sie, dass der zweite Teil mitgehört: Wenn Ihr Werkzeug eine Historie führt, ist das eine Zusage.

5:43 Und die Invariante: Eine geschlossene Anfrage bleibt geschlossen. Alle drei stehen in der Beschreibung, damit das Modell sie kennt — und im Code, damit sie gelten. Hier schlägt die Zustandslosigkeit aus Modul 4 durch. MCP kennt keine Sitzung, also gibt es keinen impliziten Zustand zwischen zwei Aufrufen. Wer trotzdem etwas über mehrere Aufrufe hinweg braucht — einen Warenkorb, eine offene Transaktion —, gibt ein Handle zurück und nimmt es beim nächsten Aufruf wieder entgegen.

6:11 Zwei Dinge sind dabei wichtig: Der Server prüft bei jedem Aufruf die Berechtigung am Handle, und die Lebensdauer gehört in die Beschreibung des erzeugenden Werkzeugs — damit das Modell sie kennt, wenn es entscheidet, Zustand anzulegen. Der erste Punkt ist der sicherheitskritische, und er hat einen eigenen Namen — wir sehen ihn in Modul 14 als State Handle Hijacking wieder: Der Besitz eines Handles wird als Berechtigung gewertet.

6:36 Die Spezifikation ist da unmissverständlich: Ein Handle ist ein Name, keine Berechtigung. Der zweite Punkt verstärkt den ersten — fortlaufend nummerierte Handles sind erratbar. Und der dritte ist der verbreitetste: Die Zusicherung steht in der Beschreibung, aber nicht im Code. Dann ist sie eine Behauptung.

Lesend, vorbereitend, verändernd

6:55 Bleibt die Einteilung, auf die der ganze dritte Tag aufbaut. Drei Klassen, und die mittlere wird häufig vergessen. Lesende Operationen haben keine Wirkung außerhalb des Servers. Verändernde wirken. Und dazwischen liegt die Klasse, die man selten sieht und die viel löst: vorbereitende Operationen, die einen prüfbaren Vorschlag erzeugen, ohne ihn auszuführen.

7:16 Denken Sie an den Unterschied zwischen einer Überweisung ausfüllen und sie abschicken. Wer diese Zwischenstufe anbietet, kann einen Agenten ungefährlich arbeiten lassen und trotzdem am Ende etwas Fertiges haben, das ein Mensch nur noch freigibt. Vier Felder, und sie sind die direkte Übersetzung von Modul 1 in den Werkzeugentwurf. Lesend: ohne Bestätigung, breit verfügbar.

7:39 Vorbereitend: Das Ergebnis ist ein Vorschlag zur Prüfung. Verändernd und umkehrbar: Bestätigung und Protokoll. Verändernd und endgültig: Bestätigung plus zweites Augenpaar. Wenn Sie Ihren Tool-Katalog in diese vier Felder einsortieren, haben Sie die Vorarbeit für das Scope-Design in Modul 16 bereits erledigt. Vier Wirkungen, und die letzte ist die, die mir am wichtigsten ist: Ein Angriff über Prompt Injection verliert seine wirksamsten Ziele.

8:07 Wenn der Agent für seinen aktuellen Auftrag gar keine löschende Operation zur Verfügung hat, läuft jede noch so geschickte Anweisung in einem fremden Dokument ins Leere. Das ist die wirksamste Verteidigung, die wir in diesem Seminar besprechen — und sie besteht nicht aus einer Prüfung, sondern aus einer Abwesenheit. Der erste Punkt hebt den Nutzen der Zwischenklasse gleich wieder auf: Ein vorbereitendes Werkzeug führt die Änderung gleich mit aus, weil es praktischer schien.

8:33 Der dritte ist der, der im Audit auffällt: Die Klasse steht in der Dokumentation, aber nicht in der Berechtigung. Und der vierte ist der Normalzustand in vielen Projekten und die Grundlage der meisten Sicherheitsprobleme, über die wir an Tag drei reden: Alle Werkzeuge laufen unter derselben Dienstidentität.

Übung

8:50 Zum Abschluss machen wir aus einer schlecht geschnittenen Sammlung einen brauchbaren Katalog. Der Tool-Katalog ist ein Arbeitsergebnis, das Sie über das Seminar hinaus begleitet: eine Liste der Operationen mit Schema, Berechtigungsbedarf und Risikoklasse. In Modul 16 wird daraus das Scope-Design, in Modul 17 ein Teil der Betriebscheckliste. Es lohnt sich also, ihn ordentlich zu machen — Sie brauchen ihn noch zweimal.

9:16 Sie bekommen drei bewusst schlecht entworfene Werkzeuge: ein Verwaltungswerkzeug mit Aktionsparameter, einen allgemeinen Dateizugriff und eine freie SQL-Ausführung. Daraus sollen mindestens acht Operationen entstehen, jede mit Name, Eingabeschema, Klasse und nötiger Berechtigung. Achten Sie besonders auf das dritte Werkzeug — es ist das, bei dem die Zerlegung am meisten wehtut und am meisten bringt.

9:40 Der erste Punkt ist der, den ich bei dieser Übung am häufigsten sehe: Die Zerlegung halbiert nur, statt die Absichten zu trennen. Aus einem Werkzeug werden zwei, und beide können immer noch zu viel. Der zweite ist die Versuchung, der man widerstehen muss: Die freie SQL-Ausführung bleibt bestehen, weil sie so praktisch ist.

9:59 Sie ist das Universalwerkzeug in Reinform — alles, was die Datenbank kann, ohne jede Zusicherung. Im nächsten Modul geht es darum, die Operationen auch unter Last brauchbar zu halten.