# MCP-Grundlagen: das Protokoll, die Rollen, der erste Aufruf > Das mentale Modell hinter MCP — welches Problem es löst, wer welche Rolle spielt, was ein Server anbietet und wie der erste Aufruf abläuft. Track: [MCP Engineering](https://physar.tech/learn/mcp-engineering) Kanonische Fassung: https://physar.tech/learn/mcp-engineering/mcp-basics Stand: 2026-07-26 Interaktiver Teil: 7 Checks (nur im Browser) ## MCP-Grundlagen: Protokoll, Rollen, erster Aufruf ### 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** > **Der Kern:** MCP tauscht multiplikativen Integrationsaufwand (`M×N`) gegen additiven (`M+N`). Der Wert liegt in **Wiederverwendung** und **Entdeckbarkeit** — nicht in Geschwindigkeit und nicht darin, andere Schichten wie Authentifizierung zu ersetzen. ### 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. | _[Abbildung: Host, Client und Server als getrennte Rollen: Der Host hält Policy und Consent, jeder Client verbindet 1:1 zu einem Server, und ein Server erhält nicht automatisch den übrigen Gesprächs- oder Serverkontext.]_ > **Vertrauensrichtung:** Der Host steuert, der Server bietet an. Ein Server kann den Host nicht zu etwas zwingen — er stellt Fähigkeiten zur Verfügung, und der Host entscheidet, was davon sichtbar oder ausführbar wird. ### 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**. _[Abbildung: Ein Server bietet Tools, Resources und Prompts an; die veröffentlichte Fähigkeit ist eine schmale Grenze zum internen Backend.]_ | | | | --- | --- | | 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. | > **Merksatz:** Tool = Aktion (modellgetrieben). Resource = Lesekontext (anwendungsgesteuert). Prompt = gewählter Workflow (nutzergesteuert). Dass etwas Daten zurückgibt, macht es noch nicht zum Tool. ### 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. _[Abbildung: Jede Verbindung durchläuft dieselbe Reihenfolge: erst initialisieren und Capabilities aushandeln, dann Requests wie Discovery und Aufruf, bis die Verbindung geschlossen wird.]_ 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 > **Discovery ist keine Ausführung:** Die Liste sagt nur, **was** es gibt. Erst der Aufruf löst eine Wirkung aus. Zwischen Entdecken und Ausführen liegt bewusst ein Schritt. ### 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`. > **Human in the Loop:** Die Sicherheitsprinzipien der Spezifikation stellen als Anforderung auf, dass Nutzer der Ausführung ausdrücklich zustimmen und sie verstehen; zusätzlich soll (`SHOULD`) stets ein Mensch in der Schleife bleiben, der einen Tool-Aufruf ablehnen kann. Ein entdecktes Tool ist damit **nicht** automatisch ein freigegebenes Tool. Diese Kontroll- und Vertrauensgrenzen vertiefen die Aufbau-Module (Trust Boundaries, Autorisierung). ### 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. > **Ziel:** Nach diesem Modul kannst du eine reale Integration den Rollen und Primitives zuordnen und benennen, wo Kontrolle und Freigabe sitzen — die Grundlage für die Intermediate- und Advanced-Module. ## Quellen - modelcontextprotocol.io/docs/learn/architecture — https://modelcontextprotocol.io/docs/learn/architecture - modelcontextprotocol.io/specification/2025-11-25/server/tools — https://modelcontextprotocol.io/specification/2025-11-25/server/tools - modelcontextprotocol.io/specification/2025-11-25/server/resources — https://modelcontextprotocol.io/specification/2025-11-25/server/resources - modelcontextprotocol.io/specification/2025-11-25/server/prompts — https://modelcontextprotocol.io/specification/2025-11-25/server/prompts - modelcontextprotocol.io/specification/2025-11-25/basic/lifecycle — https://modelcontextprotocol.io/specification/2025-11-25/basic/lifecycle - modelcontextprotocol.io/specification/2025-11-25 — https://modelcontextprotocol.io/specification/2025-11-25 - anthropic.com/news/model-context-protocol — https://www.anthropic.com/news/model-context-protocol - modelcontextprotocol.io/specification/2025-11-25/basic/index — https://modelcontextprotocol.io/specification/2025-11-25/basic/index