Kapitel 3 — Server-Primitives: Kontext und Fähigkeiten freigeben

Dritter Beitrag der kapitelweisen Tour durch LLM Primer IV: Designing AI Cognition with MCP. Darin: wir lernen, was ein MCP-Server tatsächlich sagen kann — drei Nomen, drei Lebenszyklen, drei Fehlermodelle — und warum die Disziplin, das richtige zu wählen, darüber entscheidet, ob ein Server skaliert oder anwächst.

Warum dieses Kapitel existiert

Ein Protokoll ist nur so nützlich wie die Dinge, die es dich sagen lässt. Kapitel 2 baute das mentale Modell aus Host, Client und Server und ließ eine Session über die Capability-Verhandlung lebendig werden. Sobald der Handshake abgeschlossen ist und beide Seiten wissen, was die andere kann, was liegt dann konkret auf dem Tisch? MCP antwortet mit drei Nomen: Resources, Prompts und Tools. Sie sehen oberflächlich ähnlich aus — jedes ist eine benannte, durch ein Schema beschriebene Sache, die der Server erzeugen oder ausführen kann — aber sie zielen auf drei unterschiedliche Absichten. Resources sind Lesezustand. Prompts sind wiederverwendbares Gerüst. Tools sind Schreibaktionen. Das Kapitel geht jedes durch: Schema, Lebenszyklus, Fehlermodell und die Stellen, an denen Entwickler es falsch machen.

3.1 Resources: read-only Kontextdaten

Eine Resource sind Daten, die der Server dem Modell als Kontext überreichen kann. Das definierende Wort ist read-only. Eine Resource verändert die Welt nicht; sie beschreibt sie. Wenn ein Abruf irgendwo eine Zustandsänderung auslöst — eine Audit-Log-Zeile, einen erhöhten Zähler, einen abgefeuerten Webhook — ist es keine Resource, sondern ein Tool im Kostüm. Diese Linie scharf zu ziehen ist die erste Disziplin im MCP-Server-Design.

