Faktenfassung: MCP-Server: Architektur, Protokoll und produktiver Betrieb

Sachliche Zusammenfassung

Ein MCP-Server ist eine Protokollgrenze zwischen einer KI-Anwendung und kontrollierten Daten- oder Funktionszugriffen. Seine Qualität bemisst sich nicht an der Zahl veröffentlichter Tools, sondern an semantischer Eindeutigkeit, korrekter Autorisierung, vorhersehbarem Laufzeitverhalten und langfristiger Betriebsfähigkeit.

1. Gegenstand und Abgrenzung eines MCP-Servers

Ein MCP-Server implementiert die Serverrolle des Model Context Protocol. Er nimmt JSON-RPC-Anfragen eines MCP-Clients entgegen, veröffentlicht ausgehandelte Capabilities und vermittelt Zugriffe auf Daten, Berechnungen oder Geschäftsoperationen. Der Server kann selbst das Fachsystem sein; in Unternehmensarchitekturen ist er jedoch häufiger ein Adapter vor APIs, Datenbanken, Dokumentenplattformen oder Workflow-Engines. Diese Unterscheidung ist zentral: MCP standardisiert die Interaktion mit einer Fähigkeit, nicht deren fachliche Wahrheit.

Der Server ist weder das Sprachmodell noch der Agent. Er plant keine Nutzerziele, sofern eine Anwendung nicht bewusst zusätzliche Agentenlogik in den Server legt. Er ist auch kein Ersatz für API-Gateway, IAM oder Prozessengine. Seine Verantwortung beginnt bei der protokollkonformen Beschreibung und endet erst nach Validierung, Autorisierungsentscheidung, kontrollierter Ausführung und einem begrenzten Ergebnis. Wer diese Grenze unscharf lässt, erhält einen Universalservice mit schwer prüfbaren Rechten.

2. Formales Kommunikationsmodell: JSON-RPC und Rollen

MCP kodiert Anfragen, Antworten und Notifications als JSON-RPC 2.0. Eine Request-ID korreliert Anfrage und Antwort; Notifications besitzen keine Antwort. Dieser scheinbar einfache Unterschied beeinflusst Fehlerbehandlung und Wiederholung: Eine verlorene Antwort bedeutet nicht, dass die zugrunde liegende Operation nicht ausgeführt wurde. Schreibende Tools benötigen deshalb Idempotenz oder einen fachlichen Statusabgleich, bevor ein Client wiederholt.

Das Protokoll ist bidirektional. Nicht nur der Client kann den Server ansprechen; abhängig von ausgehandelten Client-Capabilities kann der Server Sampling, Elicitation oder Roots verwenden. Daraus folgt ein symmetrischeres Vertrauensmodell als bei einer gewöhnlichen REST-API. Ein Server darf keine Clientfunktion voraussetzen, die nicht während der Initialisierung angekündigt wurde, und ein Client muss serverseitige Beschreibungen als nicht automatisch vertrauenswürdig behandeln.

3. Lebenszyklus und Version Negotiation

Die Initialisierung ist die erste reguläre Interaktion. Der Client sendet die von ihm bevorzugte Protokollversion, seine Capabilities und Implementierungsinformationen. Der Server antwortet mit einer unterstützten Version, seinen Capabilities und Serverinformationen. Kann der Client die Antwortversion nicht unterstützen, muss die Verbindung beendet werden. Erst die anschließende initialized-Notification markiert den Übergang in den normalen Betrieb.

Version Negotiation ist von der Version der eigenen Serveranwendung zu trennen. Eine Implementierung kann beispielsweise Version 2.4.1 besitzen und zugleich MCP 2025-11-25 sprechen. Für Streamable HTTP muss die ausgehandelte Protokollversion in nachfolgenden Requests über den MCP-Protocol-Version-Header transportiert werden. Tests müssen deshalb mindestens jede offiziell unterstützte Protokollversion und deren Capability-Kombination abdecken.

4. Capability-Modell und semantische Verträge

Der Server kündigt nur Funktionen an, die er in der konkreten Sitzung unterstützt. Tools, Ressourcen, Prompts und Logging besitzen eigene Capability-Einträge; zusätzliche Merkmale wie listChanged oder subscribe präzisieren das Verhalten. Capability Negotiation ist kein Marketingkatalog, sondern ein Laufzeitvertrag. Meldet ein Server listChanged, muss er Änderungen korrekt signalisieren. Andernfalls arbeitet der Client mit veralteten Annahmen.

Auf fachlicher Ebene benötigt jede Capability einen semantischen Vertrag: Zweck, Eingaben, Ergebnis, Fehler, Datenklasse, Nebenwirkung, Eigentümer und Berechtigungsregel. Das JSON-Schema erfasst davon nur den strukturellen Teil. Universitätsniveau bedeutet hier, Syntax, Semantik und Pragmatik zu unterscheiden: Ein String kann syntaktisch gültig, fachlich unmöglich und im gegebenen Nutzerkontext dennoch unzulässig sein.

