Host- und Client-Integration: Kontrolle über Servergrenzen

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, aktive Fähigkeiten und Kontextaggregation

Client

Protokollrolle des Hosts gegenüber einem Server; sendet Metadaten pro Request

Server

Bietet abgegrenzte MCP-Fähigkeiten; kennt weder die gesamte Unterhaltung noch andere Server

Diese Aufteilung verhindert ein bequemes, aber gefährliches Verantwortungsloch. Der Server autorisiert seine eigenen geschützten Daten und Wirkungen, kann jedoch nicht entscheiden, ob das Produkt eine Fähigkeit in diesem Arbeitsraum überhaupt anbieten will. Das Modell schlägt Aufrufe vor, besitzt aber weder Identität noch Policy. Der Host verknüpft beides: Er kennt den angemeldeten Nutzer, den aktuellen Zweck, die Herkunft jeder Capability und die Oberfläche für Zustimmung. Deshalb prüft er vor einem wirkenden Call Server-Allowlist, lokale Risikoklasse, Nutzerrolle und konkrete Parameter. Serverseitige Autorisierung bleibt zusätzlich notwendig; Defense in Depth bedeutet hier zwei verschiedene Entscheidungen, nicht dieselbe Prüfung doppelt.

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.

Isolation muss Cache, Telemetrie und Fehlerpfade einschließen. Ein Resource-Ergebnis für Nutzerin A bleibt auch nach erfolgreicher Übertragung an deren Principal, Tenant, Server und Zweck gebunden. Legt der Host es nur nach URI ab, kann ein späterer Treffer für Nutzer B die ursprüngliche Autorisierung umgehen. Dasselbe gilt für Tool-Aliase und gespeicherte Outputs. Verwende zusammengesetzte Cachekeys, prüfe die aktuelle Policy vor Wiederverwendung und lösche Daten entsprechend ihrer Aufbewahrungsklasse. In Logs darf eine gemeinsame Trace-ID Abläufe verbinden; sensible Inhalte und Tokens werden nicht zur Diagnose kopiert. So entsteht beobachtbare Föderation, ohne Server- oder Nutzergrenzen zu einer gemeinsamen Datenhalde zu machen.

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. HTTP verbindet dagegen einen eigenständigen Dienst, der Requests vieler Clients bedienen kann. Das schafft eine klare Netzwerk- und Betreibergrenze, verlangt aber ausdrücklich Erreichbarkeit, Authentisierung, Origin-Prüfung, stateless Request-Verarbeitung 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

HTTP: unabhängiger Operator, Netzwerk-Policy, Authentisierung und Request-Grenzen werden Teil des Integrationsvertrags

Die Topologie folgt Eigentum und Reichweite. Ein Codeanalysator pro Projektfenster kann als Child-Prozess enden, sobald das Fenster schließt. Ein organisationsweiter Buchungsdienst braucht zentrale Policy, Audit und Widerruf. Betreibe keinen dauerhaften Listener nur für eine hypothetische spätere Integration; jede erreichbare Schnittstelle kostet Härtung. Umgekehrt skaliert ein lokaler Rollout auf Hunderte Geräte nicht kostenlos: Herkunft, Updates, lokale Secrets und Support vervielfachen sich. Dokumentiere daher Betreiber, Updateweg, Principal, Netzwerkpfad und erwarteten Lifecycle zusammen mit der Transportentscheidung. Der Host darf Transport nicht als bloßes SDK-Flag behandeln.

Jeder Request deklariert seinen Protokollkontext

Die Revision 2026-07-28 kennt im Core keinen Initialisierungs-Handshake und keine Protokollsession. Jeder Request nennt seine Protokollversion und die Client-Capabilities in _meta. Der Server antwortet unter dieser Version oder weist eine nicht unterstützte Version kontrolliert zurück. Der Host darf Angaben weder aus dem letzten Request derselben Verbindung noch aus einer anderen Serverintegration übernehmen.

Ein zentraler Request-Builder verhindert inkonsistente Metadaten. Er wählt die unterstützte Version pro Zielserver, bildet nur tatsächlich implementierte Client-Fähigkeiten ab und korreliert Request-ID, Server-ID und Principal für die Antwort. Capabilities sind keine Wunschliste: Deklariert der Client Elicitation, muss der Host die entsprechende Nutzerinteraktion sicher darstellen können. Deklariert er nichts, darf der Server die Funktion in dieser Runde nicht voraussetzen. Tests variieren Capability-Sets parallel über dieselbe Verbindung und prüfen, dass keine Antwort im falschen Arbeitsraum landet. Dadurch wird Statelessness zu einer nachweisbaren Eigenschaft statt zu einer Annahme über das SDK.

Langlebige Requests und Wiederverbindungen brauchen eigene Regeln

