Kapitel 4 — Client-Primitives: Agentisches Verhalten und Kontrolle

Vierter Beitrag der kapitelweisen Tour durch LLM Primer IV: Designing AI Cognition with MCP. Server-Primitives geben frei, was der Server anbietet; Client-Primitives geben frei, was der Host zurückleiht — und jede Leihe ist eine Capability, die die Nutzerin gewährt, und ein Risiko, das der Host akzeptiert.

Warum dieses Kapitel existiert

Ein Server, der nur Resources, Prompts und Tools freigibt, weiß nichts über seinen Host: nicht das Modell, das er fährt, nicht die Dateien, die er sehen kann, nicht einmal, ob die Nutzerin am Keyboard sitzt. Für viele Integrationen ist diese Wand Absicht. Für ganze Klassen nützlichen Verhaltens ist sie zu hoch. Ein Server, der ein langes Dokument zusammenfassen muss, sollte nicht sein eigenes LLM mitliefern müssen. Ein Server, der an einem Projekt arbeiten will, sollte wissen, welches. Ein Server, der die Erlaubnis der Nutzerin für einen zerstörerischen Schritt braucht, sollte sie erbitten dürfen. Client-Primitives sind die Art, wie MCP kleine, kontrollierte Öffnungen in die Wand schneidet.

Die drei Primitive — Sampling, Roots, Elicitation — erweitern die Reichweite des Servers jeweils präzise und verhandelt in das Territorium des Hosts. Jedes ist auch eine Sicherheitsfläche, die der Host im Namen seiner Nutzerin akzeptiert, und jedes komponiert mit den anderen zu Verhalten, das agentischer ist als die Summe der Teile.

In einem Satz: Sampling lässt den Server das Modell des Hosts nutzen, Roots sagen dem Server, in welchem Scope er arbeitet, und Elicitation lässt den Server der Nutzerin eine Frage stellen — jede eine bewusste Leihe, jede ein bewusstes Risiko.

4.1 Sampling: das Hirn des Hosts ausleihen

Mit aktiviertem Sampling kann ein Server den Host bitten, einen Inferenzaufruf zu fahren und das Ergebnis zurückzugeben. Er liefert kein Modell mit, hält keinen API-Key und erfährt nie, welches Modell der Host tatsächlich verwendet hat — er schickt Nachrichten plus weiche Präferenzen (Kosten, Geschwindigkeit, Intelligenz), und der Host fährt den Aufruf. Aus der Sicht des Servers ist der Host zu einem generischen LLM-Endpunkt geworden.

Der Hebel ist real. Ein Document-Store-Server kann kleine Reasoning-Schritte innerhalb seiner eigenen Logik fahren — abrufen, ranken, vergleichen — ohne Fachwissen an den Host zu lecken oder selbst Inferenz mitzuliefern. Das Risiko ist genauso real. Ein bösartiger Server kann das Modell des Hosts — und das Budget der Nutzerin — nutzen, um Arbeit zu erledigen, die die Nutzerin nie genehmigt hat. Der klassische Angriff ist eine Sampling-Payload, die als Nutzeranweisung verkleidet ist. Der Host ist die einzige Verteidigungslinie, weshalb reife Hosts Sampling defaultmäßig ablehnen, sofern die Nutzerin sich nicht für genau diesen Server eingewählt hat, jeden Aufruf zur Inspektion sichtbar machen, Aufrufe pro Session deckeln und Kosten am Wallet der Nutzerin messen, nicht am Wallet des Servers.

Eine subtilere Sorge: Sampling kann eine interne agentische Schleife einkapseln. Aus Sicht des Hosts sieht es nach einem Sampling-Aufruf aus; im Server hat ein ganzer Sub-Agent gelaufen. Das Muster, das Namen verdient, ist der begrenzte Sub-Agent — die Nutzerin gewährt ein Budget von N Aufrufen, T Sekunden, X Dollar; der Server fährt, was er mag, innerhalb dieses Umschlags und liefert entweder ein Ergebnis oder eine elegante Teilantwort. Sampling gibt dem Server auch keinen Zugriff auf die Konversation; er sieht nur, was er geschickt hat, und ein Host, der Konversationskontext in Sampling-Payloads schmuggelt, hat die Vertrauensgrenze unabhängig von der Absicht geschwächt.

4.2 Roots: Dateisystemgrenzen und Projektscope

Ein Root ist eine URI — meist file://, obwohl die Spec allgemeiner ist — die der Host als im Scope deklariert hat. Der Server ruft roots/list auf und fragt „womit arbeite ich?" Der Host bewirbt bei der Initialisierung eine roots-Capability und emittiert notifications/roots/list_changed, wenn die Nutzerin das Projekt wechselt. Die Liste ist nur eine Liste; es gibt keine geschachtelte Berechtigungssprache, keine Glob-Muster, keine Include/Exclude-Regeln.

Die Grobkörnigkeit ist Absicht und spiegelt eine MCP-weite Designentscheidung, die du verstehen solltest. Eine feinkörnige Berechtigungssprache auf der Protokollebene erzeugt ein falsches Gefühl von Sicherheit: Nutzer lesen eine lange Scope-Liste und nehmen an, das Protokoll setze sie durch, obwohl es nicht verhindern kann, dass der Server in Weisen fehlgeht, an die die Sprache nie gedacht hat. Ein grobes Primitiv, abgesichert durch externe Isolation — Prozessgrenzen, Container-Mounts, OS-Zugriffskontrolle — ist ehrlich darüber, wo Durchsetzung tatsächlich lebt. Roots sind ein Ehrensystem auf der Protokollebene, durchsetzbar gemacht auf der Laufzeitebene, wenn Sandboxing im Spiel ist.

