# Host- und Client-Integration: Kontrolle über Servergrenzen

> Entwirf MCP-Hosts und Clients so, dass Consent, Kontext, Sessions, Roots und mehrere Server kontrollierbar bleiben.

Track: [MCP Engineering](https://physar.tech/learn/mcp-engineering)  
Kanonische Fassung: https://physar.tech/learn/mcp-engineering/host-client-integration  
Stand: 2026-07-25  
Interaktiver Teil: 10 Checks (nur im Browser)

## MCP-Host und Clients integrieren: Kontrolle bleibt beim Produkt

### 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 |

> **Merksatz:** Ein Server darf Fähigkeiten **anbieten**. Der Host entscheidet, ob sie für diesen Nutzer, diese Aufgabe und diesen Moment nutzbar sind.

### 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.

_[Abbildung: Der Host kontrolliert Kontext, Sichtbarkeit und Freigabe zwischen Nutzer, Modell und externen MCP-Servern.]_

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

> **Nicht verwechseln:** Ein gemeinsamer Trace hilft bei der Diagnose. Ein gemeinsamer Gesprächs- oder Serverkontext würde die Isolationsgrenze aufheben.

### 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 |

> **Trade-off:** `stdio` reduziert die Netzwerkfläche, macht aber Prozess- und Dependency-Management zur Host-Aufgabe. HTTP entkoppelt Betrieb, erweitert aber die Angriffs- und Ausfallgrenzen.

### 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

> **Rekonstruktion statt Erinnerung:** Nach einer abgebrochenen oder beendeten Session wird nicht blind lokaler Zwischenzustand wiederverwendet. Der Host startet die vorgeschriebene Initialisierung neu und prüft den nun geltenden Vertrag.

### 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.

> **Betriebsregel:** Wiederverbinden stellt die Kommunikation wieder her. Es beweist nicht, dass ein vorheriger Request fehlgeschlagen oder sicher wiederholbar ist.

### 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 |

> **Grenze:** Eine Root ist eine vom Host kommunizierte Zugriffsbeschränkung. Sie ersetzt keine serverseitige Pfad- und Berechtigungsprüfung.

### 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

> **Kein Vertrauens-Upgrade:** Eine erfolgreiche MCP-Übertragung macht Inhalt nicht wahr, sicher oder handlungsleitend. Sie belegt nur, von welchem Server der Host ihn empfangen hat.

### 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 |

> **Komposition:** Komponierbarkeit bedeutet nicht Gleichbehandlung. Mehr Server erhöhen die Wahlmöglichkeiten und gleichzeitig die Pflicht zur eindeutigen Zuordnung.

### 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.

> **UX ist Sicherheitskontrolle:** Eine Freigabe ist nur sinnvoll, wenn Nutzer Ursprung, Wirkung und Zeitpunkt der Entscheidung erkennen können.

### 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.

> **Für die Checks:** Achte jeweils auf die fehlende Grenze: Zuständigkeit, Serveridentität, Session, Dateisystem, Modellkontext, Föderation oder menschliche Entscheidung.

## Quellen

- modelcontextprotocol.io/specification/2025-11-25/architecture — https://modelcontextprotocol.io/specification/2025-11-25/architecture
- modelcontextprotocol.io/specification/2025-11-25/basic/lifecycle — https://modelcontextprotocol.io/specification/2025-11-25/basic/lifecycle
- modelcontextprotocol.io/specification/2025-11-25/basic/transports — https://modelcontextprotocol.io/specification/2025-11-25/basic/transports
- modelcontextprotocol.io/specification/2025-11-25/client/roots — https://modelcontextprotocol.io/specification/2025-11-25/client/roots
- modelcontextprotocol.io/docs/tutorials/securit…urity_best_practices — https://modelcontextprotocol.io/docs/tutorials/security/security_best_practices