Einzelne Requests können trotzdem lange leben, etwa subscriptions/listen. Ein Streamabbruch beendet den Zustellweg, aber nicht rückwirkend jede Fachwirkung oder jede Änderung an der Quelle. Ohne ausdrücklich vereinbarte Replay-Garantie öffnet der Client bei weiterem Interesse einen neuen Listen-Request und synchronisiert betroffene Listen oder Resources aus der autoritativen Quelle. Abbruch ist ein eigenes Protokollsignal und beendet die Nachrichtenfolge des adressierten Requests.

• Cleanup planen: lokale Streams, Timeouts, Cancellation und Host-Ressourcen beim Beenden freigeben.
• Keine implizite Wiederholung: einen nicht bestätigten Seiteneffekt nach Verbindungsverlust erst per Status klären.
• Neu deklarieren: jeder neue Request trägt wieder Version und aktuelles Capability-Set.

Der Host verwaltet daher Requestzustände wie geplant, gesendet, laufend, abgebrochen, abgeschlossen und Ausgang unbekannt. Ein verlorener Response darf nicht automatisch in „fehlgeschlagen“ wechseln. Bei wirkenden Tools hält der Host Idempotency-Key oder Vorgangshandle und zeigt eine Statusaktion an. Bei Subscriptions verwirft er keine Source-of-Truth zugunsten lokaler Eventhistorie. Timeouts werden pro Interaktion begründet und an die darunterliegenden Dienste weitergegeben, damit Hintergrundarbeit nicht unbegrenzt weiterläuft. Diese Zustandsmaschine ist Produktlogik: Sie entscheidet, was Nutzer sehen und welche Folgeaktion sicher ist.

Discovery wird durch lokale Policy wirksam

Ein Client kann server/discover aufrufen, um Identität, Fähigkeiten und serverseitige Capabilities in einer Response zu erfassen. Der Server muss diese Methode implementieren; ein Client muss sie nicht zwingend aufrufen. Discovery ist Information, keine Installationserlaubnis. Der Host gleicht das Ergebnis mit Server-Allowlist, Datenklassifikation, Nutzerrolle und Produktkonfiguration ab, bevor daraus eine aktive Modellfähigkeit wird.

Server-Discovery

Beschreibt aktuelle Identität und angebotene Protokollfähigkeiten

Capability-Listen

Liefern konkrete Tools, Resources oder Prompts mit ihren Verträgen

Host-Policy

Entscheidet Sichtbarkeit, Alias, Freigabe, Kontextbudget und Risikoklasse

Aktive Registry

Enthält nur die für diesen Principal und Arbeitsraum erlaubte Schnittmenge

Veraltete Client-Features wie Roots, Sampling und die frühere direkte Server-zu-Client-Elicitation sind in der aktuellen Revision deprecated. Neue Hosts sollen keine Sicherheitsarchitektur auf ihnen aufbauen. Dateibezug kommt über Toolparameter, Resource-URIs oder Serverkonfiguration; zusätzliche Eingaben laufen über Multi Round-Trip Results. Wenn ein Produkt ältere Server unterstützt, kapselt es den Legacy-Pfad als eigene Kompatibilitätsschicht, erkennt die Protokollära ausdrücklich und testet die abweichende Semantik. Ein stiller Mischmodus ist gefährlich, weil beide Seiten dann unterschiedliche Annahmen über Zustand und Rückkanäle treffen.

Discovery-Antworten und Capability-Listen können gecacht werden, aber nur unter den vom Server gelieferten Hinweisen und der lokalen Berechtigungsbindung. ttlMs beschreibt Frische, cacheScope den vorgesehenen Geltungsbereich; weder Feld macht einen Eintrag öffentlich. Bei Listen wird jede Seite eigenständig gecacht, ohne implizite Garantie für einen seitenübergreifenden Snapshot. Ändert sich die Registry während eines Modellturns, entscheide bewusst, ob die laufende Planung mit einem stabilen, bereits freigegebenen Satz endet oder vor Ausführung neu geprüft wird. Für wirkende Calls ist die zweite Prüfung unverzichtbar. Protokolliere den Fingerabdruck des tatsächlich verwendeten Vertrags, damit ein Incident später nicht nur den aktuellen, inzwischen veränderten Serverzustand sieht. Behandle unbekannte neue Capability-Felder konservativ: verstehen und validieren, bevor sie Produktwirkung erhalten. So bleibt Erweiterbarkeit möglich, ohne dass Discovery selbst zum automatischen Rolloutkanal wird.

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.

Kontextpolicy arbeitet vor und nach dem Modellaufruf. Vorher begrenzt sie Größe, Typen, Datenklassen und Relevanz; eingebettete Instruktionen bleiben als untrusted Daten markiert. Nachher darf ein Modellvorschlag die ursprüngliche Herkunft nicht verlieren: Stammt eine Behauptung aus einer Resource, bleibt sie dieser Quelle zugeordnet. Verlangt der Vorschlag ein Tool, prüft der Host die aktuelle Capability und Policy erneut. Ein einmal in Kontext sichtbarer Name ist keine fortdauernde Ausführungserlaubnis. Beobachte verworfene Bytes, Redaktionen, Serveranteile am Kontext und Policy-Ablehnungen, damit Sicherheit nicht als unsichtbare Qualitätsverschlechterung endet.

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

