# MCP-Server: Capability-Grenzen, Trust & Betrieb > MCP standardisiert die Grenze zwischen Host, Client und Server. Lerne Primitives, Transport, Capability-Negotiation, Vertrauens- und Autorisierungsgrenzen sowie den sicheren Betrieb eines MCP-Servers. Track: [Agentic AI](https://physar.tech/learn/agentic-ai) Kanonische Fassung: https://physar.tech/learn/agentic-ai/mcp-servers Stand: 2026-07-25 Interaktiver Teil: 8 Checks (nur im Browser) ## MCP-Server: eine kontrollierte Grenze zur Außenwelt ### 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. > **Merksatz:** MCP macht eine Fähigkeit **interoperabel**. Ob und wann sie ein Agent nutzt, bleibt eine Entscheidung 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 | > **Merksatz:** Wähle das Primitive nach der **Kontrollsemantik**, nicht danach, welches am schnellsten implementiert ist. ### 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 > **Kein API-Raten:** Ein lokaler Testserver ist kein Beweis, dass ein anderer Server dieselben optionalen Capabilities anbietet. ### 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 | > **Merksatz:** Wähle den Transport aus **Topologie, Lifecycle und Trust Boundary** — nicht aus einer pauschalen Vorliebe für lokal oder remote. ### 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. > **Merksatz:** Die Fähigkeit eines Servers ist ein Angebot, keine automatisch erteilte Berechtigung. ### 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. > **Merksatz:** Ein Zugriffstoken ist eine **delegierte Berechtigung für eine Ressource**, kein allgemeiner Ausweis für alle Server. ### 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. > **Abgrenzung:** Generisches Tool-Design und Argumentvalidierung vertieft das vorherige Modul. Hier zählt zusätzlich, dass der Vertrag über eine **Server- und Protokollgrenze** publiziert wird. ### 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. > **Merksatz:** Betreibe einen MCP-Server als **abhängigen Vertrag**: Capabilities, Identität, Fehler und Seiteneffekte müssen beobachtbar bleiben. ### 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. > **Weiterführend:** Die konkrete SDK- und Serverimplementierung ist absichtlich nicht festgeschrieben: Protokollversionen und Plattformen entwickeln sich. Die Entscheidungsgrenzen bleiben die stabile Grundlage. ## Quellen - Model Context Protocol Specification — Architecture, 2025-11-25 - Model Context Protocol Specification — Server Features, 2025-11-25 - Model Context Protocol Specification — Transports, 2025-11-25 - Model Context Protocol Specification — Authorization, 2025-11-25 - Model Context Protocol — Security Best Practices, 2025 - Model Context Protocol Specification — Lifecycle, 2025-11-25 - RFC 9728 — OAuth 2.0 Protected Resource Metadata, IETF 2024 - Model Context Protocol Specification — Server Features: Tools, 2025-11-25