Eintrag
Lesenswert

Claude Code erweitern mit MCP: externe Tools anbinden

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. Nutze http, 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.json klont, 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 von VAR ersetzt; fehlt die Variable, gibt es einen Fehler.
  • ${VAR:-default} – nutzt default, falls VAR nicht 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:

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.

Dieser Eintrag ist vom Autor unter CC BY 4.0 lizensiert.