Was ist das MCP (Model Context Protocol) und wie funktioniert es?

Jeder KI-Assistent stößt an dieselbe Grenze: Er weiß viel über die Welt bis zum Trainingsstichtag, aber nichts über Ihre Dateien, Ihre Datenbank oder die interne API Ihres Unternehmens. Das Model Context Protocol (MCP) wurde genau entwickelt, um diese Lücke zu schließen. Seit Anthropic es Ende 2024 als offenen Standard veröffentlicht hat, ist es praktisch zu einer Art USB-C geworden, um Sprachmodelle mit externen Tools und Daten zu verbinden.

Was ist das MCP?

Das Model Context Protocol ist ein offenes Protokoll, das auf JSON-RPC 2.0 basiert und eine standardisierte Methode definiert, mit der ein Sprachmodell (oder die Anwendung, die es hostet) eine Verbindung zu Datenquellen und externen Tools herstellen kann. Anstatt dass jeder KI-Assistent seine eigene Art erfindet, eine Datei zu lesen, eine Datenbank abzufragen oder eine Automatisierung auszulösen, bietet das MCP eine gemeinsame Schnittstelle, die jeder Server implementieren und jeder Client nutzen kann.

Praktisch bedeutet das: Wer eine Integration baut, zum Beispiel einen Connector für GitHub oder Google Drive, erledigt diese Arbeit genau einmal in Form eines MCP-Servers. Jede kompatible Anwendung, wie Claude Desktop, Claude Code, eine IDE oder ein benutzerdefinierter Agent, kann diese Integration dann nutzen, ohne dafür spezifischen Code schreiben zu müssen. Das Protokoll organisiert die Kommunikation in drei Blöcke: Tools (Aktionen, die das Modell ausführen kann), Resources (Daten, die das Modell lesen kann) und Prompts (wiederverwendbare Instruktionsvorlagen), die alle in einem Format beschrieben sind, das das Modell zur Laufzeit selbst interpretiert.

Das Problem, das das MCP löst

Vor dem MCP bedeutete die Verbindung eines LLMs mit einem externen System in der Regel eine maßgeschneiderte Integration: ein Plugin hier, ein maßgeschneidertes Function Calling dort, ein Agent mit spezifischen API-Wrappern. Jede KI-Anwendung hatte ihre eigene Art, Tools bereitzustellen, und jedes Tool musste an jede Anwendung angepasst werden. Wenn ein Unternehmen 5 interne Tools unterhielt und diese in 3 verschiedenen Assistenten funktionieren sollten, waren 15 separate Integrationen zu warten, jede mit eigenem Authentifizierungsschema und Anfrageformat.

Dies ist das klassische „M-mal-N“-Problem: M Tools multipliziert mit N Anwendungen ergeben M×N Integrationsbrücken. Das MCP reduziert diese Gleichung auf M+N. Jedes Tool wird zu einem MCP-Server, der einmal gebaut wird; jede Anwendung wird zu einem kompatiblen MCP-Client, ebenfalls einmal gebaut; und jede Kombination der beiden Seiten funktioniert ohne zusätzlichen Aufwand. Es ist im Grunde die gleiche Logik wie beim Language Server Protocol, das Jahre zuvor entwickelt wurde, damit Code-Editoren nicht mehr für jede Programmiersprache einzeln native Unterstützung implementieren müssen.

Architektur des Protokolls

Das MCP folgt einer Client-Server-Architektur mit drei klar definierten Rollen:

• Host: Die Anwendung, die der Endbenutzer direkt verwendet, wie Claude Desktop, eine IDE mit integrierter KI oder ein eigener Agent.
• MCP-Client: Eine Komponente innerhalb des Hosts, die eine individuelle und isolierte Verbindung zu einem bestimmten MCP-Server aufrechterhält.
• MCP-Server: Ein separater Prozess, lokal oder remote, der Tools, Resources und Prompts für ein externes System bereitstellt.

