Was ist MCP? Model Context Protocol einfach erklärt

MCP (Model Context Protocol) ist ein offener Standard, mit dem sich KI-Anwendungen mit externen Systemen verbinden, zum Beispiel mit Dateien, Datenbanken, Werkzeugen und fertigen Arbeitsabläufen. Anthropic hat ihn im November 2024 vorgestellt. Statt für jede Kombination aus KI-Anwendung und Werkzeug eine eigene Schnittstelle zu bauen, sprechen beide dieselbe Sprache.

Die Projektdokumentation selbst vergleicht MCP mit einem USB-C-Anschluss, also einem Stecker, der an viele Geräte passt. Stell dir vor, du verbindest einen KI-Agenten über einen GitHub-Server mit deinem Code. Danach kann er auf die Frage „Welche Pull Requests sind offen?“ selbst nachsehen, statt zu raten. Welche Server es gibt, zeigt dir unser MCP-Server-Verzeichnis.

1. Warum es MCP gibt

Ein Sprachmodell erzeugt Text. Auf deine Dateien, dein Ticketsystem oder deinen Kalender kommt es nur, wenn das Programm drumherum ihm diesen Zugriff baut. Früher brauchte dafür jede Anwendung für jedes Werkzeug einen eigenen Anschluss. Anthropic beschrieb das bei der Vorstellung so, dass jede neue Datenquelle eine eigene Integration erfordere.

MCP setzt an dieser Stelle an. Wer ein Werkzeug anbieten will, baut einen Server. Wer eine KI-Anwendung entwickelt, baut einen Client. Beide Seiten verstehen sich, ohne sich zu kennen. Am Anfang unterstützten Block und Apollo den Standard, Zed, Replit, Codeium und Sourcegraph arbeiteten damit. Im Dezember 2025 übergab Anthropic MCP an die Agentic AI Foundation, die unter dem Dach der Linux Foundation steht. Anthropic nennt dort ChatGPT, Gemini, Microsoft Copilot, Cursor und Visual Studio Code unter den Produkten mit MCP-Unterstützung.

2. Wie MCP funktioniert

2.1 Host, Client und Server

MCP kennt drei Rollen:

• Host: die KI-Anwendung, mit der du arbeitest, etwa ein Chatbot oder ein Coding-Agent.
• Client: ein Baustein im Host, der die Verbindung zu genau einem Server hält. Bindest du drei Server an, entstehen drei Clients.
• Server: das Programm, das Fähigkeiten bereitstellt.

Die Dokumentation nennt ein Beispiel. Visual Studio Code ist der Host. Verbindet es sich mit dem Sentry-Server, legt es dafür einen Client an. Kommt der Dateisystem-Server dazu, entsteht ein zweiter.

2.2 Die drei Server-Primitive

Ein Server kann drei Arten von Fähigkeiten anbieten:

• Tools: Funktionen, die das Modell aufrufen kann, etwa „Ticket anlegen“ oder „Datenbank abfragen“.
• Resources: Daten, die als Kontext dienen, etwa Dateiinhalte oder ein Datenbankschema.
• Prompts: wiederverwendbare Vorlagen, die eine Unterhaltung strukturieren.

Die meiste Aufmerksamkeit bekommen die Tools. Jedes Tool kommt mit Namen, einer Beschreibung und einem Eingabeformat. Genau diese Beschreibung liest das Modell, um zu entscheiden, ob und wie es das Tool nutzt. Das wird in Abschnitt 5 noch wichtig.

2.3 Nachrichten und Transporte

Die Nachrichten folgen JSON-RPC 2.0. Das ist ein schlichtes Format, in dem eine Seite eine Methode mit Parametern aufruft und die andere mit einem Ergebnis antwortet. Für den Transport gibt es zwei Wege:

• stdio: Der Host startet den Server als Programm auf demselben Rechner und redet über Standardeingabe und Standardausgabe mit ihm. Das ist schnell und braucht kein Netzwerk.
• Streamable HTTP: Der Server läuft im Netz, Nachrichten gehen per HTTP-POST hin und optional als Stream zurück. So kann ein Server viele Clients bedienen, und er kann sich per Token oder OAuth absichern.

Die Spezifikation trägt ein Datum als Version, die aktuelle Fassung ist vom 28. Juli 2026. Jede Anfrage nennt die Version, die sie spricht. Ein Server, der sie nicht kennt, antwortet mit einer Fehlermeldung samt den unterstützten Versionen.

3. Beispiel: ein Ticketsystem anbinden

Ein ausgedachtes Beispiel. Du willst, dass dein Agent Support-Tickets nachschlagen kann. Dafür gibt es einen (erfundenen) MCP-Server namens „tickets“. Beim Start fragt der Client ihn mit tools/list nach seinen Tools. Ein Eintrag sieht so aus:

{
  "name": "tickets_suchen",
  "title": "Tickets suchen",
  "description": "Sucht Support-Tickets nach Status und Kunde.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "status": { "type": "string", "enum": ["offen", "geschlossen"] },
      "kunde": { "type": "string" }
    },
    "required": ["status"]
  }
}

Der Agent trägt den Server in seiner Konfiguration ein. Bei Claude Code liegt sie in einer Datei .mcp.json im Projektordner. Der erste Eintrag ist ein lokaler stdio-Server, der zweite ein Server im Netz:

{
  "mcpServers": {
    "tickets": {
      "command": "npx",
      "args": ["-y", "tickets-mcp-server"],
      "env": {
        "TICKETS_API_TOKEN": "${TICKETS_API_TOKEN}"
      }
    },
    "wiki": {
      "type": "http",
      "url": "https://mcp.example.com/wiki"
    }
  }
}

