MCP-Architekturdiagramm: Hosts, Clients, Server und Transports

Dein Coding-Agent liest das Repository, prüft den Build und legt Issues in deinem Tracker an. Ein typisches Diagramm dieses Aufbaus zeigt eine Box mit der Aufschrift «MCP» zwischen Modell und Tools. Dann fragt ein Security-Reviewer, welcher Prozess dein Home-Verzeichnis lesen kann, welches Token den Tracker erreicht und wer den Aufruf freigegeben hat, der ein Issue angelegt hat. Die Box hat darauf keine Antwort.

Das Model Context Protocol (MCP) hat eine präzise Architektur, und seine Revision 2026-07-28 hat einen Teil davon verändert. Dieser Beitrag behandelt Teilnehmer, Protokollschichten, Transports, Features, einen Tool-Aufruf, Remote-Autorisierung und Trust Boundaries, mit einem Diagramm zum Nachbauen.

Hosts, Clients und Server

Vor MCP brauchte jede KI-Anwendung für jedes Tool einen eigenen Adapter: fünf Anwendungen und zwanzig Tools bedeuteten bis zu 100 Integrationen. Mit MCP decken 25 Implementierungen (ein Client pro Anwendung, ein Server pro Tool) jede Kombination ab.

Ein Host erzeugt pro Server einen Client, und jeder Client spricht mit genau einem Server. Das Modell ruft nie selbst einen Server auf: Es fordert einen Tool-Aufruf an, und der Host entscheidet, ob er ausgeführt wird und welcher Client ihn sendet. Server bleiben isoliert: Sie sollten weder die gesamte Konversation noch einander sehen.

Zwei Schichten und was 2026-07-28 geändert hat

Die Data Layer ist JSON-RPC 2.0: Requests (mit einer id, die nie null ist), Results, Errors und einseitige Notifications. Die Transport Layer befördert diese Nachrichten und kümmert sich um Framing, Abbruch und Autorisierung.

Die Spezifikation 2026-07-28, veröffentlicht am 28. Juli 2026, hat MCP zustandslos gemacht. Frühere Revisionen eröffneten jede Verbindung mit einem initialize-Handshake, der Version und Capabilities festlegte, und HTTP-Server konnten eine Session mit Mcp-Session-Id festhalten. Jetzt trägt jeder Request seine Protokollversion und die Client-Capabilities in _meta, sodass er auf jeder Server-Instanz hinter einem einfachen Round-Robin-Load-Balancer landen kann.

Server auf älteren SDKs erwarten weiterhin den Handshake, deshalb prüfen Clients für beide Epochen zuerst und fallen auf initialize zurück. Ein Client, der nur 2026-07-28 spricht, kann keinen reinen Legacy-Server nutzen. Das Changelog listet jede Breaking Change auf.

Transports: stdio und Streamable HTTP

Streamable HTTP hat in 2025-03-26 den HTTP+SSE-Transport (einen GET-Stream plus einen separaten POST-Endpoint) abgelöst; HTTP+SSE ist inzwischen offiziell deprecated. Gateways können anhand von Mcp-Method und Mcp-Name routen und Rate Limits setzen, ohne Bodies zu parsen, und Server weisen Requests ab, deren Header dem Body widersprechen. HTTP-Server müssen den Origin-Header gegen DNS Rebinding prüfen, und lokale sollten an 127.0.0.1 binden.

Server- und Client-Features

Der Form-Modus der Elicitation darf nie nach Passwörtern, API-Keys oder Tokens fragen; der URL-Modus schickt den Nutzer stattdessen auf eine Seite außerhalb des Clients. Sampling, Roots und Server-Logging wurden in 2026-07-28 als deprecated markiert und können frühestens in der ersten Revision entfernt werden, die am oder nach dem 28. Juli 2027 veröffentlicht wird.

Ein Tool-Aufruf, Schritt für Schritt

Das Modell legt über einen Remote-Server ein Issue an:

1. Optional ruft der Client server/discover für Versionen und Capabilities auf.
2. Der Client ruft tools/list auf. Der Host führt die Listen aller Server zusammen, stellt kollidierenden Namen ein Präfix voran und gibt sie dem Modell.
3. Das Modell fordert create_issue an. Der Host zeigt den Aufruf, und der Nutzer gibt ihn frei.
4. Der Client sendet tools/call, siehe unten.
5. Braucht der Server eine Bestätigung, liefert er input_required mit einer Elicitation-Anfrage zurück. Der Client fragt den Nutzer und wiederholt den Request mit der Antwort und dem undurchsichtigen requestState des Servers.
6. Das Ergebnis kommt als complete an. Ein Tool-Fehler setzt isError: true, damit sich das Modell selbst korrigieren kann.
7. Auf einem subscriptions/listen-Stream weist notifications/tools/list_changed den Client an, die Tools erneut aufzulisten.