Ein einzelner Host kann gleichzeitig mehrere MCP-Clients unterhalten, jeder verbunden mit einem anderen Server: einen für das Dateisystem, einen für Slack, einen für eine Postgres-Datenbank. Diese Regel „ein Client pro Server“ ist beabsichtigt, da sie Isolation gewährleistet. Ein Fehler oder Absturz in einem Server bringt die Verbindung zu den anderen nicht zum Erliegen.

Das folgende Diagramm fasst dieses Design zusammen:

Die Kommunikation zwischen Client und Server erfolgt über zwei Haupttransporte. Für lokale Server ist der Standard stdio, die Standardeingabe und -ausgabe des Prozesses, einfach und schnell, da kein Netzwerk erforderlich ist. Für entfernte Server erfolgt der Transport über HTTP mit Streamable HTTP, der Weiterentwicklung des früheren Server-Sent-Events-basierten Transports, was das Hosting eines MCP-Servers in der Cloud und die gleichzeitige Bedienung mehrerer Clients ermöglicht.

Der MCP-Client

Der Client lebt innerhalb des Hosts und kümmert sich um drei Dinge: Aufbauen und Aufrechterhalten der Verbindung zu einem Server, Übersetzen der Entscheidungen des Modells in JSON-RPC-Nachrichten und Zurückgeben der Serverantworten in den Gesprächskontext. In der Praxis führt der Client auch den anfänglichen Handshake durch, den Initialize-Schritt, bei dem Client und Server Informationen über die Protokollversion und unterstützte Fähigkeiten austauschen, sowie den Discovery-Prozess, bei dem er den Server fragt, welche Tools, Resources und Prompts er anbietet.

Ein wenig offensichtliches Detail ist, dass der Client nicht allein entscheidet, wann ein Tool verwendet wird. Diese Entscheidung liegt beim Modell: Der Client übergibt dem LLM die Liste der verfügbaren Tools, formatiert als Teil des Gesprächskontexts, und das Modell selbst wählt basierend auf der Benutzeranfrage aus, ob und welches Tool aufgerufen werden soll. Der Client führt den technischen Aufruf erst aus, nachdem das Modell entschieden hat.

Der MCP-Server

Auf der anderen Seite ist der Server derjenige, der tatsächlich mit dem externen System interagieren kann, sei es eine Datenbank, eine Drittanbieter-API oder das lokale Dateisystem. Ein gut gebauter MCP-Server stellt seine Fähigkeiten selbsterklärend dar: Jedes Tool hat einen Namen, eine Beschreibung in natürlicher Sprache und ein Schema, in der Regel JSON Schema, das definiert, welche Parameter es akzeptiert.

Diese Selbstbeschreibung macht das MCP steckbar. Der Server muss nicht wissen, welches Modell ihn konsumieren wird, und der Client benötigt keinen spezifischen Code für diesen Server, außer der Fähigkeit, das Protokoll zu sprechen. Heute gibt es bereits Hunderte von MCP-Servern, die von Unternehmen wie GitHub, Stripe, Cloudflare und Sentry veröffentlicht wurden, sowie ein großes Ökosystem von Community-Servern für Datenbanken, Produktivitätstools und interne Dienste.

Die Tools des MCP

Tools sind die am häufigsten genutzte Fähigkeit im MCP: Aktionen, die das Modell ausführen kann und die normalerweise Nebenwirkungen haben oder ein berechnetes Ergebnis zurückgeben, wie das Abfragen einer Wettervorhersage, das Erstellen einer Karte in Trello oder das Ausführen einer SQL-Abfrage. Das Protokoll definiert zwei weitere Arten von Fähigkeiten, die es wert sind, erwähnt zu werden:

• Resources: Daten, die der Server zum Lesen bereitstellt, wie der Inhalt einer Datei, eine Datenbankzeile oder das Ergebnis einer Abfrage. Im Gegensatz zu Tools haben Resources normalerweise keine Nebenwirkungen, sie sind lediglich Kontext, den der Host an das Gespräch anhängen kann.
• Prompts: Wiederverwendbare Instruktionsvorlagen, die der Server bereitstellt, wie eine fertige Anleitung zum Überprüfen eines Pull Requests oder zum Zusammenfassen eines Support-Tickets, die der Benutzer direkt aufrufen kann.

Jedes Tool wird durch ein Objekt mit name, description und inputSchema beschrieben. Diese Beschreibung, in natürlicher Sprache, aber strukturiert, ermöglicht es dem Modell zu verstehen, was das Tool tut, ohne dass jemand explizite Regeln für seine Verwendung programmieren muss.

Vollständiger Ablauf eines MCP-Aufrufs

Um zu verstehen, wie all dies in der Praxis zusammenhängt, lohnt es sich, den Lebenszyklus eines tatsächlichen Aufrufs zu verfolgen, so wie er zwischen Client und Server über JSON-RPC 2.0 übertragen wird.

Zunächst fragt der Client bei der Verbindung, welche Tools der Server anbietet:

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/list"
}

Der Server antwortet mit der vollständigen Liste, die bereits das Schema jedes Tools enthält:

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "tools": [
      {
        "name": "get_weather",
        "description": "Gibt die aktuelle Wettervorhersage für eine Stadt zurück",
        "inputSchema": {
          "type": "object",
          "properties": {
            "city": { "type": "string" }
          },
          "required": ["city"]
        }
      }
    ]
  }
}

Dieser Katalog wird dem Modell als Teil des verfügbaren Kontexts übergeben. Wenn der Benutzer eine Anfrage stellt, die das Modell als etwas interpretiert, das das Tool get_weather erfordert, erstellt und sendet der Client einen tools/call-Aufruf:

{
  "jsonrpc": "2.0",
  "id": 2,
  "method": "tools/call",
  "params": {
    "name": "get_weather",
    "arguments": { "city": "São Paulo" }
  }
}

Der Server führt die eigentliche Logik hinter dem Tool aus, in diesem Fall wahrscheinlich einen Aufruf an eine echte Wetter-API, und gibt das Ergebnis im selben JSON-RPC-Format zurück:

{
  "jsonrpc": "2.0",
  "id": 2,
  "result": {
    "content": [
      { "type": "text", "text": "23°C, klarer Himmel in São Paulo" }
    ]
  }
}

Der Client injiziert dieses Ergebnis zurück in das Gespräch, und das Modell verwendet die Informationen, um die endgültige Antwort an den Benutzer zu formulieren. Aus Sicht desjenigen, der mit dem Assistenten spricht, geschieht dies alles transparent: Man sieht nur die Frage und die Antwort, ohne zu wissen, dass im Hintergrund ein kompletter Protokollhandel stattgefunden hat.

MCP vs. traditionelle API

Es taucht oft die Frage auf: Wenn jedes externe Tool bereits eine REST-API hat, warum diese API nicht direkt verwenden? Die Antwort liegt im Unterschied zwischen der Integration eines Systems für einen menschlichen Entwickler, der die Dokumentation liest, und der Integration eines Systems für ein Modell, das es selbstständig in Echtzeit entdecken und nutzen soll.

Aspekt	Traditionelle REST-API	MCP
Entdeckung von Fähigkeiten	Externe Dokumentation (Swagger/OpenAPI), von einem Menschen gelesen	Der Client fragt den Server in Echtzeit, welche Tools existieren (tools/list)
Integration pro System	Ein dedizierter Connector für jede API	Ein einheitliches Standardprotokoll für jeden MCP-Server
Kommunikationsformat	HTTP + JSON, Schema variiert je nach Anbieter	Standardisiertes JSON-RPC 2.0
Kontext für das Modell	Der Entwickler entscheidet manuell, was dem LLM offengelegt wird	Der Server beschreibt Tools so, dass das Modell selbst entscheidet, was verwendet wird
Transport	Fast immer HTTP	stdio (lokal) oder HTTP mit Streamable HTTP (remote)
Wiederverwendbarkeit zwischen KI-Apps	Niedrig, jede App implementiert die Integration neu	Hoch, jeder kompatible Host verwendet denselben Server

