Sampling — die Rück-Richtung
Bislang ging der Pfeil immer in eine Richtung: Client → Server. Sampling dreht ihn um — der Server fragt den Client, ob er für ihn das LLM laufen lassen würde. Eine elegante Lösung, die LLM-Kosten an einer Stelle bündelt und Server LLM-frei lässt.
Warum überhaupt? Stell dir vor, ein MCP-Server für ein Bug-Tracker-System will ankommende Tickets klassifizieren. Er bräuchte dafür ein LLM — aber dann müsste der Server-Anbieter eigene API-Keys verwalten, eigene Inferenz-Kosten tragen. Mit Sampling sagt er stattdessen: „hey Client, lass mich kurz dein LLM nutzen, hier sind die Messages.“
Der Flow
Was modelPreferences bedeutet
- hints — Name-Patterns („claude-3-5", „gpt-4"), die der Server gerne hätte. Der Client mappt sie auf das, was er hat.
- costPriority (0..1) — wie wichtig ist günstig? Hoch = nimm das billigste Modell, das die Aufgabe wahrscheinlich schafft.
- speedPriority (0..1) — wie wichtig ist schnell?
- intelligencePriority (0..1) — wie wichtig ist Schärfe? Hoch = nimm das größte Modell, das du hast.
Der Client gewichtet das alles und entscheidet selbst — ein Server hat keinen Anspruch auf ein bestimmtes Modell.
Warum eigentlich? — Warum nicht einfach selbst ein LLM laufen lassen?
Drei Gründe. Kosten: ein Server für 1000 Nutzer müsste 1000 Inferenz-Kontingente haben — der Client hat eines. Schlüssel-Verwaltung: jeder Server bräuchte eigene API-Keys, eigene Abrechnung. Konsistenz: der Nutzer hat sich für ein Modell entschieden (Claude, GPT, lokal); der Server soll diese Wahl respektieren statt ein zweites Modell ins Spiel zu bringen.
Häufiger Denkfehler — Sampling ohne Nutzer-Sichtbarkeit
Ein Server könnte 100 sampling/createMessage-Calls hintereinander schicken und stille Kosten produzieren. Ein guter Client zeigt jede Sampling-Anfrage zumindest als Counter („3 Sampling-Calls seit Verbindung") — bei sensiblen Domains besser als Modal mit Approval. Ohne diese Bremse hat ein bösartiger Server eine Hebelwirkung auf den Geldbeutel des Nutzers.
Tiefer rein — Wann statt eigenem LLM, wann nicht
Sampling lohnt sich für kontextbezogene Inferenz — der Server hat Kontext, den der Client nicht hat (z.B. Tickets, DB-Zeilen). Sampling lohnt sich nicht, wenn der Server eine sehr spezifische Inferenz braucht (z.B. fine-tuned auf seine Domain) — da ist eigenes Hosting besser. Heuristik: General-Purpose-Aufgabe → Sampling. Spezial-Aufgabe → eigenes Modell.