POST /mcp HTTP/1.1
Host: mcp.tracker.example
Authorization: Bearer eyJhbGciOi...
Content-Type: application/json
Accept: application/json, text/event-stream
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: create_issue

{"jsonrpc": "2.0", "id": 7, "method": "tools/call",
 "params": {"name": "create_issue",
  "arguments": {"title": "Login fails on Safari"},
  "_meta": {"io.modelcontextprotocol/protocolVersion": "2026-07-28",
   "io.modelcontextprotocol/clientInfo": {"name": "my-ide", "version": "1.4.0"},
   "io.modelcontextprotocol/clientCapabilities": {"elicitation": {}}}}}

{"jsonrpc": "2.0", "id": 7, "result": {"resultType": "complete",
 "content": [{"type": "text", "text": "Created issue #482"}], "isError": false}}

Remote-Server und Autorisierung

Ein Remote-MCP-Server ist ein OAuth Resource Server; seine Tokens stammen von einem Authorization Server, den derselbe Anbieter oder ein separater Identity Provider betreibt. Bei der ersten Verbindung:

1. Der Client ruft ohne Token auf und erhält 401, meist mit einem WWW-Authenticate-Header, der auf die Protected Resource Metadata des Servers zeigt (RFC 9728).
2. Dieses Dokument, ersatzweise /.well-known/oauth-protected-resource, nennt den Authorization Server, dessen Metadaten der Client liest; er bricht ab, wenn PKCE nicht angekündigt wird.
3. Der Client nutzt eine vorab registrierte Client-ID, ein Client ID Metadata Document (eine HTTPS-URL als Client-ID) oder Dynamic Client Registration, die 2026-07-28 als deprecated markiert.
4. Der Client führt den Authorization-Code-Flow mit PKCE (S256) und einem resource-Parameter aus, der den MCP-Server benennt (RFC 8707). Der Nutzer meldet sich im Browser an und willigt ein, und der Client prüft das iss in der Antwort (RFC 9207).
5. Jeder Request trägt Authorization: Bearer. Ein 403 mit insufficient_scope löst Step-up-Autorisierung aus.

Der Server akzeptiert nur Tokens, die für ihn selbst ausgestellt wurden, und reicht sie nie durch: Aufrufe an eine Upstream-API nutzen ein separates Token. Das OAuth-2.0-Flow-Diagramm erklärt PKCE, und die Autorisierungsspezifikation enthält alle Regeln, aufgebaut auf dem OAuth-2.1-Draft.

Wo die Trust Boundaries liegen

Der stdio-Transport ist keine Sandbox: Der Leitfaden zur Sicherheit lokaler Server von MCP sagt, dass ein stdio-Server mit den Rechten des Clients läuft und die Isolation Sache des Hosts und desjenigen ist, der den Rechner betreibt. Ein State-Handle, den ein zustandsloser Server ausstellt, ist ebenfalls kein Credential; binde es an den authentifizierten Nutzer. Das Threat-Modeling-Datenflussdiagramm zeigt, wie du solche Boundaries mit STRIDE durchgehst.

Das MCP-Architekturdiagramm

So liest du es:

• Der grüne Rahmen ist eine Trust Domain: Der Host, seine drei Clients und beide stdio-Server laufen als OS-Nutzer des Entwicklers.
• Ein Client pro Server. Client 1 und 2 nutzen stdin und stdout; Client 3 nutzt Streamable HTTP.
• Graue Kanten vom Modell sind Tool-Aufrufe, die der Host weiterleitet; Server erreichen das Modell nie direkt.
• Blau läuft mit Bearer-Token über das Netzwerk. Gestricheltes Violett ist der OAuth-Flow, der nur läuft, wenn der Client kein gültiges Token hat.
• Türkis ist der Remote-Server, der seine API mit seinem eigenen Token aufruft: kein Passthrough.
• Der Markdown-Block fasst die Revision 2026-07-28 zusammen.

MCP-Architekturdiagramme klar zeichnen