In der Praxis ersetzt das MCP nicht die REST-API hinter dem Server, sondern ist eine Standardisierungsschicht darüber. Ein MCP-Server für GitHub ruft beispielsweise intern wahrscheinlich die GitHub-REST-API auf. Der Unterschied besteht darin, dass das Modell dies nie wissen muss: Es sieht nur Tools mit konsistenten Namen und Schemata, unabhängig davon, welche API dahintersteckt.

Praktisches Beispiel: Ein einfacher MCP-Server

Um das Protokoll praktisch zu veranschaulichen, passt ein minimaler MCP-Server in Python mit dem offiziellen SDK und der Klasse FastMCP in wenige Zeilen:

from mcp.server.fastmcp import FastMCP

mcp = FastMCP("clima-server")
@mcp.tool()
def get_weather(city: str) -> str:
    """Gibt die aktuelle Wettervorhersage für eine Stadt zurück."""
    # Der eigentliche Aufruf einer Wetter-API würde hier erfolgen
    return f"23°C, klarer Himmel in {city}"
if name == "main":
    mcp.run(transport="stdio")

Dieser Server stellt ein einzelnes Tool namens get_weather bereit. Der Dekorator @mcp.tool() kümmert sich bereits um die Generierung des JSON-Schemas aus der Funktionssignatur und dem Docstring, sodass das JSON-Schema nicht von Hand geschrieben werden muss. Wenn dieses Skript ausgeführt wird, lauscht es über stdio und ist bereit, dass sich jeder MCP-Client, wie der lokal konfigurierte Claude Desktop, verbindet und das Tool automatisch entdeckt.

Dieses Beispiel ist bewusst einfach, aber das gleiche Muster gilt für komplexere Server: Die Geschäftslogik (Abfragen einer Datenbank, Aufrufen einer kostenpflichtigen API, Auslösen einer Automatisierung) kommt in den Funktionskörper, und das SDK kümmert sich um den gesamten Protokollteil, Handshake und Serialisierung.

Sicherheit im MCP

Einem Sprachmodell direkten Zugriff auf Tools zu geben, die Dateien lesen, in Datenbanken schreiben oder Drittanbieter-APIs aufrufen, wirft eine offensichtliche Frage auf: Wer garantiert, dass dies nicht außer Kontrolle gerät? Das Protokoll definiert einige Schutzmaßnahmen, aber die endgültige Verantwortung wird zwischen Server, Client und demjenigen, der das System konfiguriert, aufgeteilt.

Auf Serverebene ist es bewährte Praxis, das Prinzip der geringsten Privilegien anzuwenden: Ein MCP-Server für das Dateisystem sollte beispielsweise den Zugriff auf bestimmte Verzeichnisse beschränken, niemals auf die gesamte Festplatte. Remote-Server, die HTTP-Transport verwenden, erfordern in der Regel eine Authentifizierung über OAuth 2.1, und die Protokollspezifikation behandelt dies ausführlich, gerade weil schlecht konfigurierte Server der offensichtlichste Angriffsvektor sind.

