MCP · Lektion 01 · Architektur

Das mentale Modell: host, client, server

Bevor du eine Zeile Code schreibst, brauchst du ein Bild im Kopf, das du im Workshop ans Whiteboard zeichnen kannst. Das ist dieses Bild.

Dein Gewinn nach dieser Lektion: Du kannst das client-host-server-Diagramm aus dem Kopf zeichnen, die drei Primitive benennen und erklären, welches Problem MCP eigentlich löst — am lebenden Beispiel des forgejo-Servers, der gerade in deiner Claude-Code-Session läuft.

1. Welches Problem löst MCP?

Ein Agent (das LLM) ist ohne Werkzeuge ein Gehirn im Glas: er kann denken, aber nichts tun — keine Datei lesen, kein Issue anlegen, keine API rufen. Tools geben ihm Hände. Das Problem: bisher musste jede App ihre Tools selbst, proprietär, fest verdrahten. N Agents × M Tools = N×M Integrationen.

MCP ist die Standard-Steckdose dazwischen. Anthropic nennt es bewusst „a standardized way to connect AI applications to external systems“¹ — oft als „USB-C für KI-Anwendungen“ beschrieben. Ein Server, einmal nach MCP gebaut, funktioniert mit jedem MCP-fähigen Agent. Aus N×M wird N+M.

Merksatz für den Workshop: MCP standardisiert nicht was ein Tool tut, sondern wie ein Agent es entdeckt und aufruft.

2. Die drei Rollen

MCP folgt einer client-host-server-Architektur, gebaut auf JSON-RPC 2.0.¹ Drei Rollen, klar getrennt:

HOSTClaude Code,
Duo, Cursor…

▸

CLIENT1 pro Server,
im Host

▸

SERVERforgejo,
Files, DB…

Host — die Anwendung & der Koordinator

Der Prozess, mit dem du redest. Er hält das LLM, die ganze Konversation, und entscheidet über Berechtigungen/Consent. Er erzeugt für jeden Server einen Client.¹ In deiner Session ist der Host Claude Code.

Client — die isolierte Verbindung

Ein Client lebt im Host und hält genau eine stateful Session zu genau einem Server (1:1).¹ Er übersetzt zwischen Host und Server und hält die Sicherheitsgrenze: ein Server sieht nie die ganze Konversation und auch nicht die anderen Server.

Server — die Fähigkeit

Ein fokussiertes Programm, das Fähigkeiten bereitstellt. Das baust du. Der forgejo-Server in deiner Session stellt ~150 Tools bereit (create_issue, get_pr_diff, …). Server sollen laut Spec „extremely easy to build“ sein — die Komplexität liegt im Host.¹

Die Kern-Asymmetrie: Host ist schwer, Server ist leicht. Genau deshalb kannst du in einer Lektion einen Server bauen.

3. Was ein Server anbietet: die drei Primitive

Ein Server stellt seine Fähigkeiten über drei primitives bereit.² Der Unterschied ist wer die Kontrolle hat:

Tools — Funktionen, die das Modell aufruft, um etwas zu tun (z.B. ein Issue anlegen). Model-controlled.
Resources — Daten, die der Agent lesen kann (Datei, DB-Zeile, Doku). Wie ein GET, ohne Seiteneffekt. App-controlled.
Prompts — vordefinierte Vorlagen/Workflows, die der User auslöst (z.B. ein Slash-Command). User-controlled.

Für den ersten eigenen Server brauchst du nur Tools. Resources und Prompts kommen später.

4. Mini-Check (aus dem Gedächtnis!)

Nicht nachschauen — Abruf aus dem Kopf baut Storage Strength.

In deiner Session: was ist Claude Code in MCP-Begriffen?

Ein Agent soll ein Issue anlegen. Welches Primitive?

Warum sieht ein Server nie die ganze Konversation?

5. Primärquelle (lesen!)

📖 MCP Specification — Architecture. Kurz, präzise, mit genau dem Diagramm und den vier Design-Prinzipien. Lies die Abschnitte Core Components und Design Principles — das ist die Substanz hinter dieser Lektion.

Stockt etwas? Ich bin dein Tutor — frag mich direkt. Gute nächste Fragen: „Zeig mir die echten JSON-RPC-Messages zwischen Claude Code und forgejo“ oder „Wann nehme ich Resource statt Tool?“. Sag „weiter“, wenn du bereit für Lektion 2 (der Wire: JSON-RPC & der initialize-Handshake) bist.

1 — MCP Specification, Architecture (2025-06-18): modelcontextprotocol.io/specification/…/architecture

2 — MCP Docs, Server concepts: tools, resources, prompts: modelcontextprotocol.io/docs/concepts