Der Zugangsschlüssel steht nicht in der Datei, sondern als Umgebungsvariable. So landet er nicht im Repository.

Fragst du nun „Welche offenen Tickets hat die Müller GmbH?“, passiert Folgendes:

1. Das Modell sieht die Tool-Beschreibung und entscheidet, tickets_suchen aufzurufen.
2. Der Host fängt diesen Wunsch ab. Das Modell führt nichts selbst aus. Je nach Einstellung fragt der Host dich vorher um Erlaubnis.
3. Der Client schickt den Aufruf an den Server:

{
  "jsonrpc": "2.0",
  "id": 7,
  "method": "tools/call",
  "params": {
    "name": "tickets_suchen",
    "arguments": { "status": "offen", "kunde": "Müller GmbH" },
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientInfo": { "name": "mein-agent", "version": "1.0.0" },
      "io.modelcontextprotocol/clientCapabilities": { "elicitation": {} }
    }
  }
}

4. Der Server fragt sein Ticketsystem ab und antwortet:

{
  "jsonrpc": "2.0",
  "id": 7,
  "result": {
    "resultType": "complete",
    "content": [
      {
        "type": "text",
        "text": "2 offene Tickets für Müller GmbH: #4812 Rechnung fehlt, #4830 Passwort-Reset"
      }
    ]
  }
}

5. Der Host legt das Ergebnis in die Unterhaltung. Das Modell formuliert daraus die Antwort an dich.

Mehr Server und praktische Anleitungen findest du im MCP-Server-Verzeichnis. Wie Claude Code Server einbindet, steht in der Claude-Code-Anleitung.

4. Rechenbeispiel: das Anbindungsproblem

Warum der Standard sich lohnt, zeigt eine kurze Rechnung. In unserem Harness-Verzeichnis stehen 35 Coding-Agenten, die aktuell verfügbar sind. Dazu kommen 20 Werkzeuge, die ein Team anbinden will, etwa GitHub, Slack, eine Datenbank oder ein Ticketsystem. Das Werkzeug-Beispiel ist ausgedacht.

Ohne Standard

Anbindungen

700

Rechnung

35 Agenten × 20 Werkzeuge

Mit MCP

Anbindungen

55

Rechnung

35 Clients + 20 Server

Ansatz	Anbindungen	Rechnung
Ohne Standard	700	35 Agenten × 20 Werkzeuge
Mit MCP	55	35 Clients + 20 Server

Eigene Berechnung+ 1 weitere

PNG|SVG

CC BY 4.0

gradually.ai

Ohne gemeinsamen Standard müsste jeder Agent jedes Werkzeug einzeln anbinden. Mit MCP bringt jeder Agent einen Client mit, und jedes Werkzeug bekommt einen Server. Die Zahl wächst nur noch mit der Summe statt mit dem Produkt. In der Praxis binden nicht alle Agenten alle Werkzeuge an, die Rechnung zeigt das Prinzip.

5. Grenzen, Risiken und Missverständnisse

MCP macht Anbindungen einfach. Das ist zugleich das Risiko, denn jeder angebundene Server vergrößert, was dein Agent tun kann und was ihm untergeschoben werden kann.

• Versteckte Anweisungen in Tool-Beschreibungen. Das Modell liest die Beschreibung jedes Tools, du siehst sie meist nicht. Invariant Labs hat 2025 gezeigt, dass ein bösartiger Server dort Anweisungen verstecken kann, die das Modell befolgt (Tool Poisoning). Das ist eine Form von Prompt Injection. Auch die Ergebnisse eines Tools landen im Kontext und können Anweisungen enthalten.
• Zu weite Rechte. Ein lokaler Server läuft mit denselben Rechten wie die Anwendung, die ihn startet. Die MCP-Dokumentation warnt vor Servern aus unklarer Quelle und empfiehlt, jede Berechtigung so eng wie möglich zu halten.
• Kontextverbrauch. Die meisten Clients laden alle Tool-Definitionen vorab in das Context Window. Bei vielen Servern gehen so viele Token verloren, bevor deine erste Frage dran ist. Anthropic nennt ein Beispiel, in dem sich der Verbrauch von 150.000 auf 2.000 Token senken ließ, indem nur die gerade nötigen Tools geladen wurden.
• MCP ist kein Sicherheitsmodell fürs Modell. Der Standard regelt den Austausch von Kontext, nicht, wie die KI-Anwendung damit umgeht. Ob ein Aufruf bestätigt werden muss, entscheidet der Host.
• MCP ersetzt keine APIs. Es sitzt davor. Der Server übersetzt zwischen MCP und der API des Dienstes.
• „Server“ heißt nicht „im Internet“. Viele Server laufen als kleines Programm auf deinem eigenen Rechner.

6. Was heißt das für dich?

• Binde nur Server an, deren Herkunft du kennst. Prüfe den Anbieter und den Quellcode, bevor du einen Server startest, der auf deinem Rechner läuft.
• Gib so wenig Rechte wie möglich. Ein Server, der Tickets lesen soll, braucht keinen Schreibzugriff. Nimm Zugangsschlüssel mit engem Zuschnitt.
• Lass Aktionen mit Folgen bestätigen. Löschen, Senden und Bezahlen sollte dein Host nie ohne deine Freigabe ausführen.
• Beschränke dich auf wenige Server. Jeder zusätzliche kostet Kontext und erhöht die Fläche für Angriffe. Schalte ungenutzte ab.
• Fang klein an. Ein einzelner Server für das, was du täglich brauchst, ist ein guter Start. Wie das mit Agenten im Alltag aussieht, steht in Persönliche KI-Agenten, projektweite Hinweise für Agenten in AGENTS.md.