Auf Client- und Host-Ebene ist die für den Endbenutzer sichtbarste Sicherheitsebene die menschliche Zustimmung: Hosts wie Claude Desktop verlangen eine Bestätigung, bevor sie sensible Tools ausführen, wie das Schreiben einer Datei oder das Senden einer Nachricht, insbesondere beim ersten Verwenden eines Tools. Es besteht auch das Risiko von Prompt Injection über Resources, wenn bösartiger Inhalt, der in einem vom Modell gelesenen Dokument eingebettet ist, versucht, das Modell selbst zu einer unangemessenen Aktion zu manipulieren. Server, die Inhalte aus nicht vertrauenswürdigen Quellen wie Webseiten oder empfangenen E-Mails bereitstellen, verdienen sowohl von Seiten des Servererstellers als auch desjenigen, der sich entscheidet, ihn mit einem Agenten mit weitreichenden Berechtigungen zu verbinden, besondere Aufmerksamkeit.

Einschränkungen des MCP

Das MCP löst das Standardisierungsproblem, ist aber keine Wunderlösung für alles. Es lohnt sich, die tatsächlichen Grenzen zu kennen, bevor man sich entscheidet, darauf aufzubauen.

Erstens ist das Protokoll noch relativ neu, Ende 2024 veröffentlicht, und das Ökosystem hat trotz schnellen Wachstums noch Lücken: Nicht jedes beliebte Tool hat bereits einen ausgereiften und offiziell gepflegten MCP-Server. Zweitens bedeuten mehr gleichzeitig verfügbare Tools auch mehr Tokens, die für die Beschreibung dieser Tools im Gesprächskontext ausgegeben werden, was Aufrufe verteuern und in extremen Fällen mit dem restlichen Gesprächskontext konkurrieren kann. Drittens löst das Protokoll allein nicht das Zuverlässigkeitsproblem des Modells: Es kann immer noch das falsche Tool auswählen, falsche Argumente zusammenstellen oder ein vom Server zurückgegebenes Ergebnis falsch interpretieren, sodass eine sorgfältige Orchestrierung weiterhin Aufgabe des Agentenerstellers bleibt.

Schließlich ist die Authentifizierung und Zugriffsverwaltung in Unternehmensumgebungen, also wer welchen Server mit welchen Berechtigungen verbinden darf und wie dies auditiert wird, noch ein Bereich, der sich weiterentwickelt, mit viel Arbeit in der Community und bei Unternehmen, die das Protokoll in der Produktion einsetzen.

FAQ

Ist das MCP exklusiv für Anthropic und Claude?

Nein. Das MCP ist ein offenes Protokoll mit einer öffentlichen Spezifikation, und andere KI-Unternehmen sowie Agent-Frameworks haben bereits Unterstützung dafür angekündigt, auch wenn es innerhalb von Anthropic entstanden ist.

Muss ich programmieren können, um einen MCP-Server zu nutzen?

Um einen bereits fertigen Server wie den für Dateizugriff oder Google Drive in einer App wie Claude Desktop zu nutzen, nein. Programmieren ist nur erforderlich, wenn Sie einen neuen Server von Grund auf neu bauen möchten.

Ersetzt MCP Function Calling?

Nicht genau. Function Calling ist die Fähigkeit des Modells, einen Tool-Aufruf auszuwählen und zu formatieren. Das MCP nutzt diese Fähigkeit unter der Haube, fügt aber die Ebene der Entdeckung, Standardisierung und des Transports zwischen Client und Server hinzu, die das isolierte Function Calling nicht definiert.

Kann ein MCP-Server in der Cloud laufen?

Ja. Remote-Server verwenden HTTP-Transport und können normal gehostet werden, um mehrere Clients gleichzeitig zu bedienen, mit Authentifizierung über OAuth.

Der eigentliche Gewinn des MCP ist nicht technisch im Sinne von „noch einer API“, sondern organisatorisch: Es verwandelt ein Problem, das multiplikativ wuchs – jedes Tool für jede Anwendung – in ein Problem, das additiv wächst. Für diejenigen, die heute KI-Agenten bauen, ist das Verständnis dieses Protokolls nicht mehr optional. Es ist bereits das Infrastrukturteil, das einem De-facto-Standard am nächsten kommt, um Modelle mit allem zu verbinden, was außerhalb des Modells selbst existiert.