FACT COPY · DE
Faktenfassung: MCP-Clients: Protokollrolle, Kontextsteuerung und Nutzerkontrolle
Vertiefende Analyse von MCP-Clients, Hostgrenzen, Discovery, Tool-Auswahl, Sampling, Elicitation und Governance.
Originalseite: https://travel-mcp.com/de/mcp-clients/
Sachliche Zusammenfassung
Ein MCP-Client ist die Protokollinstanz zwischen Host und Server. Seine Qualität entscheidet darüber, welche Fähigkeiten ein Modell sieht, wie Nutzer sensible Aktionen kontrollieren und ob Daten zwischen Vertrauensdomänen sauber getrennt bleiben.
1. Host und Client sind nicht dasselbe
Der Host ist das Produkt mit Modell, UI und Nutzerkontext. Er erzeugt typischerweise einen Client pro Serververbindung. Diese Trennung isoliert Sessions, Capabilities und Berechtigungen.
Ein Host kann viele Clients verwalten und Ergebnisse orchestrieren. Der einzelne Client sollte nicht eigenmächtig Daten eines Servers an einen anderen weitergeben.
2. Initialisierung und Discovery
Der Client initiiert den Lifecycle, bietet eine Protokollversion an und erklärt eigene Capabilities. Nach erfolgreicher Aushandlung listet er Tools, Ressourcen und Prompts, soweit angekündigt.
List-Changed-Notifications halten Angebote aktuell. Neue Tools dürfen in Unternehmensumgebungen trotzdem einer Administrator- oder Policyfreigabe unterliegen.
3. Kontext- und Toolselektion
Hunderte vollständige Toolschemas im Modellkontext erhöhen Kosten und Fehlwahl. Clients sollten nach Rolle, Aufgabe und Vertrauen filtern oder Tool-Suche nutzen.
Auswahlqualität wird evaluiert: passende Tools, falsche positive Auswahl, unnötige Aufrufe und Parameterkorrekturen. Eine lange Capability-Liste ist kein Qualitätsmerkmal.
4. Nutzerfreigaben
Vor sensiblen Aktionen zeigt der Client Zielsystem, Daten, Wirkung, Preis oder Bedingungen. Eine Zustimmung gilt für den konkreten Zustand und die konkrete Operation.
Pauschale Einwilligung in ‚Tool-Nutzung‘ reicht nicht für Zahlung, Buchung oder Veröffentlichung. Der Server autorisiert zusätzlich unabhängig.
5. Sampling
Sampling erlaubt Servern, Modellgenerierung über den Client anzufordern. Dadurch bleiben Modellauswahl und Credentials beim Host. Die Spezifikation unterstützt auch Toolnutzung innerhalb von Sampling.
Der Client kontrolliert Modelle, Kosten, Kontextweitergabe und Nutzertransparenz. Ein Server darf Sampling nicht als Weg verwenden, Datenkontrollen des Hosts zu umgehen.
6. Elicitation
Elicitation erlaubt einem Server zusätzliche Nutzereingaben. Form Mode sammelt nicht-sensitive strukturierte Daten; URL Mode verlagert sensible Vorgänge in einen sicheren externen Flow.
Passwörter, Tokens oder Zahlungscredentials dürfen nicht über Form Mode abgefragt werden. Nutzer müssen Herkunft, Zweck, Ziel-URL sowie Accept-, Decline- und Cancel-Optionen erkennen.
7. Roots und lokale Grenzen
Roots beschreiben relevante Dateisystemgrenzen, die ein Client dem Server bereitstellt. Sie sind Kontext und keine alleinige Sandbox. Der Server darf nicht annehmen, dass jeder Pfad unter einem Root automatisch zulässig ist.
Lokale Server laufen häufig mit Benutzerrechten. Prozesssandbox, explizite Verzeichnisse und minimale Umgebungsvariablen begrenzen Schäden.
8. Client-Governance
Unternehmen regeln zulässige Server, Versionen, Publisher, Scopes, Modelle und Datenklassen. Dynamische Discovery benötigt Allowlisting und Herkunftsinformation.
Telemetrie misst Auswahl, Freigaben, Ablehnungen, Latenz und Kosten. Sie muss datensparsam bleiben und darf keine verdeckte Überwachung von Nutzerprompts erzeugen.
FAQ
Unterstützt jeder Client alle MCP-Funktionen?
Nein. Capabilities werden ausgehandelt und Produktunterstützung variiert. Eine Supportmatrix ist Teil der Einführung.
Warum ein Client pro Server?
Damit Sessions, Sicherheitskontexte und Serverzustände isoliert bleiben.