MCP-Server: eine kontrollierte Grenze zur Außenwelt
Einführung · 9 Abschnitte · ~5 Min Lesezeit · Stand
MCP ist ein Protokoll, kein Agent
Das Model Context Protocol (MCP) standardisiert, wie ein Host Kontext und Fähigkeiten aus Servern bezieht. Ein Host verwaltet die Anwendung und ihre Sicherheitsentscheidungen; pro Server-Verbindung arbeitet ein Client; der Server stellt klar beschriebene Fähigkeiten bereit. Ein MCP-Server entscheidet weder selbstständig Ziele noch ersetzt er die Agentenlogik des Hosts.
Die Server-Primitives unterscheiden sich in der Kontrolle
Ein Server kann Prompts, Resources und Tools anbieten. Prompts werden typischerweise vom Nutzer gewählt, Resources von der Anwendung als Kontext gelesen und Tools vom Modell zur Ausführung vorgeschlagen. Die Kategorien sind keine bloßen Namen: Sie bestimmen, wer den Zugriff anstößt und wo Freigaben sichtbar sein müssen.
| Prompt | Nutzergesteuerte Vorlage oder Workflow-Einstieg |
|---|---|
| Resource | Anwendung liest oder abonniert Kontextdaten |
| Tool | Modell kann eine Operation mit Argumenten vorschlagen |
Initialisierung vor Annahmen
Bei Verbindungsaufbau tauschen Client und Server Protokollversion und Capabilities aus. Viele Funktionen sind optional. Ein Client darf deshalb weder Tool-Listen, Logging, Subscriptions noch andere Erweiterungen einfach voraussetzen; er prüft die ausgehandelten Fähigkeiten und behandelt die Verbindung als den konkret vereinbarten Vertrag.
- Verbindung herstellen
- Version und Capabilities initialisieren
- Server-Fähigkeiten entdecken
- Nur unterstützte Fähigkeit aufrufen
- Änderungen und Fehler beobachten
Transport folgt Topologie und Betriebsgrenze
Für einen lokalen Server kann der Client einen Child-Prozess über stdio starten; Standardausgabe ist dabei der MCP-Nachrichtenkanal. Streamable HTTP eignet sich für einen Netzwerkdienst und kann auf demselben Rechner oder entfernt laufen; dann sind Erreichbarkeit, TLS, Identität und Angriffsfläche explizit zu behandeln. Lokal bedeutet nicht automatisch vertrauenswürdig, remote nicht automatisch ungeeignet.
| stdio | Lokaler Child-Prozess; der Host kontrolliert Start, Umgebung und Lebenszyklus |
|---|---|
| Streamable HTTP | HTTP-Netzwerkdienst, lokal oder remote; Netzwerk-, TLS-, Authentisierungs- und Betriebsgrenze explizit behandeln |
Ein Server ist eine eigene Vertrauensgrenze
Ein MCP-Server bringt nicht nur Code, sondern auch Tool-Beschreibungen, Prompt-Text, Resource-Inhalte und potenziell Seiteneffekte mit. Diese Daten können aus einem fremden oder kompromittierten Server stammen. Der Host behandelt sie deshalb als untrusted, prüft Herkunft und Version und exponiert nur die Server und Fähigkeiten, die für die konkrete Aufgabe nötig sind.
Namen und Beschreibungen sind keine Sicherheitsgarantie. Ein Tool, das harmlos klingt, kann breite Datenzugriffe oder Aktionen auslösen. Der Host braucht nachvollziehbare Allowlisting-, Freigabe- und Berechtigungsentscheidungen außerhalb der Modellentscheidung.
Remote-Autorisierung bindet Token an den richtigen Empfänger
Ein Remote-MCP-Server kann eine Nutzerautorisierung benötigen. Im MCP-Autorisierungsmodell entdeckt der Client die geschützte Ressource und ihren Authorization Server; ein Token ist für die konkrete Resource bzw. Audience bestimmt. Der Client reicht nicht einfach irgendein vorhandenes Upstream-Token an den Server weiter.
Diese Grenze verhindert, dass ein Server ein Token für einen anderen Dienst verwertet. Welche Scopes, Consent-Schritte und Credential-Formen nötig sind, hängt vom Server und dem organisatorischen Kontext ab. HTTPS, präzise Resource-Identität und Validierung am Server sind Teil des Vertrags.
Schemas begrenzen Missverständnisse, ersetzen aber keine Durchsetzung
Tool-Schemas beschreiben die erwarteten Argumente und helfen dem Modell bei der Auswahl. Der Server validiert Eingaben trotzdem selbst, begrenzt Suchräume und prüft die Autorisierung vor einer Nebenwirkung. Modell-generierte Argumente und Inhalte aus Resources bleiben untrusted, auch wenn sie schema-konform aussehen.
- Schmaler Vertrag: nur die Parameter und Operationen anbieten, die die Aufgabe braucht.
- Serverseitige Prüfung: Typ, Bereich, Identität, Mandant und Berechtigung vor Ausführung validieren.
- Sichtbare Seiteneffekte: riskante Tools klar benennen, begrenzen und bei Bedarf vorab bestätigen lassen.
Betrieb heißt Vertrag beobachten
Ein Server kann ausfallen, langsam werden, seine Capabilities ändern oder eine laufende Anfrage abbrechen. Der Host braucht Timeouts, Abbruchpfade, strukturierte Fehler und Telemetrie pro Server und Operation. Wiederholungen sind nur sicher, wenn die konkrete Operation idempotent ist oder ein Idempotency-Mechanismus besteht.
Teste Integrationen gegen die tatsächlich unterstützten Capabilities und sichere Server-Versionen oder Vertrauensanker ab. Ein erfolgreicher einzelner Tool-Call beweist weder Kompatibilität nach einem Update noch eine sichere Berechtigungskette. Damit ergänzt dieses Modul die allgemeinen Retry-, Eval- und Observability-Entscheidungen des Reliability-Moduls.
Gleich entscheidest du diese acht Grenzen selbst
Die folgenden Checks führen von der Architekturentscheidung zur Betriebsentscheidung. Sie fragen nicht, welches SDK gerade beliebt ist, sondern welche Kontrolle an welcher Grenze fehlt: Interoperabilität, Primitive, Transport, Capability-Negotiation, Trust, Autorisierung, Eingabe und Betrieb.
- Architektur: MCP-Grenze, Primitive und Transport passend zur Aufgabe wählen.
- Sicherheit: Server-Angebote, Tokens und Tool-Argumente nicht mit Berechtigungen verwechseln.
- Betrieb: ausgehandelte Capabilities und Seiteneffekte über Änderungen hinweg prüfen.