Zwei praktische Folgen. Erstens: wechseln die Roots, verwerfen wohlerzogene Server gecachten Zustand, der zum alten Root gehört — Indizes, geparste ASTs, Watch-Subskriptionen — oder Zustand leckt über Projektgrenzen. Zweitens: Roots begrenzen worauf der Server schauen soll, nicht was er tun darf. Eine sensible Datei innerhalb eines gewährten Roots — ein Credential-Dump, ein Envfile, persönliche Korrespondenz — ist immer noch sensibel, und ein höflicher Server übt Urteilsvermögen darüber, was er sichtbar macht.

4.3 Elicitation: den Server fragen lassen

Elicitation ist das jüngste der drei und das, das spiegelt, was Designer aus der ersten Welle von Agentendeployments gelernt haben. Der Server emittiert elicitation/create mit einer Nachricht (der Frage) und einem requestedSchema (der Form der erwarteten Antwort). Der Host rendert die Frage in seinem UI, sammelt die Antwort, validiert sie und liefert sie zurück. Der Server nimmt die Arbeit mit der Antwort in der Hand wieder auf.

Das Schema ist, was Elicitation sicherer macht als ein Freitext-Prompt. Auf einen Booleschen kann man nicht mit Prosa antworten; auf einen Enum nicht mit einer vierten Option. Der Host kann der Nutzerin in klarem UI zeigen, dass sie nach Ja/Nein gefragt wird, und alles andere verweigern. Die Spec beschränkt Schemata bewusst auf flache Objekte aus Primitiven — für echte Formulare nimm ein Tool, dessen Argumentschema das Formular ist, sodass die Nutzerin die ausgefüllten Werte des Modells vor der Ausführung prüfen kann. Elicitation ist für ein- bis zwei-Feld-Fälle.

Das Risikoprofil hat Phishing-Form: ein Server, der „das System verlangt deinen AWS-Access-Key, um fortzufahren" oberflächlich zeigt, versucht, die Nutzerin dazu zu bringen, an der falschen Stelle ein Geheimnis zu tippen. Hosts mildern das mit klarer Zuordnung — jede Elicitation-Aufforderung trägt das Label des Ursprungsservers, getrennt von der Stimme des Assistenten — und indem sie Schemata ablehnen, die credentialförmig aussehen. Die positive Kehrseite ist das Bestätigungsmuster für zerstörerische Tools: die erste Aufgabe eines Tools ist es, „bist du sicher?" zu eliciten, und erst bei Bestätigung handelt es. Das ist eines der wirksamsten MCP-Härtungspraktiken in der Produktion.

4.4 Die drei komponieren

Die Primitiven sind so entworfen, dass sie sich komponieren. Ein Server mit allen dreien hat faktisch eine vollständige Agent-Laufzeit, an den Host delegiert: er kann Scope lesen (Roots), darüber nachdenken (Sampling), klärende Fragen stellen (Elicitation) und über eigene Tools handeln. Die Kombinationen zählen. Sampling plus Roots ist ein autonomer Agentenserver; Sampling plus Elicitation ist ein konversationeller Server ohne Dateisystemreichweite; Roots plus Elicitation ist ein deterministischer Helfer. Jedes für sich ist begrenzt; zusammen multiplizieren sie sich, und das Consent-UI eines Hosts ist am besten, wenn es die Kombination benennen kann, die die Nutzerin gewährt, statt für jede einzeln um Erlaubnis zu bitten.

Wert, das festzuhalten: lies die drei Client-Primitives als eine Frage — wieviel von sich selbst ist der Host bereit, dem Server zu leihen? Sampling leiht das Modell. Roots leihen einen Scope. Elicitation leiht die Aufmerksamkeit der Nutzerin. Jede Leihe wird einzeln verhandelt, sodass Zustimmung bewusst sein kann, und die Aufgabe des Protokolls ist nicht, das Risiko zu entfernen, sondern es lesbar zu machen.

Was Kapitel 4 vorbereitet

Server-Primitives und Client-Primitives zusammen beschreiben alles, was Host und Server einander tun können. Was wir noch nicht behandelt haben: wie irgendetwas davon den Draht entlangfließt. tools/list und sampling/createMessage sind nicht nur abstrakte Nachrichten — sie reiten auf einem Transport, und die Wahl des Transports entscheidet still fast jede operative Eigenschaft einer MCP-Integration. Server müssen auch auffindbar sein: ein Host, der einen Server nutzen will, muss wissen, dass er existiert, wo er lebt und ob er der Behauptung trauen darf. Kapitel 5 nimmt beides auf.

Als Nächstes — Kapitel 5: Transport und Discovery. Die drei Transports, die MCP unterstützt — stdio, SSE, Streamable HTTP — ehrlich verglichen, und die .well-known/mcp.json-plus-Server-Card-Schicht, die aus Punkt-Integrationen etwas macht, das einem Ökosystem ähnelt.

Möchtest du das ganze Bild? Das Buch geht jeden Lebenszyklus, jedes Fehlermodell und jede Risikofläche der Primitiven durch, behandelt das Muster des begrenzten Sub-Agenten tief und legt das tiered-consent-Modell aus, das sich für Hosts etabliert hat, die read-, scoped- und agentische Server verwalten. LLM Primer IV auf Amazon →