MCP ist ein offener Standard für die Anbindung von Werkzeugen an KI-Anwendungen, und Claude Code spricht ihn ab Werk. Der Unterschied zu einer Memory-Datei: die hält festen Kontext, ein MCP-Server liefert den Stand von jetzt — offene Issues, Zeilen aus der Produktionsdatenbank, den letzten Alarm aus dem Monitoring. Die Faustregel der Doku ist schlicht: Wenn du Daten regelmäßig aus einem anderen Fenster in den Chat kopierst, gehört dieses System an einen Server. Dieses Modul geht die Transporte durch, dann Ablageorte und Vorrang, die Tool-Suche, ein paar Muster aus der Praxis — und am Ende Channels, bei denen der Server von selbst etwas schickt.
Server anbinden
Vier Transporte stehen zur Wahl. http ist der empfohlene Weg zu entfernten Servern, stdio startet einen lokalen Prozess, sse gilt als veraltet und bleibt nur für Server ohne HTTP-Endpunkt, und ws hält eine dauerhafte Verbindung in beide Richtungen. Zwei Stolperstellen der JSON-Form: streamable-http ist dort ein erlaubter Aliasname für http, damit Beispiele aus fremden Server-Dokus unverändert funktionieren — und ein Eintrag mit url, aber ohne type, ist ein Konfigurationsfehler, denn ohne type liest Claude Code ihn als stdio-Server und überspringt ihn mit einem Hinweis. ws kennt nur Header-Authentifizierung und lässt sich nicht über --transport anlegen.
# 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" Verwaltet wird über claude mcp list, claude mcp get und claude mcp remove; in der Session zeigt /mcp den Status, die Tool-Zahl je Server und die Anmeldung. Seit v2.1.186 brauchst du für OAuth keine Session mehr: claude mcp login führt den Flow in der Shell, claude mcp logout löscht die gespeicherten Anmeldedaten. Ohne lokalen Browser — über SSH etwa — druckt der Befehl die Autorisierungs-URL, du öffnest sie am eigenen Rechner und fügst die vollständige Redirect-URL am Prompt ein; --no-browser erzwingt diesen Weg. Dazu kommen claude mcp reset-project-choices für die erteilten Zustimmungen, claude mcp add-from-claude-desktop für den Umzug aus Claude Desktop und claude mcp serve, wenn Claude Code selbst als Server auftreten soll. Namen wie workspace oder computer-use sind für eingebaute Server reserviert und werden abgewiesen.
Zwei Dateien halten die Konfiguration: ~/.claude.json für alles, was nur dich betrifft, und .mcp.json im Projekt-Wurzelverzeichnis für alles, was das Team teilt. Die Projektdatei wandert in die Versionsverwaltung, und wer sie zum ersten Mal öffnet, wird um Zustimmung gebeten. In beiden Formen ersetzt Claude Code Umgebungsvariablen — in command, args, env, url und headers, mit ${VAR} oder ${VAR:-default} für einen Rückfallwert. Fehlt die Variable und hat keinen Standard, lädt die Konfiguration trotzdem: claude mcp list warnt, und der Text bleibt unersetzt stehen — der Server scheitert dann beim Verbinden, nicht beim Laden:
{
"mcpServers": {
"github": {
"command": "npx",
"args": ["@modelcontextprotocol/server-github"],
"env": {
"GITHUB_TOKEN": "${GITHUB_TOKEN}"
}
}
}
} Für eine einzelne Session — ein Experiment, ein CI-Lauf, eine Reproduktion für den Bug-Report — lädt --mcp-config Server aus JSON-Dateien, ohne deine gespeicherte Konfiguration anzufassen. Das Flag nimmt einen Pfad oder mehrere, durch Leerzeichen getrennt, sodass eine geteilte Basis und lokale Abweichungen übereinanderliegen können. --strict-mcp-config blendet daneben jede andere Quelle aus; die Kombination ist der kürzeste Weg zu einem Fehlerbild, das jemand anderes nachstellen kann:
# 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 Beim Start wartet Claude Code nicht mehr auf die Server: seit v2.1.142 verbinden sie sich im Hintergrund, und ihre Tools tauchen auf, sobald sie fertig sind — MCP_CONNECTION_NONBLOCKING auf 0 holt das alte, blockierende Verhalten mit fünf Sekunden Wartezeit zurück. Das geschieht in Stapeln: bis zu 20 entfernte Server gleichzeitig, bis zu 3 lokale stdio-Prozesse, einstellbar über MCP_REMOTE_SERVER_CONNECTION_BATCH_SIZE und MCP_SERVER_CONNECTION_BATCH_SIZE. Braucht deine Anfrage ein Tool von einem Server, der noch verbindet, hält Claude an dieser Stelle an, statt ohne das Tool zu antworten.
Für Zeitlimits gibt es mehrere Schrauben, und sie greifen an verschiedenen Stellen. MCP_TIMEOUT begrenzt den Verbindungsaufbau beim Start. Ein timeout-Feld in Millisekunden im Server-Eintrag begrenzt den einzelnen Tool-Aufruf — hart nach Uhrzeit, Fortschrittsmeldungen verlängern es nicht, und Werte unter 1000 werden übergangen; dann gilt MCP_TOOL_TIMEOUT, dessen Standard bei etwa 28 Stunden liegt. Für HTTP-, SSE- und Connector-Server läuft zusätzlich eine Frist von 60 Sekunden bis zum ersten Antwortbyte. Wer gar nichts sendet, fällt in den Leerlauf-Abbruch: fünf Minuten bei HTTP, SSE, WebSocket und Connectors, 30 Minuten bei stdio, verstellbar über CLAUDE_CODE_MCP_TOOL_IDLE_TIMEOUT. Und ein Aufruf im Hauptgespräch, der länger als zwei Minuten braucht, wandert seit v2.1.212 in eine Hintergrundaufgabe, statt die Session zu blockieren.
Wer sich mit einem claude.ai-Konto anmeldet, findet die dort eingerichteten Connectors ohne Zutun in Claude Code wieder — geladen werden sie aber nur, solange genau diese Anmeldung aktiv ist; ein ANTHROPIC_API_KEY, ein apiKeyHelper oder ein Fremdanbieter schalten sie ab. Zeigt ein selbst angelegter Server auf dieselbe URL wie ein Connector, gewinnt der eigene Eintrag, und /mcp weist den Connector als verdeckt aus. Organisationen können einzelne Tools eines Connectors auf ask stellen — dann fragt Claude Code bei jedem Aufruf und merkt sich die Antwort ausdrücklich nicht — oder auf blocked, dann sieht Claude das Tool nie. Ganz abschalten lässt sich die Quelle über disableClaudeAiConnectors.
Scopes, Vorrang und Tool-Suche
Drei Scopes entscheiden, wo ein Server liegt und wer ihn sieht. Der Local-Scope ist die Vorgabe: der Eintrag landet in ~/.claude.json unter dem Pfad deines Projekts, gilt nur dort und nur für dich. Der Project-Scope schreibt in .mcp.json und teilt den Server über die Versionsverwaltung mit dem Team. Der User-Scope liegt ebenfalls in ~/.claude.json, aber projektübergreifend — gut für Werkzeuge, die du in jedem Projekt brauchst. Verwirrend ist dabei nur der Name: „local" heißt bei MCP-Servern nicht .claude/settings.local.json, sondern die Datei in deinem Home-Verzeichnis.
Steht derselbe Server an mehreren Stellen, verbindet Claude Code ihn einmal — mit dem Eintrag aus der stärksten Quelle, und zwar ganz: Felder werden nicht über Scopes hinweg vermischt. Die Reihenfolge ist Local, Project, User, Plugin-Server, claude.ai-Connector. Die drei Scopes erkennen Doppelungen am Namen, Plugins und Connectors am Endpunkt — wer auf dieselbe URL oder denselben Befehl zeigt, gilt also als dasselbe. Praktisch heißt das: Du kannst die Teamfassung eines Servers lokal überschreiben, ohne dass jemand anderes etwas merkt.
Prompts eines Servers erscheinen als Slash-Befehle im Muster /mcp__servername__promptname, Ressourcen lässt du mit @server:protocol://resource/path mitten im Satz einbinden. Die Tool-Definitionen selbst hält Claude Code standardmäßig zurück: zum Start laden nur Namen und die Server-Anweisungen, den Rest sucht Claude bei Bedarf — deshalb kostet ein zusätzlicher Server kaum Kontext. Über ENABLE_TOOL_SEARCH stellst du das um: true erzwingt die Zurückstellung, false lädt alles zum Sitzungsbeginn, auto lädt vorab, solange die Definitionen unter 10 % des Kontextfensters bleiben, und auto:N setzt diese Grenze selbst. Zwei Vorgaben weichen ab: auf Google Clouds Agent Platform und bei einem ANTHROPIC_BASE_URL, der nicht auf Anthropic zeigt, ist die Zurückstellung aus. Für Server-Autoren wichtig: Tool-Beschreibungen und Server-Anweisungen werden bei je 2 KB abgeschnitten. Bei der Ausgabe warnt Claude Code oberhalb von 10 000 Tokens und kappt bei 25 000, was MAX_MCP_OUTPUT_TOKENS hebt.
Soll ein Server von der Zurückstellung ausgenommen sein, setzt du alwaysLoad auf true in seinem Eintrag; dann liegen alle seine Tools ab Sitzungsbeginn im Kontext, unabhängig von ENABLE_TOOL_SEARCH. Ein Server kann dasselbe für ein einzelnes Tool erklären, über anthropic/alwaysLoad in dessen _meta-Objekt. Der Preis ist zweifach: jedes vorab geladene Tool belegt Kontext, und dieser eine Server blockiert den Start, bis er verbunden ist — höchstens fünf Sekunden, die übrigen verbinden weiter im Hintergrund. Sparsam einsetzen, für Tools, die Claude in jedem Zug braucht.
Ein Server muss nicht der ganzen Session gehören. Im Frontmatter eines Subagenten nennt mcpServers entweder den Namen eines schon konfigurierten Servers — dann teilt der Subagent die bestehende Verbindung — oder eine vollständige Definition, die nur für ihn gilt: sie verbindet sich, wenn er startet, und trennt sich, wenn er fertig ist. Das ist der saubere Weg, die Tool-Beschreibungen eines Spezialservers aus dem Hauptgespräch herauszuhalten. Die Beschränkungen der Hauptsession gelten mit, seit v2.1.153 auch hier: --strict-mcp-config, die verwaltete Konfiguration und die Allow- und Deny-Listen greifen, und ein blockierter Server wird mit Warnung übersprungen:
---
name: data-analyst
description: Analyze production data
mcpServers:
- database
- playwright:
type: stdio
command: npx
args: ["-y", "@playwright/mcp@latest"]
---Muster aus der Praxis
Hängt der GitHub-Server, sprichst du über Pull Requests, Issues und Commits in normalen Sätzen, und Claude holt die Antwort live vom Server statt aus deinem Zitat. Die dritte Zeile unten ist kein Prosa-Satz, sondern ein Prompt des Servers — aufgerufen wie ein Slash-Befehl, mit der PR-Nummer als Argument:
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 456Ein Datenbank-Server verschiebt die Grenze noch etwas: du fragst nach Zahlen, nicht nach SQL. Für den Anfang lohnt ein Zugang, der nur lesen darf — dann liefert eine missverstandene Frage höchstens eine falsche Auswertung und keine geänderte Zeile:
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?Mehrere Server lassen sich in einer Session kombinieren, und genau dort wird MCP interessant. Ein wöchentlicher Bericht etwa: Kennzahlen zu den Pull Requests vom GitHub-Server, Umsätze aus der Datenbank, der fertige Text über den Dateisystem-Server ins Repository, die Zusammenfassung über den Chat-Server ins Team — ein Auftrag, vier Systeme, kein Kopieren zwischen Fenstern.
Manche Server fragen mitten im Vorgang zurück. MCP nennt das Elicitation, und Claude Code zeigt es in zwei Formen: ein Formular mit den Feldern, die der Server beschreibt, oder eine Browser-URL, die du bestätigst — danach macht der Server dort weiter, wo er stehen geblieben ist. Einzurichten ist dafür nichts. Wer die Rückfragen automatisch beantworten will, greift mit dem Elicitation-Hook davor ein; der ElicitationResult-Hook sieht deine Antwort, bevor sie zum Server geht. Ein Aufruf, der auf einen offenen Dialog wartet, wandert übrigens nicht in den Hintergrund — er ist nicht langsam, er wartet auf dich.
Zur Absicherung gilt das Naheliegende, nur konsequenter: Anmeldedaten kommen aus Umgebungsvariablen, kein Token wandert in die Versionsverwaltung, Lesezugriff reicht meistens, und der Server bekommt nur den Bereich, den er wirklich braucht. Dazu zwei Punkte, die man leicht übersieht. Ein Server, der fremde Inhalte holt, holt damit auch fremde Anweisungen ins Gespräch — prüfe, wem du das zutraust. Und in Organisationen legt managed-mcp.json den erlaubten Serversatz zentral fest, mit allowedMcpServers und deniedMcpServers als Allow- und Deny-Liste.
Vier Verhaltensweisen fallen im Alltag auf, wenn man sie nicht kennt. Ein Server kann seine Tool-, Prompt- und Ressourcenliste per list_changed im Betrieb ändern, ohne dass du etwas neu verbindest; schlägt die Aktualisierung fehl, behält Claude Code die vorher bekannte Liste. Bricht eine HTTP- oder SSE-Verbindung mitten in der Session, wird bis zu fünfmal neu verbunden, beginnend bei einer Sekunde und jedes Mal verdoppelt; für den ersten Verbindungsversuch beim Start gilt seit v2.1.121 dasselbe Muster mit drei Anläufen, aber nur bei vorübergehenden Fehlern — eine abgelehnte Anmeldung wird nicht wiederholt, die ändert sich ohne dein Eingreifen nicht. Lokale stdio-Server startet Claude Code nicht von selbst neu. Und ein Server kann für ein einzelnes Tool erzwingen, dass jeder Aufruf bestätigt wird, über anthropic/requiresUserInteraction — gedacht für Schritte, bei denen die Rückfrage der eigentliche Zweck ist.
Channels: wenn der Server dich anspricht
Ein Channel dreht die Richtung um. Statt dass Claude einen Server fragt, schiebt der Server Ereignisse in die offene Session — eine Nachricht aus Telegram, ein CI-Ergebnis, ein Alarm aus dem Monitoring —, und Claude kann darauf reagieren, während du nicht am Terminal sitzt. Technisch ist es ein MCP-Server, der die Fähigkeit claude/channel anmeldet; die Richtung geht auch zurück, sodass eine Antwort im selben Chat landet. Eine Bedingung bleibt: Ereignisse treffen nur ein, solange die Session läuft. Wer dauerhaft erreichbar sein will, lässt Claude in einem Hintergrundprozess oder einem offenen Terminal laufen.
Die Funktion ist Research Preview, seit v2.1.80 dabei, und die Form des Flags kann sich noch ändern. Mitgeliefert sind Telegram, Discord und iMessage, dazu fakechat als Demo, die eine Chat-Oberfläche auf localhost startet — zum Ausprobieren ohne fremdes Konto. Jeder Channel ist ein Plugin und braucht Bun. Der Weg ist immer derselbe: Plugin installieren, Token setzen, Claude neu starten — und zwar mit dem Plugin als Argument des Flags, mehrere durch Leerzeichen getrennt:
claude --channels plugin:telegram@claude-plugins-official Jeder Channel führt eine Liste erlaubter Absender; alles andere wird stillschweigend verworfen. Telegram und Discord füllen sie über ein Pairing: du schreibst dem Bot, er antwortet mit einem Code, du bestätigst ihn in der Session. iMessage behandelt den Chat mit dir selbst als erlaubt und nimmt weitere Kontakte über ihren Handle auf. Zwei Dinge sind leicht zu übersehen. Ein Eintrag in .mcp.json genügt nicht — ein Server darf erst schieben, wenn er im Flag genannt ist. Und wenn der Channel Berechtigungsfragen weiterleitet, darf jeder erlaubte Absender Tool-Aufrufe freigeben; diese Liste ist damit keine Formsache.
Für Organisationen hängen Channels an zwei verwalteten Einstellungen. channelsEnabled ist der Hauptschalter — auf claude.ai-Team- und -Enterprise-Plänen sind Channels bis zur Freigabe blockiert, bei Console-Zugängen mit API-Key erlaubt, solange keine verwalteten Einstellungen ausgerollt sind. allowedChannelPlugins ersetzt, sobald es gesetzt ist, die von Anthropic geführte Liste zulässiger Plugins vollständig — auch um einen eigenen Marktplatz aufzunehmen. Pro- und Max-Zugänge ohne Organisation umgehen beide Prüfungen und entscheiden pro Session. Nicht verfügbar sind Channels auf Amazon Bedrock, Google Clouds Agent Platform und Microsoft Foundry.
Zum Schluss eine Kleinigkeit, die beim ersten Versuch irritiert: Antwortet Claude über einen Channel, steht die Antwort nicht in deinem Terminal. Dort siehst du die eingehende Nachricht, den Tool-Aufruf und eine Bestätigung — der Text selbst erscheint auf der anderen Plattform. Und im Modus -p sind Werkzeuge abgeschaltet, die eine Eingabe im Terminal bräuchten, damit die Session nicht auf jemanden wartet, der nicht da ist.