MCP (Model Context Protocol) erklaert

Das Grundproblem: jedes Tool seine eigene Integration

Ein Sprachmodell kann von Haus aus nur mit dem sprechen, was im Prompt steht. Sobald es auf externe Daten zugreifen oder etwas tun soll - eine Datenbank abfragen, ein Ticket anlegen, eine Datei lesen - braucht es eine Bruecke zur Aussenwelt. KI-Agents und Tool-Nutzung beschreibt das Grundprinzip: Das Modell bekommt eine Liste verfuegbarer Funktionen (Tools) beschrieben, entscheidet im Gespraech, welche es aufrufen will, und bekommt das Ergebnis zurueck in den Kontext gemischt.

Das Problem, das lange offen blieb: Ohne gemeinsamen Standard baut jede Anwendung ihre eigene Tool-Integration. Ein Chatbot mit Datenbank-Zugriff, Dateisystem-Zugriff und Slack-Integration brauchte drei komplett verschiedene, massgeschneiderte Anbindungen - und ein Tool-Anbieter, der zehn verschiedene KI-Anwendungen unterstuetzen wollte, musste zehnmal dieselbe Arbeit machen, nur mit anderen Schnittstellen. Das ist das klassische “M mal N”-Integrationsproblem: bei M Anwendungen und N Tools braucht es im schlimmsten Fall M×N einzelne Integrationen.

MCP (Model Context Protocol) loest genau das. Anthropic hat das Protokoll 2024 als offenen Standard veroeffentlicht und seither zusammen mit der Community weiterentwickelt: eine einheitliche Sprache, mit der KI-Anwendungen (“Hosts”) sich mit Datenquellen und Werkzeugen (“Servern”) verbinden - unabhaengig davon, welches Modell dahintersteckt oder wer den Server geschrieben hat. Ein Server wird einmal gebaut und funktioniert danach in jeder MCP-faehigen Anwendung, ob das Claude Desktop, Claude Code, VS Code, Cursor oder ein selbstgebauter Agent ist.

Architektur: Host, Client und Server

MCP folgt einem Client-Server-Modell mit drei klar getrennten Rollen:

MCP HOST (die KI-Anwendung, z.B. Claude Code, Claude Desktop, ein eigener Agent)
  |
  +-- MCP Client 1 ---- dedizierte Verbindung ---- MCP Server A (z.B. Dateisystem, lokal)
  +-- MCP Client 2 ---- dedizierte Verbindung ---- MCP Server B (z.B. Datenbank, lokal)
  +-- MCP Client 3 ---- dedizierte Verbindung ---- MCP Server C (z.B. Sentry, remote)

• Host: die Anwendung, die das Sprachmodell steuert und die Verbindungen verwaltet - also Claude Code, Claude Desktop, aber auch VS Code oder ein selbstgeschriebenes Agent-Programm.
• Client: eine Komponente innerhalb des Hosts, die genau eine Verbindung zu genau einem Server haelt. Fuer jeden verbundenen Server legt der Host einen eigenen Client an.
• Server: ein eigenstaendiges Programm, das Kontext bereitstellt - Tools, Daten oder Prompt-Vorlagen. Ein Server kann lokal auf demselben Rechner laufen (z.B. ein Dateisystem-Zugriff per stdio) oder remote gehostet sein (z.B. ein Sentry- oder Slack-Server, den der Anbieter betreibt).

Wichtig: “MCP-Server” bezeichnet die Rolle im Protokoll, nicht zwingend einen entfernten Rechner. Ein lokal laufendes Skript, das per Standard-Ein-/Ausgabe mit dem Host spricht, ist genauso ein “Server” wie ein Cloud-Dienst, der ueber HTTPS erreichbar ist.

Die drei Primitives, die ein Server anbietet

MCP definiert drei grundlegende Bausteine, die ein Server einem Client anbieten kann:

Umgekehrt kann auch der Client dem Server etwas anbieten - unter anderem Sampling (der Server bittet den Host, eine Modellantwort fuer ihn zu generieren, ohne selbst ein eigenes Modell einzubinden) und Elicitation (der Server fragt bei Bedarf gezielt beim Menschen nach, etwa um eine Aktion zu bestaetigen). Fuer die allermeisten Alltagsfaelle reicht das Verstaendnis der Server-Primitives Tools, Resources und Prompts.

Wie ein Aufruf technisch ablaeuft