5. Tools als kontrollierte Operationen

Ein Tool besteht mindestens aus Name, Beschreibung und inputSchema; outputSchema kann strukturierte Ergebnisse absichern. Namen sollten stabil, eindeutig und auf eine Nutzerabsicht bezogen sein. Ein Tool api_request oder execute ist semantisch wertlos. Besser sind begrenzte Fähigkeiten wie hotel_verfuegbarkeit_suchen oder buchung_stornierung_vorbereiten. Suche und verbindliche Stornierung gehören nicht in denselben Vertrag, weil Rechte, Fehlerfolgen und Freigaben verschieden sind.

Tool-Annotationen können Hinweise auf Lesbarkeit, Destruktivität oder Wiederholbarkeit geben, sind aber keine Sicherheitsgrenze. Der Server muss jede Eingabe unabhängig validieren und jeden Aufruf gegen die aktuelle Identität autorisieren. Strukturierte Ergebnisse sollten gegen outputSchema geprüft und zusätzlich als Text serialisiert werden, wenn Abwärtskompatibilität dies erfordert. Interne Stacktraces, Tokens und ungefilterte Backendantworten gehören nicht in ToolResult.

6. Ressourcen und Prompts als andere Kontrollformen

Ressourcen sind URI-adressierbare Kontextobjekte. Sie können Dateien, Datenbankansichten, Handbücher oder dynamische Fachobjekte repräsentieren. Resource Templates beschreiben variable URI-Muster; Subscriptions erlauben Änderungsbenachrichtigungen. Eine Ressourcenliste ist keine Berechtigungsgarantie: Das Zugriffsrecht muss beim tatsächlichen Read erneut geprüft werden, weil Nutzerrolle oder Objektstatus sich geändert haben können.

Prompts sind nutzergesteuerte Vorlagen mit optionalen Argumenten. Sie unterstützen wiederkehrende Arbeitsweisen, dürfen aber nicht als Ersatz für serverseitige Policies missverstanden werden. Ein Prompt kann eine Tarifprüfung strukturieren; die verbindliche Tarifregel gehört in Fachcode oder eine versionierte Ressource. Diese Trennung verhindert, dass eine manipulierbare Sprachvorlage geschäftskritische Kontrolle übernimmt.

7. Transportwahl und Deployment-Topologie

Beim stdio-Transport startet der Client den Server als Unterprozess und kommuniziert über stdin und stdout. Jede Zeile auf stdout muss eine gültige MCP-Nachricht sein; Logs gehören auf stderr. stdio besitzt eine natürliche Prozess- und Sitzungsgrenze und eignet sich für lokale Werkzeuge, ist aber nicht ohne Weiteres zwischen vielen Nutzern teilbar. Dateisystem- und Umgebungsrechte des Unterprozesses werden damit Teil des Sicherheitsmodells.

Streamable HTTP betreibt den Server als eigenständigen Netzwerkdienst über einen MCP-Endpunkt für POST und GET. SSE kann mehrere Nachrichten streamen. Für Produktion sind HTTPS, Origin-Validierung, Autorisierung, Session-Handling und Schutz gegen DNS-Rebinding erforderlich. Zustandslose Verarbeitung vereinfacht horizontale Skalierung; zustandsbehaftete Sessions erfordern Affinität oder externen Zustand. Die Transportentscheidung ist deshalb zugleich eine Betriebs- und Sicherheitsentscheidung.

8. Authentifizierung, Autorisierung und Delegation

Bei entfernten HTTP-Servern folgt MCP einem OAuth-basierten Autorisierungsmodell. Der Resource Server muss Signatur, Issuer, Ablauf, Audience und Scopes validieren. Token-Passthrough ist ein Anti-Pattern: Ein für ein Downstream-System ausgestelltes Token darf nicht ungeprüft als MCP-Berechtigung akzeptiert oder blind weitergereicht werden. Audience Binding verhindert, dass ein gestohlenes oder fehladressiertes Token an einem anderen Server funktioniert.

Autorisierung endet nicht beim Scope. Ob ein Mitarbeiter eine bestimmte Buchung lesen oder stornieren darf, ist eine objektbezogene Fachentscheidung. Der MCP-Server muss diese Entscheidung selbst treffen oder an ein vertrauenswürdiges Policy- beziehungsweise Fachsystem delegieren. Nutzerzustimmung im Client ergänzt die Serverautorisierung, ersetzt sie aber nicht: Ein Nutzer kann einer Aktion zustimmen, zu der er organisatorisch trotzdem nicht berechtigt ist.

9. Fehlersemantik, Idempotenz und langlaufende Arbeit