Die Registry sollte einen internen Schlüssel aus Serveridentität und Capability-Name verwenden. Produktaliases sind eine Darstellungsschicht und dürfen die Rückbindung nicht löschen. Bei einer erneuten Discovery wird nicht blind ersetzt: Der Host diffed hinzugefügte, entfernte und geänderte Verträge, invalidiert abhängige Caches und lässt neue wirkende Tools erneut durch Policy. Eine geänderte Beschreibung oder ein gelockertes Schema kann sicherheitsrelevant sein, auch wenn der Name gleich bleibt. Ist ein Server ausgefallen, verschwinden seine Tools zeitweilig aus der aktiven Modellmenge; begrenzte Hintergrundprobes ermöglichen die Rückkehr. So beeinflusst Betriebszustand die Planung, ohne Konfiguration dauerhaft umzuschreiben.

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.

Eine gute Freigabe zeigt die entscheidungsrelevante Differenz, nicht das gesamte JSON. Bei close_ticket sind Ticket, Zielstatus, Serverherkunft und Folgen wichtig; interne Request-Metadaten nicht. Gruppiere keine unabhängigen Wirkungen in ein pauschales „Erlauben“, nur um Klicks zu sparen. Wiederholte, risikoarme Aktionen können über eng begrenzte Produktregeln freigegeben werden, doch Serverwechsel, Parameter außerhalb der Grenze oder Vertragsänderungen erzwingen neue Prüfung. Bei MRTR-Elicitation kontrolliert der Host Formular, Ziel-Domain, Zweck und Ablehnung. Nutzerabbruch wird als normaler Ausgang behandelt und nicht durch automatische Retries umgangen.

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 Produktkontrolle trägt, wie Server isoliert bleiben, welche Transportgrenze passt, wie Request-Metadaten und Discovery verarbeitet werden, wie Kontext begrenzt wird, wie mehrere Server eindeutig bleiben und wie Nutzer sichtbar eingreifen.

• Eigentum: Consent, Request-Lifecycle und Kontextpolicy bleiben beim Host.
• Isolation: serverqualifizierte und principalgebundene Datenflüsse verhindern Vermischung.
• Statelessness: Version und Client-Capabilities werden für jeden Request neu deklariert.
• Kontrolle: Discovery und Serverantworten erhalten erst durch Host-Policy Produktwirkung.

Baue für die Abnahme eine kleine Föderationsmatrix. Zwei Nutzer verwenden zwei Server mit gleichnamigem Tool; ein Server ändert seinen Vertrag und fällt danach aus. Parallel läuft eine Subscription, während ein wirkender Call seinen Response verliert. Prüfe, dass Registry, Cache, Modellkontext, Consent und Telemetrie stets Server und Principal erhalten. Der Host darf weder eine alte Capability anbieten noch einen unbekannten Ausgang als sicheren Fehlschlag darstellen. Wenn diese Probe grün ist, sind die wichtigsten Integrationsgrenzen nicht nur beschrieben, sondern ausführbar getestet.

Ergänze Negativtests für Antworten, die zur falschen Request-ID, Serveridentität oder Protokollversion gehören. Simuliere zwei gleichzeitige Elicitation-Runden und lehne eine davon ab; der Host darf Responses und requestState nicht vertauschen. Führe danach einen Rechtewechsel aus, während ein Resource-Cache noch frisch ist, und erwarte eine erneute Policyprüfung statt eines blinden Cachetreffers. Bei einer Tool-Kollision muss die UI denselben qualifizierten Ursprung zeigen wie Auditlog und Ausführungspfad. Schließlich kappe einen Subscription-Stream und ändere die Resource während der Unterbrechung: Nach dem Wiederverbinden wird aus der Quelle neu gelesen, nicht eine lückenlose Eventfolge behauptet. Solche Tests verbinden Protokollkorrektheit mit Produktsemantik. Sie sind wertvoller als ein einzelner End-to-End-Happy-Path, weil Integrationsfehler fast immer an Übergängen zwischen Cache, Registry, Nutzerkontext und Transport auftreten.

Halte diese Grenzen in einem Integrationsvertrag fest: stabile Server-ID, unterstützte Protokollversionen, erlaubte Capabilities, Principal-Bindung, Cachebereich, Consent-Klasse, Timeout und Verhalten bei unbekanntem Ausgang. Der Vertrag gehört in Code und Tests, nicht nur in ein Architekturdiagramm. Ändert sich eine Seite, zeigt ein Diff, welche Policy- und UX-Prüfungen erneut nötig sind. Damit bleibt eine wachsende Serverlandschaft operierbar, ohne dass jede neue Fähigkeit still dieselben Rechte und denselben Kontext wie ihre Vorgänger erbt.