MCP (Model Context Protocol) gibt Claude Echtzeit-Zugriff auf externe Dienste. Anders als Memory-Dateien, die statischen Kontext speichern, lassen MCP-Verbindungen Claude Live-Daten abfragen — deine GitHub-Issues, die Produktionsdatenbank, Slack-Kanäle oder jeden Dienst mit einem MCP-Server. Dieses Modul behandelt das Hinzufügen von Servern, das Verständnis von Scopes und den effektiven Einsatz von MCP-Tools.
MCP-Server hinzufügen
Der schnellste Weg, einen Server hinzuzufügen, ist der claude mcp add -Befehl. Wähle den Transport, der zum Server-Typ passt: http für Remote-Server, stdio für lokal laufende Prozesse und sse für ältere Remote-Server, die noch nicht auf HTTP umgestellt haben. (Hinweis: SSE ist veraltet — nutze stattdessen HTTP-Server, wo verfügbar.) Unter nativem Windows nutzt du oft cmd /c beim Starten von npx-basierten stdio-Servern.
# Add a remote HTTP server
claude mcp add --transport http notion https://mcp.notion.com/mcp
# Add a local Node.js server via stdio
claude mcp add --transport stdio github -- npx @modelcontextprotocol/server-github
# Add with an auth header
claude mcp add --transport http my-api https://api.example.com/mcp \
--header "Authorization: Bearer $MY_TOKEN"
Verwalte deine Server mit claude mcp list, claude mcp get <name>, und claude mcp remove <name>. Der /mcp -Befehl innerhalb einer Session zeigt aktive Verbindungen und löst OAuth-Flows für Server aus, die eine browserbasierte Authentifizierung erfordern. Ab v2.1.186 kannst du diesen OAuth-Flow ausführen, ohne eine Session zu öffnen: claude mcp login <name> authentifiziert einen konfigurierten Server direkt aus deiner Shell, und claude mcp logout <name> löscht dessen gespeicherte Anmeldedaten. Übergib --no-browser , um die Autorisierungs-URL auszugeben, statt einen Browser zu öffnen — praktisch über SSH, wo du die URL auf deinem lokalen Rechner öffnest und die vollständige Redirect-URL wieder am Prompt einfügst. Weitere nützliche Befehle sind claude mcp reset-project-choices, claude mcp add-from-claude-desktop, und claude mcp serve , wenn Claude Code selbst als MCP-Server agieren soll.
MCP-Konfigurationen liegen in ~/.claude.json (deine lokale Benutzer-Konfiguration) oder .mcp.json im Projekt-Root (mit dem Team geteilt). Die .mcp.json -Datei wird in git eingecheckt und fragt Teammitglieder bei der ersten Nutzung nach Zustimmung. Die Expansion von Umgebungsvariablen funktioniert in allen Konfigurationsfeldern — nutze ${VAR:-default} für Fallbacks:
{
"mcpServers": {
"github": {
"command": "npx",
"args": ["@modelcontextprotocol/server-github"],
"env": {
"GITHUB_TOKEN": "${GITHUB_TOKEN}"
}
}
}
}
Für einmalige Sessions — schnelle Experimente, CI-Läufe oder gesandboxte Reproduktionen — --mcp-config lädt MCP-Server aus JSON-Dateien, ohne deine gespeicherte Konfiguration anzurühren. Das Flag akzeptiert einen oder mehrere Dateipfade (durch Leerzeichen getrennt), sodass ein einzelner Befehl eine geteilte Konfiguration über lokale Overrides legen kann. Kombiniere es mit --strict-mcp-config , um für diese Session jede andere MCP-Quelle zu ignorieren — der sauberste Weg, einen Bug gegen eine bekannte Server-Menge zu reproduzieren:
# Load a single config file for this session only
claude --mcp-config ./ci-servers.json
# Combine multiple files (space-separated)
claude --mcp-config "./shared-servers.json ./local-overrides.json"
# Reproduce a bug against exactly one server, ignoring user/project config
claude --strict-mcp-config --mcp-config ./repro.json
MCP-Server verbinden sich jetzt standardmäßig gleichzeitig. Wenn du mehrere Server konfiguriert hast — sowohl lokale stdio-Server als auch entfernte claude.ai-Connectors —, initialisieren sie beim Start parallel statt nacheinander. Das reduziert die Startlatenz für Projekte mit mehreren MCP-Integrationen deutlich.
Zwei verschiedene Timeouts steuern das MCP-Verhalten. Konfiguriere den Server-Start-Timeout mit der MCP_TIMEOUT -Umgebungsvariable (zum Beispiel MCP_TIMEOUT=10000 claude setzt beim Start einen Verbindungs-Timeout von 10 Sekunden). Die Tool-Ausführung hat ein separates Limit: Füge ein timeout -Feld in Millisekunden zum .mcp.json -Eintrag eines Servers hinzu — zum Beispiel "timeout": 600000 für zehn Minuten — um zu begrenzen, wie lange ein einzelner Tool-Aufruf an diesen Server laufen darf. Dieser serverspezifische Wert überschreibt die MCP_TOOL_TIMEOUT -Umgebungsvariable nur für diesen Server, es ist ein hartes Wall-Clock-Limit, das Fortschrittsbenachrichtigungen nicht verlängern, und Werte unter 1000 werden ignoriert.
In Claude.ai konfigurierte MCP-Connectors können auch automatisch in Claude Code erscheinen. Wenn du einen Server über die Weboberfläche einrichtest, wird er in deinen CLI-Sessions verfügbar, ohne separate lokale Konfiguration. Wenn derselbe Server sowohl lokal als auch über Claude.ai konfiguriert ist, werden Duplikate automatisch dedupliziert, damit du nicht mit zwei Verbindungen zum selben Dienst endest.
Scopes und Tool-Discovery
MCP-Konfigurationen haben drei Scopes. Der Local-Scope (gespeichert in ~/.claude.json unter dem Schlüssel deines Projekts) ist privat — nur du, nur dieses Projekt. Der Project-Scope (.mcp.json) wird über git mit dem Team geteilt. Der User-Scope (~/.claude.json global) gilt über all deine Projekte hinweg.
Wenn derselbe Server in mehreren Scopes definiert ist, gewinnt die lokale Konfiguration. So kannst du eine teamweite Server-Konfiguration zum Testen mit einer lokalen Version überschreiben, ohne jemand anderen zu beeinflussen.
MCP-Prompts erscheinen als Slash-Befehle nach dem Muster /mcp__servername__promptname. Auf MCP-Ressourcen kann inline verwiesen werden mit @server:protocol://resource/path. Tool-Search ist standardmäßig aktiviert — MCP-Tool-Definitionen werden zurückgestellt und bei Bedarf entdeckt, sodass nur die Tools, die Claude tatsächlich für eine Aufgabe nutzt, in den Kontext gelangen (nur auf Vertex AI ist es standardmäßig deaktiviert und wenn ANTHROPIC_BASE_URL auf einen Nicht-First-Party-Proxy zeigt). Überschreibe es mit der ENABLE_TOOL_SEARCH -Umgebungsvariable: true erzwingt, dass es immer an ist, false lädt jede Definition bei jedem Turn vorab, und auto aktiviert Tool-Search nur, wenn die Tool-Definitionen 10 % des Kontextfensters überschreiten (auto:N setzt einen eigenen Prozentsatz). Einzelne MCP-Tool-Beschreibungen und Server-Anweisungen sind jeweils auf 2KB begrenzt, um zu verhindern, dass OpenAPI-generierte Server den Kontext aufblähen. Eine Laufzeit-Warnung erscheint, wenn die Ausgabe eines MCP-Tools 10.000 Tokens überschreitet. Um dieses Limit zu erhöhen, setze die Umgebungsvariable MAX_MCP_OUTPUT_TOKENS (Standard 25.000).
Um die Zurückstellung für einen bestimmten Server zu überschreiben, füge alwaysLoad: true zu seiner Konfiguration hinzu — alle Tools dieses Servers überspringen die Tool-Search-Zurückstellung und sind in der Session immer verfügbar:
Subagent-bezogenes MCP lässt dich bestimmten Agents Zugriff auf Server geben, die der Rest der Session nicht braucht:
---
name: data-analyst
description: Analyze production data
mcpServers:
- database
- playwright:
type: stdio
command: npx
args: ["-y", "@playwright/mcp@latest"]
---
Praktische Nutzungsmuster
Mit verbundenem GitHub-MCP kannst du mit PRs, Issues und Commits in natürlicher Sprache arbeiten. Claude fragt den Server ab, erhält Live-Daten und antwortet:
List all open PRs that haven't been reviewed in more than 3 days.
Create an issue for the login timeout bug with medium priority.
/mcp__github__pr_review 456
Das Datenbank-MCP ermöglicht Abfragen in natürlicher Sprache, ohne selbst SQL zu schreiben:
Find all users who placed more than 5 orders in the last 30 days.
What's the average order value by country for Q1 2026?
Für komplexe Workflows lassen sich mehrere MCP-Server natürlich kombinieren. Ein täglicher Report-Workflow könnte: PR-Metriken vom GitHub-MCP abrufen, Verkaufsdaten vom Datenbank-MCP abfragen, mit dem Filesystem-MCP einen Report schreiben und ihn über das Slack-MCP posten — alles in einer einzigen Session.
MCP-Elicitation lässt einen Server den Workflow pausieren und strukturierte Eingaben vom Benutzer anfordern. Wenn ein Server Informationen braucht, die er nicht selbst bekommen kann — eine OAuth-Autorisierung, eine Bestätigung vor einer destruktiven Aktion oder ein Formular mit projektspezifischen Parametern —, löst er einen interaktiven Dialog aus. Der Benutzer sieht Formularfelder oder eine Browser-URL, gibt die Antwort und der Server macht dort weiter, wo er aufgehört hat. Die Elicitation und ElicitationResult Hooks lassen dich diese Dialoge programmatisch abfangen oder anpassen.
Sicherheits-Best-Practices: Nutze für Anmeldedaten immer Umgebungsvariablen, committe niemals Tokens nach git, nutze schreibgeschützte Tokens, wenn du nur Daten abfragen musst, und beschränke den Zugriffs-Scope des Servers auf das nötige Minimum. Für Enterprise-Deployments managed-mcp.json können Administratoren eine Allowlist zulässiger Server organisationsweit durchsetzen.
Weitere wichtige MCP-Fähigkeiten, die man kennen sollte: MCP-Server können list_changed -Benachrichtigungen senden, um ihre verfügbaren Tools, Prompts und Ressourcen dynamisch zu aktualisieren, ohne dass eine erneute Verbindung nötig ist. Wenn ein HTTP- oder SSE-Server mitten in der Session die Verbindung verliert, verbindet Claude Code sich automatisch mit exponentiellem Backoff neu — bis zu fünf Versuche, beginnend mit einer Sekunde Verzögerung, die sich jedes Mal verdoppelt. Für die anfänglichen Verbindungen beim Start gilt derselbe Backoff, es wird aber bei vorübergehenden Fehlern wie einer 5xx-Antwort, einer abgelehnten Verbindung oder einem Timeout bis zu dreimal erneut versucht (seit v2.1.121).
Channels: Events in eine laufende Session pushen
Channels sind MCP-Server, die Events in deine laufende Session pushen, damit Claude reagieren kann, während du nicht am Terminal bist. Anders als Standard-MCP-Server, die Claude bei Bedarf abfragt, liefert ein Channel Nachrichten proaktiv — eine Chat-Bridge von Telegram, ein CI-Webhook oder ein Monitoring-Alert. Events treffen nur ein, solange die Session offen ist.
Channels befinden sich in der Research Preview und erfordern Claude Code v2.1.80 oder neuer. Drei Plugins sind enthalten: Telegram, Discord, und iMessage. Jedes wird als Plugin installiert und mit deinen eigenen Anmeldedaten konfiguriert. Installiere ein Channel-Plugin mit /plugin install telegram@claude-plugins-official, konfiguriere es mit dem /telegram:configure <token> -Befehl des Plugins, dann starte neu mit dem --channels -Flag, um es zu aktivieren:
claude --channels plugin:telegram@claude-plugins-official
Jeder Channel führt eine Sender-Allowlist — nur IDs, die du hinzugefügt hast, können Nachrichten pushen. Telegram und Discord nutzen einen Pairing-Flow: Schreibe deinem Bot, erhalte einen Code und bestätige ihn dann in Claude Code mit /telegram:access pair <code> und sperre ab mit /telegram:access policy allowlist. iMessage umgeht das Pairing für den Self-Chat und lässt dich Kontakte per Handle hinzufügen.
Channels erfordern eine Anthropic-Authentifizierung (claude.ai oder Console-API-Key) und sind auf Bedrock, Vertex AI oder Foundry nicht verfügbar. Team- und Enterprise-Organisationen müssen Channels aktivieren über channelsEnabled in den Managed Settings — standardmäßig sind sie blockiert. Pro- und Max-Nutzer können Channels direkt nutzen, indem sie sich pro Session anmelden mit --channels. Admins können außerdem über das allowedChannelPlugins -Managed-Setting einschränken, welche Plugins zulässig sind.
Wenn Claude über einen Channel antwortet, erscheint die Antwort auf der externen Plattform (Telegram, Discord usw.) — dein Terminal zeigt den Tool-Aufruf und die Bestätigung, aber nicht den Antworttext selbst.