Unter der Haube ist MCP ein Protokoll auf Basis von JSON-RPC 2.0 - reine JSON-Nachrichten, jede mit einer eindeutigen id, die Anfrage und Antwort verknuepft. Ein typischer Ablauf, vereinfacht dargestellt:

// 1. Client fragt: welche Tools bietest du an?
{ "jsonrpc": "2.0", "id": 2, "method": "tools/list" }

// 2. Server antwortet mit Beschreibung + Eingabeschema
{
  "jsonrpc": "2.0", "id": 2,
  "result": {
    "tools": [{
      "name": "weather_current",
      "description": "Aktuelles Wetter fuer einen Ort abrufen",
      "inputSchema": {
        "type": "object",
        "properties": { "location": { "type": "string" } },
        "required": ["location"]
      }
    }]
  }
}

// 3. Client (im Auftrag des Modells) ruft das Tool auf
{
  "jsonrpc": "2.0", "id": 3,
  "method": "tools/call",
  "params": { "name": "weather_current", "arguments": { "location": "Zuerich" } }
}

// 4. Server liefert das Ergebnis zurueck
{
  "jsonrpc": "2.0", "id": 3,
  "result": { "content": [{ "type": "text", "text": "14 Grad, bewoelkt" }] }
}

Bevor dieser Austausch beginnt, handeln Client und Server bei der Verbindungsaufnahme (initialize) aus, welche Protokollversion und welche Faehigkeiten (Capabilities) beide unterstuetzen - erst danach folgen die eigentlichen Tool-, Resource- und Prompt-Aufrufe. Aendert sich das Angebot eines Servers waehrend der Sitzung (z.B. weil ein neues Tool dazukommt), kann er eine list_changed-Benachrichtigung schicken, und der Client fragt die Liste automatisch neu ab - ohne dass die Verbindung neu aufgebaut werden muss.

Zwei Transportarten: lokal vs. remote

Die Nachrichten selbst sind immer JSON-RPC, aber wie sie uebertragen werden, unterscheidet sich je nach Einsatzort:

Frueher gab es zusaetzlich einen reinen SSE-Transport fuer entfernte Server; der gilt inzwischen als veraltet zugunsten von Streamable HTTP, taucht in aelterer Dokumentation aber noch auf. Ein lokaler stdio-Server bedient in aller Regel genau einen Client, waehrend ein per HTTP erreichbarer Remote-Server gleichzeitig viele Clients unterschiedlicher Nutzer bedienen kann.

MCP und Claude

Claude selbst - egal ob im Claude-Chat, in Claude Desktop oder ueber die API - “spricht” MCP nicht direkt; es ist die jeweilige Anwendung (der Host), die MCP-Server einbindet und dem Modell die daraus gewonnenen Tools zur Verfuegung stellt. Auf claude.ai heissen fertig eingerichtete MCP-Anbindungen “Konnektoren” (Connectors) - etwa fuer Gmail, Google Calendar oder Slack, die sich mit ein paar Klicks aktivieren lassen. Wer selbst Software gegen Claude entwickelt, kann ueber die Anthropic-API und die offiziellen SDKs (Python, TypeScript) sowohl eigene MCP-Server bauen als auch MCP-Clients in eigene Anwendungen integrieren.

Claude Code ist der Ort, an dem MCP im Entwickleralltag am sichtbarsten wird: Es ist selbst ein vollwertiger MCP-Host und kann sich mit beliebig vielen Servern gleichzeitig verbinden - Issue-Tracker, Datenbanken, Monitoring-Tools, Design-Werkzeuge. Praktisch heisst das: Statt Daten aus Jira, Sentry oder einer Postgres-Datenbank manuell in den Chat zu kopieren, liest und veraendert Claude Code sie direkt ueber den verbundenen Server.

Praxis: einen MCP-Server in Claude Code anbinden

Server werden ueber den Befehl claude mcp add konfiguriert. Fuer die meisten Cloud-Dienste ist das der einfachste Weg - kein manuelles JSON-Editieren noetig:

# Remote-Server per HTTP verbinden (empfohlener Weg fuer Cloud-Dienste)
claude mcp add --transport http sentry https://mcp.sentry.dev/mcp

# Mit Authentifizierungs-Header (z.B. fuer ein Bearer-Token)
claude mcp add --transport http github https://api.githubcopilot.com/mcp/ \
  --header "Authorization: Bearer DEIN_GITHUB_TOKEN"

# Lokalen Server per stdio starten (z.B. ein npm-Paket)
claude mcp add --transport stdio airtable -- npx -y airtable-mcp-server