• Ein Client pro Server. Eine einzelne «MCP»-Box verbirgt, was jeder Server sehen kann.
• Beschrifte Kanten mit Transport und Payload: stdin und stdout, ein POST mit Bearer-Token, ein OAuth-Flow, Beispiel-Tool-Namen.
• Zeichne Trust Boundaries als Rahmen: den Rechner, den Host, jeden Anbieter. Markiere Server in einer Sandbox.
• Gib dem Authorization Server und den Upstream-APIs eigene Nodes, damit Token-Quellen und die Regel «kein Passthrough» sichtbar sind.
• Nenne die Protokollrevision. Ein Diagramm für 2026-07-28 hat weder Handshake noch Session-IDs.
• Lass weg: SDK-Interna, vollständige Tool-Listen und die Infrastruktur des Modellanbieters.

Das AI-Agent-Architekturdiagramm behandelt den Agent-Loop um diese Aufrufe.

In Archboard nachbauen

1. Melde dich mit Google oder GitHub an und lege ein Diagramm an.
2. Füge für den Entwicklerrechner einen Rahmen aus dem Paket Basis hinzu und darin für den Host eine Containergrenze aus dem Paket C4 Model.
3. Füge in der Grenze ein Modell aus dem Paket ML und drei Komponente-Nodes aus dem Paket C4 Model für die Clients hinzu, mit den Technologien stdio, stdio und Streamable HTTP.
4. Füge zwei Container-Nodes aus dem Paket C4 Model für die lokalen Server hinzu, verbunden mit den Kanten «stdin / stdout», und eine Person aus demselben Paket, verbunden mit dem Modell.
5. Füge außerhalb des Rahmens eine Systemgrenze aus dem Paket C4 Model hinzu, die einen Container für den Remote-Server, ein Externes System für dessen API und einen Identitätsanbieter aus dem Paket Sicherheit enthält, und zeichne dann die Kanten für Bearer-Token, gestricheltes OAuth und «own token».
6. Füge einen Markdown-Block aus dem Paket Basis mit den Protokollfakten hinzu und Basis-Text-Notizen für die Boundaries.

Kein kostenloses Tool liest MCP-Client-Konfigurationsdateien, zeichne die Server also selbst oder füge ein Mermaid-Flowchart, etwa das aus der MCP-Spezifikation, in das Mermaid-zu-editierbarem-Diagramm-Tool ein.

Zum Zeitpunkt des Schreibens (November 2026) ist Archboard selbst ein Remote-MCP-Server unter https://getarchboard.app/mcp: Streamable HTTP, OAuth 2.1 von einem eigenen Authorization Server mit PKCE (S256) und dieser URL als Resource Indicator sowie Client-Registrierung per Client ID Metadata Document oder Dynamic Client Registration. Die MCP-Server-Dokumentation listet die Tools auf, und die AI-Agents-Seite zeigt, wie du deine App verbindest.

Das Beispiel nutzt 14 Diagramm-Nodes und bleibt damit im Free-Plan.

FAQ

Was ist der Unterschied zwischen MCP-Host, -Client und -Server? Der Host ist die KI-Anwendung, etwa eine IDE. Er erzeugt pro Server einen Client, und jeder Client hält eine dedizierte Verbindung zu einem Server, der Tools, Resources und Prompts bereitstellt.

Ist MCP jetzt zustandslos? Ja, seit Revision 2026-07-28: kein initialize-Handshake, keine Session-ID, und jeder Request trägt seine eigene Version und Capabilities. Server auf älteren Revisionen nutzen weiterhin den Handshake.

Welche Transports unterstützt MCP? Zwei standardisierte: stdio für lokale Server und Streamable HTTP für Remote-Server. HTTP+SSE ist deprecated, und eigene Transports müssen das JSON-RPC-Nachrichtenformat beibehalten.

Brauchen lokale MCP-Server OAuth? Nein. Die Spezifikation sagt, dass stdio-Server ihre Credentials aus der Umgebung beziehen sollen. Gib jedem ein eng gefasstes Token und betreibe Drittanbieter-Server in einer Sandbox.

Was ist Token Passthrough in MCP? Ein MCP-Server, der ein Token akzeptiert, das nicht für ihn ausgestellt wurde, oder das Token des Clients an eine andere API weiterreicht. Die Spezifikation verbietet das; Upstream-Aufrufe brauchen das eigene Token des Servers.

Kostenlos starten — ein Seat, keine Kreditkarte.