MCP-Grundlagen: Protokoll, Rollen, erster Aufruf
Einführung · 7 Abschnitte · ~7 Min Lesezeit · Stand
Warum es MCP gibt
Model Context Protocol (MCP) ist ein offener Standard, mit dem KI-Anwendungen an externe Tools und Datenquellen andocken. Ohne einen gemeinsamen Standard baut jede KI-App für jedes Tool einen eigenen Adapter. Bei N Apps und M Tools sind das N × M paarweise Integrationen — jede einzeln zu bauen, zu testen und zu pflegen. Das ist das M×N-Integrationsproblem.
- Ausgangslage: 3 KI-Apps und 4 Tools
- Ohne Standard: jede App baut jeden Adapter selbst → 3 × 4 = 12 paarweise Integrationen
- Mit MCP: jede App spricht einen Client, jedes Tool bietet einen Server
- Ergebnis: 3 + 4 = 7 Integrationsstellen statt 12
Die drei Rollen: Host, Client, Server
MCP folgt einer Client-Server-Architektur. Ein Host ist die KI-Anwendung (etwa eine Chat- oder IDE-App). Er erzeugt für jeden Server einen Client, und jeder Client hält eine dedizierte Verbindung zu genau einem Server. Verbindet sich der Host mit einem zweiten Server, erzeugt er einen zweiten Client. Die Rollen sind Verantwortungsgrenzen, keine Maschinen: Ein Prozess kann mehrere Clients halten.
| Host | Die KI-App. Besitzt Nutzerkontext, Modellzugang und die Freigabe-Policy. Koordiniert alle Clients. |
|---|---|
| Client | Der Baustein im Host, der eine dedizierte 1:1-Verbindung zu genau einem Server hält; über ihn besorgt der Host dessen Kontext und Fähigkeiten. Der Client ist die Komponente, nicht die Leitung selbst. |
| Server | Das Programm, das eine Fähigkeit bereitstellt. Bietet an, entscheidet aber nicht über Sichtbarkeit oder Ausführung. |
Was ein Server anbietet: Tools, Resources, Prompts
Ein Server veröffentlicht seine Fähigkeiten über drei Primitives. Sie unterscheiden sich nicht am Datenfluss, sondern daran, wer die Interaktion steuert.
| Tool | Eine ausführbare Aktion mit Wirkung, etwa ein API-Aufruf oder eine Datenbankabfrage. Modellgetrieben: Das Modell kann sie basierend auf dem Kontext vorschlagen. |
|---|---|
| Resource | Lesbarer Kontext, über eine URI adressierbar, etwa ein Dokument oder ein Statusbericht. Anwendungsgesteuert: Der Host entscheidet, wann und wie er ihn liest. |
| Prompt | Ein benannter, wiederverwendbarer Workflow-Einstieg. Nutzergesteuert: Der Nutzer wählt ihn bewusst aus. |
Der erste Aufruf, Schritt für Schritt
MCP ist ein zustandsbehaftetes Protokoll über JSON-RPC. Eine Verbindung beginnt immer mit derselben Reihenfolge: erst verbinden und Fähigkeiten aushandeln, dann entdecken, was der Server anbietet, dann gezielt aufrufen und das Ergebnis verarbeiten.
- Initialisierung: Client und Server handeln Protokollversion und Capabilities aus
- Discovery: der Client listet die angebotenen Fähigkeiten (z. B. `tools/list`)
- Aufruf: der Client ruft eine Fähigkeit gezielt auf (z. B. `tools/call`)
- Ergebnis: der Server antwortet, der Host verarbeitet die Antwort
Wer behält die Kontrolle
Weil Tools modellgetrieben sind, kann das Modell einen Aufruf vorschlagen, ohne dass ein Mensch ihn angestoßen hat. Deshalb legt MCP den Kontrollpunkt bewusst an den Host: Er entscheidet, was sichtbar wird, und er gibt die Ausführung frei — nach der Discovery und vor dem eigentlichen tools/call.
Typische Anfänger-Irrtümer
Drei Verwechslungen tauchen am häufigsten auf. Wer sie kennt, versteht MCP schon deutlich schärfer.
| „Ein Tool, weil es Daten liefert.“ | Nicht der Datenfluss entscheidet, sondern die Interaktionsart. Lesbarer, adressierbarer Kontext ist eine Resource; ein Tool ist eine Aktion mit Wirkung. |
|---|---|
| „MCP ist ein Plugin-Store oder API-Key-Manager.“ | MCP ist ein Protokoll für den Kontextaustausch. Es verteilt keine Plugins und ersetzt keine Authentifizierung — Auth bleibt eine eigene Schicht. |
| „Ein Server ist immer ein Remote-Netzwerkdienst.“ | Lokale Server über den stdio-Transport sind völlig normal; sie laufen als Prozess auf derselben Maschine. „Server“ meint die Rolle, nicht einen entfernten Host. |
Was gleich geprüft wird
Die folgenden Checks trainieren genau diese vier Achsen: wozu MCP passt (und wann nicht), wer welche Rolle und Kontrolle hat, welches Primitive ein Bedarf braucht, und wo im ersten Aufruf die Freigabe liegt. Es geht nicht um Auswendiglernen, sondern um die Zuordnung im konkreten Fall.