Fehler sollten Protokollfehler, Validierungsfehler, Autorisierungsfehler, Fachkonflikte und temporäre Infrastrukturfehler unterscheiden. Nur dann kann ein Client sinnvoll reagieren. Ein Preiswechsel ist kein interner Serverfehler, sondern ein fachlicher Konflikt, der dem Nutzer neue Bedingungen zeigen muss. Ein Timeout ist wiederum kein Beweis für Nichtausführung; ein Wiederholungsversuch ohne Idempotenz kann Doppelbuchungen erzeugen.

Für langlaufende Operationen enthält die Spezifikation 2025-11-25 experimentelle Tasks. Tasks modellieren Zustände wie working, input_required, completed, failed und cancelled, besitzen TTL sowie Polling- und Ergebnisoperationen. Sie erfordern strikte Bindung an den Autorisierungskontext. Da Tasks experimentell sind, sollten produktive Architekturen sie hinter einer eigenen Abstraktion kapseln und nicht mit der dauerhaften Prozesswahrheit eines BPM-Systems verwechseln.

10. Qualitätssicherung und formale Teststrategie

Der MCP Inspector unterstützt interaktive Prüfung von Verbindung, Capability Negotiation, Tools, Ressourcen, Prompts und Notifications. Er ist ein Explorations- und Debuggingwerkzeug, kein Ersatz für automatisierte Tests. Eine belastbare Strategie kombiniert Schema-Tests, Protokollzustandsautomaten, Backend-Vertragstests, Berechtigungsmatrizen, Nebenwirkungs- und Idempotenztests sowie Ende-zu-Ende-Aufgaben im Zielclient.

Besonders wichtig sind Negativtests: ungültige Versionen, nicht angekündigte Capabilities, übergroße Payloads, zusätzliche Schemafelder, fehlende Rechte, abgelaufene Tokens, manipulierte Ressourcen, Clientabbruch und teilweise Backendfehler. Property-based Testing und Fuzzing helfen, Parser- und Validierungsannahmen aufzudecken. Für schreibende Tools muss nachweisbar sein, dass Retry, Timeout und Parallelität keine unerlaubten Zustände erzeugen.

11. Observability, SLOs und Governance

Produktionsbeobachtung verbindet eine Korrelations-ID über Clientrequest, MCP-Server und Downstream-System. Metriken trennen Protokolllatenz, Toolausführung, Backendzeit, Fehlertypen und Ergebnisgröße. Logs enthalten Identität und Datenklassifikation nur soweit nötig und niemals Tokens oder unnötige personenbezogene Inhalte. Traces müssen Mandantengrenzen respektieren und einer definierten Aufbewahrung folgen.

Jede Capability benötigt einen fachlichen Owner, eine Risikoklasse, unterstützte Versionen, SLO, Deprecation-Regel und dokumentierte Datenflüsse. Governance bedeutet nicht zentrale Entwicklung aller Server. Sinnvoll ist föderierte Verantwortung: Plattformteams setzen Protokoll-, Sicherheits- und Observability-Baselines; Domänenteams besitzen Semantik, Fachtests und Lebenszyklus ihrer Fähigkeiten.

12. Vertiefende Studienmodule

Die folgenden Seiten zerlegen den Gegenstand in eigenständige Module. Zusammen bilden sie einen technischen Lernpfad vom Protokollzustandsautomaten bis zum produktiven Plattformbetrieb.

Referenzartefakt: Tool-Vertrag und Aufruf

{
  "name": "search_offers",
  "description": "Sucht Reiseangebote; das Ergebnis ist keine Buchungsbestätigung.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "destination": { "type": "string", "minLength": 2 },
      "date_from": { "type": "string", "format": "date" },
      "date_to": { "type": "string", "format": "date" },
      "travellers": { "type": "integer", "minimum": 1 },
      "max_price": { "type": "number", "exclusiveMinimum": 0 },
      "currency": { "type": "string", "pattern": "^[A-Z]{3}$" }
    },
    "required": ["destination", "date_from", "date_to", "travellers"]
  }
}

{
  "jsonrpc": "2.0", "id": 17, "method": "tools/list", "params": {}
}

{
  "jsonrpc": "2.0",
  "id": 18,
  "method": "tools/call",
  "params": {
    "name": "search_offers",
    "arguments": {
      "destination": "JP",
      "date_from": "2026-09-10",
      "date_to": "2026-09-20",
      "travellers": 2,
      "max_price": 4000,
      "currency": "EUR"
    }
  }
}

Ein prüfbarer Vertrag verbindet Beschreibung, Schema, Ergebnisgrenzen, stabile Fehlerklassen, Autorisierungsregel und Nebenwirkung.

stdio oder Streamable HTTP?

Transport verändert Identitätsgrenze, Angriffsfläche, Session-Modell und Skalierung. Er ist keine reine Deploymentpräferenz.

FAQ

Primärquellen und Spezifikationen

• MCP-Spezifikation 2025-11-25
• Lifecycle
• Transports
• Tools
• Security Best Practices
• MCP Inspector