Jede Resource hat eine stabile URI in einem Schema, das der Server wählt (file://, postgres://, linear://issue/ENG-1234), dazu Metadaten: Name, optionale Beschreibung, MIME-Type, optionale Größe. Keines dieser Felder ist Dekoration. Eine Resource ohne Beschreibung ist eine, die das Modell nicht bewerten kann. Der Lebenszyklus ist schlicht: resources/list zum Aufzählen, resources/read zum Holen. Es gibt kein resources/write — will der Server Schreibvorgänge, muss er ein Tool exponieren. Die Asymmetrie hält die Vertrauensgrenze sichtbar.

Zwei Muster machen Resources im Maßstab praktikabel. URI-Templates erlauben dem Server, einen parametrisierten Leseendpunkt freizugeben (db://orders/{order_id}), statt Millionen Zeilen aufzuzählen. Subskriptionen lassen den Host Interesse an einer URI registrieren und notifications/resources/updated empfangen, wenn sich die zugrundeliegenden Daten ändern — die Alternative wäre Polling im LLM-Takt, was in beide Richtungen verschwenderisch ist. Die Falle: nicht jedes interne Objekt beim Sessionstart auf die Resource-Liste schütten. Eine Liste von dreitausend Resources verbraucht Zehntausende Tokens, bevor die Nutzerin etwas getippt hat. Gib eine kuratierte oberste Ebene plus Templates und lass das Modell den langen Schwanz durchsuchen.

3.2 Prompts: wiederverwendbare Vorlagen und Workflows

Prompts in MCP haben nichts mit dem System-Prompt eines LLM zu tun. Sie sind wiederverwendbare, vom Server definierte Vorlagen, die eine Nutzerin — oder ein Host in ihrem Namen — aufrufen kann, um eine bestimmte Interaktion zu starten. Ein Prompt ist näher an einem Slash-Befehl als an einer Persönlichkeit. Der Punkt ist, dem Server zu erlauben, neben den Tools und Resources, die er anbietet, auch erprobte Interaktionsmuster auszuliefern, sodass der Mensch am Keyboard sich die Formulierung nicht merken muss.

Ein Prompt hat einen Namen, eine optionale Beschreibung und eine Liste von Argumenten. Der Host ruft prompts/list zur Entdeckung, dann prompts/get, um den Prompt in eine Folge von Nachrichten zu expandieren, die der Host in seine Modellschleife einspeist. Der Prompt darf Resources per URI referenzieren; der Host fügt sie vor dem Senden inline ein. Der Server skriptet die ersten Turns; das Modell übernimmt von dort.

Die Trennung zwischen Prompts und System-Nachrichten zählt. Ruft eine Nutzerin /review_pr auf, sieht sie im Konversationslog, wie der Assistent ein Review beginnt — sie versteht, was gestartet ist, sie kann unterbrechen, sie kann nachprüfen. Hätte der Server stattdessen still Anweisungen an den System-Prompt des Hosts angehängt, wüsste die Nutzerin nicht, warum der Assistent plötzlich anders agiert. Prompts sind nutzersichtbares Gerüst; System-Prompts sind der Rahmen des Hosts. Beide zu vermischen ist ein Designfehler. Die Disziplin: jeder Prompt-Inhalt, den die Nutzerin nicht freigeben würde, wenn er ihr explizit gezeigt würde, ist ein Defekt.

3.3 Tools: Aktionen, strukturierte Ausgaben, Idempotenz

Tools sind die Stelle, an der MCP zugleich interessant und gefährlich wird. Resources sind Lesen; Prompts sind Gerüst; Tools sind Schreiben — sie erzeugen Zeilen, versenden Nachrichten, deployen Dienste, belasten Karten. Jedes Tool hat einen Namen, eine Beschreibung und ein Input-Schema in JSON Schema. Die Beschreibung ist das wichtigste Feld auf der gesamten MCP-Oberfläche, weil sie der Text ist, mit dem das Modell entscheidet, ob es das Tool aufruft, wann und mit welchen Argumenten. Ein Tool, dessen Beschreibung „sendet eine E-Mail" sagt, ruft das Modell überall dort auf, wo eine mailförmige Intention auftaucht. Ein Tool, dessen Beschreibung „sendet eine transaktionale E-Mail über die Marketing-Plattform, nur an verifizierte Kundenadressen; nicht für persönliche Korrespondenz" sagt, nutzt das Modell deutlich diskriminierter.

Das Fehlermodell hat zwei Kanäle. Ein Protokollfehler (fehlerhafte Argumente, unbekanntes Tool) liefert einen JSON-RPC-Fehler und ist ein Framing-Fehler. Ein Tool-Fehler (Empfänger abgewiesen, Platte voll) liefert eine erfolgreiche Antwort mit isError: true und einem Content-Block, der erklärt, was passiert ist. Der Unterschied zählt: das Modell soll Tool-Fehler sehen und sich anpassen; der Host soll Protokollfehler sehen und den Transport reparieren. Beide zu vermischen nimmt dem Modell die Information, die es braucht.

Modernes MCP unterstützt structuredContent neben dem prosaischen Content-Array, konform zu einem deklarierten outputSchema. Der zinseszinsartige Effekt über einen langen Trace ist real: kurze, strukturierte Tool-Ausgaben lassen dem Modell Platz für echtes Reasoning; lange, prosaische Ausgaben fressen das Kontextbudget. Zwei weitere Disziplinen verdienen Namen. Minimalität: zwölf gut beschriebene Tools schlagen sechzig in fast jedem Benchmark; exponiere find_users mit strukturiertem Filter statt list_users, get_user, search_users, count_users. Idempotenz: Retry-Stürme sind unvermeidlich; ein Tool, das einen Idempotency-Key akzeptiert oder ein deterministisches Identifikator-Schema verwendet, macht aus Netzaussetzern No-Ops statt Datenintegritätsvorfällen.

3.4 Komposition: wie die drei Primitiven zusammenspielen

Die Primitiven sind am nützlichsten, wenn sie zusammen arbeiten. Ein gut entworfener Server bietet typischerweise von jedem etwas: ein paar Prompts, um häufige Interaktionen zu starten, eine kleine Menge Tools für die Aktionen, die zählen, und eine womöglich große Menge Resources, die den Kontext liefern. Ein Support-Server könnte Kundendaten und Ticket-Historie als Resources, reply_to_ticket und escalate_ticket als Tools und /triage_ticket als Prompt anbieten, der die richtigen Resources lädt und das Modell zur Klassifikation auffordert. Prompts säen; Resources füllen die Lage; Tools verändern die Welt.

Die Versuchung, sobald du die Flexibilität der Primitiven siehst, ist, alles durch eines zu pressen. Resources lassen sich mit read-only Tools faken, Tools mit Prompts, die das Modell zur Ausgabe von Befehlen schubsen, Prompts mit Resources, die Anweisungen enthalten. Jede Kompression schrumpft den Designraum und verliert etwas. Resources, die du als Tools gefaked hast, lassen sich nicht cachen, abonnieren oder in eine Prompt-Expansion einfügen. Tools, die du als Prompts gefaked hast, lassen sich am Aufrufpunkt nicht autorisieren und haben keinen strukturierten Ausgabekanal. Die Primitiven sind nicht willkürlich; sie sind so faktoriert, dass der Host weiß, wie er jedes sicher behandelt. Diese Faktorisierung zu ehren, ist Teil des Protokollvertrags.

Was Kapitel 3 vorbereitet

Du hast die Server-Seite des Bargains gegangen. Ein Server gibt Resources, Prompts und Tools frei, jedes mit eigenem Schema, Lebenszyklus und Fehlermodell. Die Disziplin liegt darin, für jede Sache, die der Server tun kann, das richtige Primitiv zu wählen, sie sorgfältig zu benennen und zu beschreiben und Überladung zu widerstehen. Aber MCP ist keine Einbahnstraße. Auch ein Host kann Capabilities an den Server zurückgeben — und genau dort leben die interessantesten und sicherheitsempfindlichsten Designentscheidungen des Protokolls.

Als Nächstes — Kapitel 4: Client-Primitives — Sampling, Roots, Elicitation. Die umgekehrte Fläche — was der Host an den Server zurückgibt — und die Sicherheitsimplikationen jeder Capability, die über die Vertrauensgrenze hinweg geliehen wird.