Claude Code erweitern mit MCP: externe Tools anbinden
Claude Code kann von Haus aus Dateien lesen, Shell-Befehle ausführen und im Web suchen. Aber was, wenn Claude direkt auf deine Datenbank zugreifen, ein Ticket in deinem Issue-Tracker anlegen oder einen selbst gehosteten Dienst abfragen soll? Genau dafür gibt es MCP – das Model Context Protocol. Es ist die einheitliche Schnittstelle, über die Claude Code mit externen Systemen spricht.
Dieser Beitrag setzt voraus, dass Claude Code bereits läuft. Falls nicht, starte mit der Einführung und dem Setup-Leitfaden.
Was ist MCP?
Das Model Context Protocol ist ein offener Standard, der KI-Anwendungen mit externen Tools und Datenquellen verbindet. Man kann es sich als „USB-C für KI-Tools” vorstellen: Statt für jedes System eine eigene Integration zu bauen, spricht Claude mit jedem MCP-Server über dieselbe Schnittstelle.
Ein MCP-Server ist ein kleines Programm (oder ein Cloud-Endpunkt), das eine Sammlung von Tools bereitstellt – etwa „lies diese Datei”, „führe diese SQL-Abfrage aus” oder „erstelle dieses Kalender-Event”. Claude Code ist der MCP-Client, der diese Tools bei Bedarf aufruft.
flowchart LR
U(["Du"]) --> CC["Claude Code<br/>MCP-Client"]
CC -->|stdio| S1["Dateisystem-Server<br/>lokaler Prozess"]
CC -->|http| S2["Git / Issues<br/>Cloud-Endpunkt"]
CC -->|http| S3["Kalender / API<br/>Cloud-Endpunkt"]
S1 --> D1[("Dateien")]
S2 --> D2[("Repository")]
S3 --> D3[("Externer Dienst")]
Die drei Transport-Typen
Ein MCP-Server wird über einen Transport angebunden. Welchen du wählst, hängt davon ab, wo der Server läuft:
| Transport | Wofür | Läuft |
|---|---|---|
stdio |
Lokale Prozesse auf deiner Maschine | als Kindprozess (z. B. via npx) |
http |
Remote-/Cloud-Dienste | über eine URL, oft mit OAuth |
ws (WebSocket) |
Persistente, bidirektionale Verbindungen | über eine wss://-URL |
Der frühere
sse-Transport (Server-Sent Events) gilt als veraltet. Nutzehttp, wo immer der Server es anbietet.
Einen Server hinzufügen
Der schnellste Weg ist der CLI-Befehl claude mcp add. Das Grundmuster:
1
claude mcp add --transport <typ> <name> <endpunkt-oder-befehl>
Lokaler Server (stdio)
Bei stdio-Servern trennt ein doppelter Bindestrich -- die Claude-Optionen vom eigentlichen Server-Befehl. Alles nach -- wird unverändert an den Server übergeben:
1
2
claude mcp add --transport stdio filesystem -- \
npx -y @modelcontextprotocol/server-filesystem ~/projekte
Dieser offizielle Filesystem-Server ist ein gutes, ungefährliches Beispiel zum Ausprobieren: Er gibt Claude Werkzeuge, um in einem klar abgegrenzten Verzeichnis zu lesen und zu schreiben.
Remote-Server (http)
1
2
claude mcp add --transport http github https://api.githubcopilot.com/mcp/ \
--header "Authorization: Bearer ${GITHUB_PAT}"
Status prüfen
In der laufenden Session zeigt dir /mcp ein Panel mit allen Servern, ihrem Verbindungsstatus und – bei OAuth-Servern – dem Login-Flow:
1
/mcp
Auf der Kommandozeile:
1
2
3
claude mcp list # alle Server + Status
claude mcp get <name> # Details zu einem Server
claude mcp remove <name> # Server entfernen
Scopes: wer sieht welchen Server?
MCP-Server können auf drei Ebenen konfiguriert werden. Das ist wichtig, sobald du im Team arbeitest:
| Scope | Speicherort | Sichtbar für | Team-Sharing |
|---|---|---|---|
| local (Standard) | projektbezogen, nur du | nur dieses Projekt | nein |
| project | .mcp.json im Repo-Root |
alle, die das Repo klonen | ja (via Git) |
| user | global auf deiner Maschine | alle deine Projekte | nein |
Für ein Setup, das dein ganzes Team teilen soll, ist der project-Scope ideal:
1
2
claude mcp add --transport stdio --scope project filesystem -- \
npx -y @modelcontextprotocol/server-filesystem "."
Das schreibt eine .mcp.json ins Repo, die mitversioniert wird:
1
2
3
4
5
6
7
8
9
{
"mcpServers": {
"filesystem": {
"type": "stdio",
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-filesystem", "${CLAUDE_PROJECT_DIR:-.}"]
}
}
}
Wer ein Repo mit
.mcp.jsonklont, muss die projekt-weiten Server beim ersten Start explizit bestätigen. Das ist eine bewusste Sicherheitsschranke – ein fremder MCP-Server bekommt nicht ungefragt Zugriff.
Secrets sicher halten
Trage niemals Klartext-Tokens in eine .mcp.json ein – die landet sonst im Git-Repo. MCP unterstützt die Expansion von Umgebungsvariablen direkt in der Konfiguration:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
{
"mcpServers": {
"secure-api": {
"type": "http",
"url": "https://api.example.com/mcp",
"headers": {
"Authorization": "Bearer ${API_TOKEN}"
}
},
"database": {
"type": "stdio",
"command": "python3",
"args": ["db-server.py"],
"env": {
"DB_PASSWORD": "${DB_PASS}",
"PORT": "${DB_PORT:-5432}"
}
}
}
}
Die Syntax:
${VAR}– wird durch den Wert vonVARersetzt; fehlt die Variable, gibt es einen Fehler.${VAR:-default}– nutztdefault, fallsVARnicht gesetzt ist.
Die eigentlichen Werte kommen dann aus deiner Umgebung – idealerweise aus einem verschlüsselten Secret-Store, den du vor dem Start lädst:
1
2
3
export API_TOKEN="…"
export DB_PASS="…"
claude
Das passt nahtlos zur allgemeinen Regel aus dem Setup-Leitfaden: Secrets nur als Umgebungsvariable referenzieren, Werte nie in Dateien oder Logs schreiben.
Ende-zu-Ende: Claude auf dein Compose-Verzeichnis loslassen
Genug Theorie – hier ein vollständiger Durchlauf. Ziel: Claude soll die docker-compose-Dateien deines Homelabs durchsehen und Ungereimtheiten finden. Dafür bekommt er über den offiziellen Filesystem-Server kontrollierten Zugriff auf genau ein Verzeichnis – nicht mehr.
1. Server hinzufügen (auf das Compose-Verzeichnis begrenzt):
1
2
claude mcp add --transport stdio homelab-fs -- \
npx -y @modelcontextprotocol/server-filesystem ~/homelab/compose
2. In der Session den Status prüfen – das Panel /mcp zeigt den Server und seine Tools:
1
/mcp
1
homelab-fs ✔ connected (12 tools)
3. Eine echte Aufgabe stellen, in normaler Sprache:
1
2
Du: Sieh dir mit den homelab-fs-Tools alle compose-Dateien durch.
Gibt es Dienste ohne restart-Policy oder mit :latest-Tag?
4. Claude arbeitet – er ruft die Tools des Servers auf (list_directory, read_file), liest die Dateien selbst und antwortet konkret:
1
2
3
4
Claude: 3 Dienste ohne restart-Policy:
- jellyfin, paperless, vaultwarden
2 Dienste mit :latest (schwer reproduzierbar):
- immich, adguard → besser auf feste Versionen pinnen
Der entscheidende Punkt: Claude hat nur auf ~/homelab/compose zugegriffen – nicht auf dein restliches Dateisystem. Der Server ist die kontrollierte Tür, durch die er darf, und der Pfad im Add-Befehl legt fest, wie weit sie aufgeht.
Dasselbe Muster funktioniert mit jeder Datenquelle: Tausche den Filesystem-Server gegen einen Datenbank- oder API-Server, und Claude arbeitet mit denselben Handgriffen auf deiner Datenbank oder einem selbst gehosteten Dienst – die Sprache bleibt „sag, was du willst”, die Werkzeuge liefert der Server.
Server finden
Fertige MCP-Server gibt es für viele Dienste – von GitHub über Datenbanken bis zu Projektmanagement-Tools. Gute Anlaufstellen:
- Anthropic-Verzeichnis: claude.ai/directory
- Offizielle Referenz-Server: das npm-Paket-Ökosystem unter
@modelcontextprotocol/* - Protokoll-Spezifikation: modelcontextprotocol.io
Für Homelab-Nutzer besonders interessant: Viele self-hosted Dienste bieten inzwischen eigene MCP-Server an, sodass Claude direkt mit deiner eigenen Infrastruktur arbeiten kann – ohne dass Daten das Haus verlassen.
Kurz-Referenz
| Befehl | Wirkung |
|---|---|
claude mcp add --transport stdio <name> -- <cmd> |
Lokalen Server hinzufügen |
claude mcp add --transport http <name> <url> |
Remote-Server hinzufügen |
claude mcp add --scope project … |
Server ins Repo (.mcp.json) schreiben |
claude mcp list |
Alle Server + Status anzeigen |
claude mcp get <name> |
Details zu einem Server |
claude mcp remove <name> |
Server entfernen |
/mcp (in Session) |
Status-Panel + OAuth-Login |
Fazit
MCP verwandelt Claude Code von einem reinen Code-Assistenten in eine Schaltzentrale für deine gesamte Werkzeuglandschaft. Der Einstieg ist bewusst niedrigschwellig: Ein einziger claude mcp add-Befehl bindet den ersten Server an, und der Filesystem-Server eignet sich perfekt zum gefahrlosen Experimentieren.
Zwei Dinge im Blick behalten – dann bleibt es sicher: Server nur aus vertrauenswürdigen Quellen, und Secrets ausschließlich über Umgebungsvariablen. Der Rest ist Ausprobieren.