FACT COPY · DE
Faktenfassung: Architektur eines MCP-Systems
Referenzarchitektur für Hosts, Clients, Server, Gateways, Identitäten, Datenflüsse und Betriebsgrenzen.
Originalseite: https://travel-mcp.com/de/mcp-architektur/
Sachliche Zusammenfassung
Eine MCP-Architektur ist kein einzelner Server, sondern ein verteiltes System aus Nutzeroberfläche, Modelllaufzeit, Clientverbindungen, Capability-Servern, Identitätsdiensten und Fachsystemen. Gute Architektur macht Verantwortung und Vertrauen an jeder Grenze explizit.
1. Architektonische Schichten
Die Präsentationsschicht erfasst Nutzerintention und zeigt Quellen, Pläne sowie Freigaben. Die Agenten- oder Orchestrierungsschicht verwaltet Modell, Kontext, Tool-Auswahl und Abbruchregeln. Die MCP-Clientschicht hält isolierte Verbindungen. Server kapseln Domänenfähigkeiten; Backends bleiben Systeme der Wahrheit.
Diese Schichten dürfen in einem Prozess laufen, sollten konzeptionell aber getrennt bleiben. Nur dann lassen sich Modellwechsel, Serverdeployment und Fachsystemänderungen unabhängig testen.
2. Datenfluss und Kontrollfluss
Ein Nutzerwunsch wird in Kontext und mögliche Aktionen zerlegt. Der Host wählt relevante Server und Tools, das Modell schlägt einen Aufruf vor, der Client übermittelt strukturierte Parameter und der Server validiert sowie autorisiert. Das Ergebnis fließt als begrenzter Inhalt zurück.
Der Kontrollfluss ist nicht identisch mit dem Datenfluss. Eine Nutzerfreigabe kann vor dem Toolaufruf liegen; Auditdaten gehen in ein separates System; das Backend kann asynchron arbeiten. Architekturdiagramme sollten deshalb Identitäten, Daten und Entscheidungen getrennt darstellen.
3. Domänengrenzen für Server
Server sollten kohärenten Fachdomänen und Sicherheitsgrenzen folgen. Ein Zahlungsserver, Dokumentenserver und Angebotsserver besitzen andere Eigentümer, Rechte und Ausfallfolgen. Ein Universalserver vergrößert Blast Radius und koppelt Releases.
Zu kleine Server können dagegen Chatty Integrations und widersprüchliche Transaktionen erzeugen. Die richtige Grenze folgt fachlicher Konsistenz, Berechtigung, Teamverantwortung und gemeinsamem Lebenszyklus – nicht der Zahl der Endpunkte.
4. Gateways und Capability-Kataloge
Ein Gateway kann Discovery, Richtlinien, Routing, Rate Limits und Telemetrie vereinheitlichen. Es sollte keine Domänenlogik absorbieren. Andernfalls entsteht ein zentraler Super-Server, den jede Fachänderung berührt.
Der Capability-Katalog dokumentiert Server, Tools, Owner, Datenklassen, Scopes, Versionen und SLOs. Er ist Governance-Instrument und Grundlage für dynamische Tool-Suche. Ein Registry-Eintrag allein beweist keine Vertrauenswürdigkeit.
5. Identität und Autorisierung
Die ursprüngliche Nutzer- oder Workloadidentität muss bis zur Fachoperation nachvollziehbar bleiben. OAuth-Scopes begrenzen grobe Capability-Gruppen; Objektberechtigungen entscheiden über konkrete Buchungen, Kunden oder Dokumente.
Servicekonten ohne Delegationskontext erschweren Audit und Least Privilege. Wo Legacy-Systeme nur Sammelkonten erlauben, muss der MCP-Server die objektbezogene Policy zuverlässig erzwingen und die Nutzeridentität manipulationssicher protokollieren.
6. Zustandsmodelle
Protokollsession, Modellkontext, Nutzerpräferenz, Taskstatus und fachlicher Prozesszustand sind verschiedene Zustände. Fachliche Wahrheit gehört in dauerhafte Fach- oder Workflow-Systeme. Eine Chat-Historie darf nicht zum Buchungsledger werden.
Zustandslose HTTP-Server skalieren einfach. Server-to-client Requests oder langlebige Streams können Sitzungsaffinität verlangen. Die Topologie wird aus benötigten Capabilities abgeleitet, nicht umgekehrt.
7. Resilienz und Skalierung
Timeouts, Bulkheads, Rate Limits und Circuit Breaker schützen abhängige Systeme. Schreibende Aufrufe benötigen Idempotenz und Zustandsabgleich. Ein Clienttimeout bedeutet nicht, dass das Backend nicht ausgeführt hat.
Skalierung misst nicht nur Requests pro Sekunde. Kontextgröße, Ergebnisvolumen, Modellwartezeit und Downstreamlimits bestimmen Kapazität. P95- und P99-Latenzen sowie Queuezeit sind wichtiger als Durchschnittswerte.
8. Observability und SLO
Korrelations-IDs verbinden Host, MCP-Request, Server und Backend. Metriken trennen Tool-Auswahl, Freigabe, Ausführung und Ergebnisvalidierung. Logs minimieren sensible Inhalte und enthalten niemals Tokens.
SLOs kombinieren technische Verfügbarkeit mit fachlicher Erfolgsquote und Aktualität. Ein Server kann 99,9 Prozent erreichbar und dennoch fachlich unbrauchbar sein, wenn Ergebnisse regelmäßig veraltet sind.
9. Cloud, On-Premises und Hybrid
Lokale Server liegen nahe an Nutzerdateien, entfernte Server nahe an zentralen Systemen. On-Premises kann Daten- und Netzwerkanforderungen erfüllen; Cloud erleichtert Skalierung und Managed Services. Hybrid ist in Unternehmen häufig realistisch.
Die Entscheidung folgt Datenklassifikation, Latenz, Identität, Egress und Betriebsfähigkeit. ‚On-Premises‘ ist keine automatische Sicherheitsgarantie, ‚Cloud‘ kein automatischer Kontrollverlust.
FAQ
Braucht ein Unternehmen ein MCP-Gateway?
Nicht zwingend. Es lohnt sich bei vielen Servern und Clients, wenn zentrale Policies und Discovery benötigt werden. Kleine Umgebungen sollten Komplexität vermeiden.
Soll jedes Backend einen Server erhalten?
Nein. Servergrenzen folgen Domäne und Sicherheitsgrenze, nicht der technischen Systemanzahl.