MCP-Host und Clients integrieren: Kontrolle bleibt beim Produkt
Einführung · 10 Abschnitte · ~12 Min Lesezeit · Stand
Der Host ist Produktgrenze, nicht bloß ein Verbindungspool
Ein MCP-Host ist die Anwendung, in der Nutzer arbeiten. Er erzeugt Clients, verbindet sie mit Servern, aggregiert Kontext und koordiniert die Modellnutzung. Damit besitzt der Host die Entscheidungen, die ein Server nicht sicher für das Produkt treffen kann: welchen Server ein Nutzer verbinden darf, welche Fähigkeiten sichtbar werden, wann Zustimmung nötig ist und was in Modellkontext gelangt.
| Host | Produktpolitik, Nutzer-Consent, Client-Lifecycle und Kontextaggregation |
|---|---|
| Client | Eine zustandsbehaftete Verbindung zu genau einem Server; verhandelt Version und Capabilities |
| Server | Bietet abgegrenzte MCP-Fähigkeiten; kennt weder die gesamte Unterhaltung noch andere Server |
Isolation ist eine Eigenschaft des Datenflusses
Ein Host kann mehrere Clients führen, aber jeder Client hat eine Eins-zu-eins-Beziehung zu einem bestimmten Server. Das ist mehr als eine Strukturfrage: Server sollen weder die vollständige Unterhaltung noch die Inhalte anderer Server sehen. Verbindungs-, Nutzer-, Tenant- und Request-Identität müssen deshalb am Host und Client korrelierbar sein, ohne Daten zwischen Servern zu vermischen.
- Nutzeraktion erhält eine Host-Request-ID
- Host wählt einen zugelassenen Server
- Zugeordneter Client sendet den MCP-Request
- Antwort bleibt mit Server- und Request-Identität markiert
- Host filtert und integriert nur den erlaubten Anteil
Transport ist zugleich eine Betreiber- und Vertrauensentscheidung
stdio verbindet einen vom Client gestarteten lokalen Child-Prozess über Standard-Ein- und -Ausgabe. Der Host kontrolliert damit Start, Umgebung und Ende des Prozesses eng. Streamable HTTP verbindet dagegen einen eigenständigen Dienst, der mehrere Client-Verbindungen bedienen kann. Das schafft eine klare Netzwerk- und Betreibergrenze, verlangt aber ausdrücklich Erreichbarkeit, Authentisierung, Origin-Prüfung, Session-Handling und eine verantwortliche Betriebsseite.
| Lokaler, aufgabenbezogener Prozess | stdio: Prozessstart und lokale Umgebung liegen beim Host; stdout bleibt ausschließlich MCP-Nachrichten vorbehalten |
|---|---|
| Geteilter oder fern betriebener Dienst | Streamable HTTP: unabhängiger Operator, Netzwerk-Policy, Authentisierung und Session-Grenzen werden Teil des Integrationsvertrags |
Eine Session beginnt mit Verhandlung, nicht mit einem Tool-Call
Die erste Interaktion einer MCP-Verbindung ist die Initialisierung. Client und Server einigen sich auf eine Protokollversion, deklarieren Capabilities und erst danach beginnt der normale Betrieb. Der Client ruft keine optionale Fähigkeit auf, nur weil sie in einer anderen Integration vorhanden war. Er benutzt ausschließlich das, was diese Session ausgehandelt hat.
- Verbindung aufbauen
- `initialize` mit Client-Capabilities senden
- Serverversion und Server-Capabilities prüfen
- `initialized` senden
- Nur ausgehandelte Funktionen verwenden
- Bei Ende Transport schließen und Ressourcen freigeben
HTTP-Sessions und Wiederverbindungen brauchen eigene Regeln
Ein Streamable-HTTP-Server kann bei der Initialisierung eine Session-ID vergeben. Der Client sendet sie anschließend mit den Requests; beendet der Server diese Session, muss der Client eine neue Initialisierung beginnen. Eine Netzwerkunterbrechung bedeutet dabei nicht automatisch, dass eine fachliche Aktion abgebrochen wurde. Abbruch ist ein eigenes Protokollsignal; bei Wiederaufnahme dürfen nur Nachrichten des zugehörigen Streams rekonstruiert werden.
- Cleanup planen: lokale Streams, Timeouts, Abbrüche und Host-Ressourcen beim Beenden freigeben.
- Keine implizite Wiederholung: einen nicht bestätigten Seiteneffekt nicht nach Verbindungsverlust erneut auslösen.
- Neu verhandeln: nach einer verlorenen Session Version, Capability-Set und Session-Zustand erneut prüfen.
Roots sind vom Host gewährte Arbeitsgrenzen
Roots sind Dateisystembereiche, die ein unterstützender Client einem Server offenlegt. Sie sind nicht bloß Komfort-Metadaten: Der Host darf nur Roots mit angemessenen Berechtigungen anbieten, braucht eine sichtbare Nutzerentscheidung und überwacht ihre Erreichbarkeit. Ein Server prüft zunächst die Roots-Capability, respektiert die angegebenen Grenzen und behandelt fehlende oder veränderte Roots als normalen Fall.
| Host oder Client | Exponiert nur freigegebene, valide Roots und signalisiert Änderungen, wenn dies ausgehandelt ist |
|---|---|
| Server | Fragt Roots nur bei unterstützter Capability ab, validiert Pfade gegen die Roots und reagiert auf Änderungen oder Nichtverfügbarkeit |
| Modell | Erhält keinen impliziten Dateisystemzugriff aus einer Root-Anzeige |
Kontextaggregation ist eine Host-Policy
Resource-Inhalte, Tool-Ergebnisse und Server-Instructions sind Eingaben über eine Vertrauensgrenze. Ein gutes Host-Design entscheidet vor dem Modellaufruf, welche Ergebnisse relevant sind, wie groß sie sein dürfen, welcher Herkunft sie zugeordnet werden und ob sensible Felder entfernt werden. Der Server liefert Kontext; er steuert nicht selbst, welchen Anteil der Unterhaltung oder welche fremden Ergebnisse er erhält.
- Serverantwort empfangen
- Herkunft und Server-Policy prüfen
- Größe, Typ und sensible Felder begrenzen
- Inhalt als untrusted kennzeichnen
- Nur aufgabenrelevanten Ausschnitt in Modellkontext übernehmen
- Modellvorschlag gegen Host-Policy ausführen oder ablehnen
Mehrere Server werden föderiert, nicht zusammengeschüttet
Mit mehreren Servern entstehen gleichnamige Tools, unterschiedliche Datenklassifikationen, getrennte Betriebsverantwortungen und wechselnde Capability-Listen. Ein Host führt daher eine stabile Zuordnung aus Serveridentität, Capability und lokaler Produkt-Policy. Für Modell und Nutzer müssen Tool-Namen, Herkunft und Freigabebedingungen eindeutig bleiben; eine unqualifizierte, gemeinsame Tool-Liste verwischt diese Grenze.
| Tool-Kollision | Mit stabiler Server-Qualifikation oder bewusstem Produktalias auflösen; Herkunft bleibt sichtbar |
|---|---|
| Unterschiedliche Trust-Level | Pro Server getrennte Allowlist, Kontextbegrenzung und Freigaberegel anwenden |
| Capability-Änderung | Neu entdecken, Policy erneut anwenden und nicht alte Tool-Annahmen behalten |
Menschliche Kontrolle ist eine konkrete Interaktion
Ein Host wahrt menschliche Kontrolle nicht mit einer allgemeinen Einstellung, sondern im richtigen Moment: vor einer riskanten Tool-Aktion, bei einer vom Server angefragten Interaktion, während länger laufender Arbeit und beim Abbruch. Die Oberfläche zeigt verständlich, welcher Server welche Aktion mit welchen Auswirkungen anfragt. Sie stellt Freigabe, Ablehnung, Fortschritt und Abbruch dem Nutzer zur Verfügung, ohne die Entscheidung im Server oder Modell zu verstecken.
- Vor Aktion: Serverherkunft, Wirkung und relevante Parameter sichtbar machen.
- Während Aktion: Fortschritt einem konkreten Request zuordnen und einen Abbruchpfad anbieten.
- Nach Aktion: Ergebnis, Fehler oder unklare Ausführung so anzeigen, dass kein falscher Erfolg suggeriert wird.
Die acht Integrationsentscheidungen im Überblick
Dieses Modul behandelt die Host-Seite der MCP-Integration. Es wiederholt weder allgemeines Agenten-Tool-Design noch eine vollständige Autorisierungsimplementierung. Stattdessen entscheidest du, wer die Produktkontrolle trägt, wie Server isoliert bleiben, welche Transport- und Session-Grenze passt, wie Roots und Kontext begrenzt werden, wie mehrere Server eindeutig bleiben und wie Nutzer sichtbar eingreifen.
- Eigentum: Consent, Lifecycle und Kontextpolicy bleiben beim Host.
- Isolation: ein Client pro Server und identitätskorrelierte Datenflüsse verhindern Vermischung.
- Kontrolle: Serverantworten, Capabilities und Nutzerinteraktionen erhalten erst durch Host-Policy ihre Wirkung.