# Konfigurierte Server anzeigen, Details pruefen
claude mcp list
claude mcp get sentry

Server, die OAuth 2.0 verwenden (die meisten Cloud-Konnektoren), werden ueber den Befehl /mcp innerhalb einer Claude-Code-Sitzung authentifiziert - ein Browser-Login-Fenster oeffnet sich, danach ist die Verbindung aktiv. Ob ein Server tatsaechlich verbunden ist, zeigt derselbe Befehl /mcp mit Status “connected” oder “failed” an.

Wichtig ist die Wahl des Scope, also wo die Konfiguration gespeichert wird:

Entscheidungshilfe: welchen Scope waehlen?
  Soll der Server im ganzen Team verfuegbar sein?
    Ja  -> project-Scope, Zugangsdaten NICHT im Klartext einchecken
    Nein -> Brauchst du ihn nur in diesem einen Projekt?
              Ja  -> local-Scope (Standard)
              Nein -> user-Scope (projektuebergreifend, nur fuer dich)

Einen eigenen MCP-Server schreiben

Fuer eigene Datenquellen oder interne Tools lohnt sich ein selbstgeschriebener Server. Das offizielle Python-SDK macht das mit wenigen Zeilen moeglich:

from mcp.server.fastmcp import FastMCP

mcp = FastMCP("firmenwiki-server")

@mcp.tool()
def suche_wiki(begriff: str) -> str:
    """Durchsucht das interne Firmenwiki nach einem Begriff."""
    treffer = wiki_datenbank_suchen(begriff)  # eigene Anbindung
    return treffer or "Keine Treffer gefunden."

@mcp.resource("wiki://kategorien")
def liste_kategorien() -> str:
    """Liefert alle verfuegbaren Wiki-Kategorien als Kontext."""
    return ", ".join(alle_kategorien())

if __name__ == "__main__":
    mcp.run(transport="stdio")

Der Server laesst sich danach lokal einbinden (claude mcp add --transport stdio firmenwiki -- python firmenwiki_server.py) und ist ab dann fuer jede Anfrage in Claude Code als Tool suche_wiki verfuegbar. Fuer produktive, im Team geteilte Server ist ein remote per Streamable HTTP erreichbarer Dienst meist die bessere Wahl - er laeuft zentral, muss nicht auf jedem Rechner installiert werden und unterstuetzt saubere Authentifizierung ueber OAuth.

Kurz zusammengefasst

• MCP ist ein offener Standard, der die Anbindung von Tools und Datenquellen an LLMs vereinheitlicht - ein Server wird einmal gebaut und funktioniert in jeder MCP-faehigen Anwendung.
• Die Architektur trennt Host (die KI-Anwendung), Client (eine Verbindung pro Server) und Server (stellt Kontext bereit) sauber voneinander.
• Server bieten drei Primitives an: Tools (Aktionen), Resources (Daten) und Prompts (Vorlagen) - Tools sind in der Praxis am haeufigsten.
• Unter der Haube laeuft alles ueber JSON-RPC 2.0, uebertragen entweder per stdio (lokal) oder Streamable HTTP (remote, mit OAuth-Unterstuetzung).
• Claude Code bindet Server per claude mcp add ein, mit Wahl des Scope (local, project, user) je nachdem, wie und mit wem die Konfiguration geteilt werden soll.
• Ein eigener Server laesst sich mit dem offiziellen SDK in wenigen Zeilen bauen - fuer geteilte Nutzung lohnt sich ein remote erreichbarer HTTP-Server statt eines lokalen Skripts.
• MCP-Server sind eine Vertrauensentscheidung: sie koennen Aktionen ausloesen und sind ein potenzieller Angriffsvektor fuer Prompt-Injection.

Weiterlernen

• Model Context Protocol: Einfuehrung (offizielle Doku) - Ueberblick und Grundkonzepte
• MCP: Architecture Overview - Host/Client/Server-Modell, Primitives, JSON-RPC-Beispiele im Detail
• MCP Specification - die vollstaendige technische Spezifikation
• Claude Code: MCP-Referenz - alle Konfigurationsoptionen, Scopes, Authentifizierung
• MCP Reference Server Implementations (GitHub) - fertige Beispiel-Server als Vorlage
• Anthropic Connector Directory - Uebersicht gepruefter Konnektoren fuer claude.ai und Claude Code

Verwandte Themen: KI-Agents und Tool-Nutzung · LLM-APIs Grundlagen · RAG fuers Firmenwissen · KI-Sicherheit in Unternehmen