Claude Code und MCP: Server einbinden und im Team betreiben

Es gibt einen Moment, an dem man merkt, dass etwas fehlt: Man kopiert zum dritten Mal an diesem Vormittag einen Ticket-Text aus dem Browser ins Terminal, damit Claude Code weiß, worum es überhaupt geht. Genau diese Handgriffe nimmt das Model Context Protocol weg. Statt Inhalte hin und her zu kopieren, bekommt Claude Code einen direkten Zugang zu dem System, in dem sie stehen.

Was MCP als Protokoll ist, woher es kommt und wie es sich von einer klassischen API oder von RAG unterscheidet, steht in unserem Grundlagenbeitrag Was ist ein MCP-Server?. Dieser Beitrag setzt das voraus und bleibt konsequent bei Claude Code: einbinden, richtig einordnen, im Team ausrollen. Der Einrichtungsteil ist schnell erzählt. Interessant wird es danach, bei den Fragen, an denen MCP-Setups in der Praxis scheitern.

Was MCP in Claude Code konkret ändert

Ein MCP-Server ist eine Brücke zwischen Claude Code und einem anderen System. Er meldet Claude Code, welche Werkzeuge er anbietet, und führt sie auf Anfrage aus. Aus Sicht der Arbeit heißt das: Claude Code liest ein Jira-Ticket selbst, fragt die Datenbank selbst ab und legt den Pull Request selbst an, statt auf das zu warten, was ihr ins Fenster einfügt.

Die praktische Faustregel für die Frage, ob sich ein Server lohnt, ist erstaunlich einfach und stammt aus Anthropics eigener Dokumentation: Bindet einen Server an, sobald ihr merkt, dass ihr Daten aus einem anderen Werkzeug in den Chat kopiert. Kopiert ihr nichts, braucht ihr auch keinen Server. Diese Regel schützt vor dem häufigsten Fehler, nämlich einem Dutzend installierter Server, von denen drei je benutzt werden.

Neben Werkzeugen kann ein Server auch Inhalte und fertige Prompts bereitstellen. Inhalte referenziert ihr im Chat direkt mit einem At-Zeichen, etwa @github:issue://123. Prompts eines Servers erscheinen als Slash-Befehle im Format /mcp__servername__promptname, also zum Beispiel /mcp__github__list_prs. Wer im Eingabefeld einen Schrägstrich tippt, sieht sie in der Liste der verfügbaren Befehle stehen.

Drei Wege, wie ein Server angebunden wird

Bevor ihr den ersten Befehl tippt, lohnt sich eine Minute für die Frage, wie der Server überhaupt erreichbar ist. Davon hängt der Befehl ab, und später hängt davon auch das Fehlerbild ab, wenn etwas klemmt.

Lokal als Prozess: stdio

Bei einem stdio-Server startet Claude Code das Programm selbst und redet über die Standardein- und -ausgabe mit ihm. Für die meisten Server, die ihr auf dem eigenen Rechner laufen lasst, ist das der richtige Weg. Der doppelte Bindestrich trennt dabei Claudes eigene Optionen von dem Kommando, das den Server startet: Alles nach -- wird unverändert weitergereicht.

claude mcp add [options] <name> -- <command> [args...]

# Beispiel mit Umgebungsvariable für den Server
claude mcp add --env AIRTABLE_API_KEY=YOUR_KEY --transport stdio airtable \
  -- npx -y airtable-mcp-server

Remote über HTTP

Gehostete Server bindet ihr über HTTP ein. Das ist der Weg mit der besten Ausstattung, denn nur er unterstützt OAuth als Anmeldeverfahren. Wenn ihr eine fertige Konfiguration aus der Dokumentation eines Anbieters kopiert und dort streamable-http steht: Das ist derselbe Transport, der Name kommt aus der MCP-Spezifikation und wird als Alias akzeptiert.

claude mcp add --transport http notion https://mcp.notion.com/mcp

# mit eigenem Header statt OAuth
claude mcp add --transport http secure-api https://api.example.com/mcp \
  --header "Authorization: Bearer YOUR_TOKEN"

SSE und WebSocket

SSE ist der ältere Remote-Transport und läuft weiterhin, ihr bindet ihn mit --transport sse ein. Für neue Setups gibt es keinen Grund mehr dazu, wenn der Anbieter HTTP anbietet. WebSocket ist der Sonderfall für Server, die von sich aus Ereignisse schicken wollen; er lässt sich nicht über --transport setzen, sondern nur über claude mcp add-json oder direkt in der Konfigurationsdatei, und kennt nur Header-Authentifizierung.

Ein Unterschied, der später im Betrieb wichtig wird: Bricht die Verbindung zu einem HTTP- oder SSE-Server während einer Sitzung ab, verbindet Claude Code sich automatisch neu, bis zu fünf Versuche mit wachsendem Abstand ab einer Sekunde. Erst danach gilt der Server als ausgefallen. Lokale stdio-Server sind einfach Prozesse und werden nicht automatisch neu gestartet.

Die wichtigste Entscheidung: für wen soll der Server gelten?

Jeder Server wird in einem von drei Geltungsbereichen abgelegt. Diese Entscheidung trefft ihr beim Hinzufügen mit --scope oder kurz -s, und sie ist der Punkt, an dem später am meisten Verwirrung entsteht, weil sich Kollegen wundern, warum bei ihnen ein Server fehlt oder plötzlich einer auftaucht.

# nur für mich, nur hier (Standard, --scope kann entfallen)
claude mcp add --transport http stripe --scope local https://mcp.stripe.com

# für das ganze Team, landet in der .mcp.json
claude mcp add --transport http paypal --scope project https://mcp.paypal.com/mcp

# für mich, aber in jedem Projekt
claude mcp add --transport http hubspot --scope user https://mcp.hubspot.com/anthropic

Die brauchbare Heuristik dahinter: Alles, was zum Projekt gehört und für jeden im Team gleich aussieht, gehört nach project. Alles, was an eurer Person hängt, etwa ein persönlicher Notiz- oder Kalenderzugang, gehört nach user. Und local ist der richtige Ort zum Ausprobieren, solange ihr noch nicht wisst, ob ein Server bleibt.

Der Teil, den kaum jemand erklärt: Rollout im Team

Eine .mcp.json ins Repository zu legen, ist der offensichtliche Weg, allen dieselben Werkzeuge zu geben. Nur startet der Server bei den Kollegen erst einmal nicht, und das ist kein Fehler, sondern Absicht. Claude Code fragt aus Sicherheitsgründen nach einer Genehmigung, bevor es einen projektweiten Server benutzt. Sonst wäre eine eingecheckte Datei ein bequemer Weg, fremden Code auf fremden Rechnern zu starten.

Sichtbar wird das an den Statusanzeigen: In claude mcp list und claude mcp get erscheinen wartende Server als „Genehmigung ausstehend", abgelehnte als „Abgelehnt". Wer sich vertan hat, setzt seine Entscheidungen für das Projekt zurück.

claude mcp list          # was ist konfiguriert, was wartet auf Freigabe
claude mcp get github    # Details zu einem Server, inklusive OAuth-Status
claude mcp remove github # wieder entfernen

claude mcp reset-project-choices   # Genehmigungen für dieses Projekt zurücksetzen

Dahinter liegt eine Mechanik, die im Alltag für Ratlosigkeit sorgt. Seit Version 2.1.196 liest Claude Code Genehmigungen nur noch aus Einstellungsdateien, die nicht im Repository liegen, solange ihr dem Arbeitsbereich nicht ausdrücklich vertraut habt. Das Vertrauen erteilt ihr, indem ihr claude in dem Ordner interaktiv startet und den Dialog bestätigt.

Die praktische Folge klingt paradox, ist aber genau der Sinn der Sache: Ein frisch geklontes Repository kann seine eigenen Server nicht selbst genehmigen. Einstellungen wie enableAllProjectMcpServers oder enabledMcpjsonServers, die ihr in die eingecheckte .claude/settings.json schreibt, werden in einem noch nicht vertrauenswürdigen Ordner ignoriert. Der Server bleibt dann hartnäckig auf „Genehmigung ausstehend" stehen, und man sucht den Fehler an der falschen Stelle.

Für ein Onboarding heißt das schlicht: Nach dem Klonen einmal claude im Projektordner starten, den Vertrauensdialog bestätigen, die Server freigeben. Wer diesen Schritt in die README schreibt, spart sich die immer gleiche Rückfrage.

Zwei Kleinigkeiten, die beim Teilen ebenfalls auffallen: Einige Servernamen sind für Claude Codes eingebaute Server reserviert, darunter workspace und computer-use. Und wenn ein Server aus einem Plugin stammt, trägt sein Werkzeug den vollen Namen mcp__plugin_<plugin>_<server>__<tool>. Wer eine Berechtigungsregel oder einen Hook nur gegen den bloßen Server-Schlüssel schreibt, wundert sich sonst, warum sie nie greift.

Die Grenzen, an denen MCP-Setups tatsächlich scheitern

Bis hierher ist alles Konfiguration. Die Probleme, die im Betrieb wirklich weh tun, stehen dagegen selten in Tutorials, weil sie erst auftreten, wenn ein Setup ein paar Wochen läuft.

Antworten sind größer, als man denkt

Ein MCP-Werkzeug, das eine Datenbank abfragt oder ein Monitoring-Dashboard ausliest, liefert schnell sehr viel Text zurück, und dieser Text landet vollständig im Kontext. Claude Code warnt deshalb, sobald die Ausgabe eines Werkzeugs 10.000 Token überschreitet, und kappt sie standardmäßig bei 25.000 Token. Die Warnschwelle ist fest verdrahtet, die Kappungsgrenze lässt sich über die Umgebungsvariable MAX_MCP_OUTPUT_TOKENS anheben.

Das Limit anzuheben, ist allerdings selten die richtige Antwort. Wer regelmäßig gegen die Grenze läuft, hat meist ein Werkzeug, das zu breit abfragt. Ein Filter auf der Serverseite ist billiger als ein größeres Kontextfenster, in jeder Hinsicht.

Timeouts sind zwei, nicht einer

Für langsame Werkzeuge könnt ihr je Server ein timeout in Millisekunden setzen, das die Umgebungsvariable MCP_TOOL_TIMEOUT für genau diesen Server überschreibt. Das ist eine harte Grenze pro Werkzeugaufruf, Fortschrittsmeldungen des Servers verlängern sie nicht. Werte unter 1000 werden ignoriert.

Der zweite Timer ist der, den man übersieht. Bei HTTP- und SSE-Servern läuft zusätzlich eine Uhr pro Anfrage, die nur das erste Antwortbyte abwartet, und die steht auf 60 Sekunden, solange ihr nichts anderes setzt. Ein Server, der eine Minute nachdenkt, bevor er überhaupt anfängt zu antworten, fällt also raus, obwohl das großzügige Werkzeug-Timeout noch lange nicht erreicht ist. Ihr hebt ihn an, indem ihr timeout oder MCP_TOOL_TIMEOUT auf einen Wert von 60 Sekunden oder mehr setzt. Lokale stdio-Server haben diesen zweiten Timer nicht.

Vertrauen ist keine Formalie

Anthropic selbst formuliert es deutlich: Prüft, ob ihr einem Server vertraut, bevor ihr ihn verbindet. Server, die externe Inhalte holen, können euch dem Risiko von Prompt-Injection aussetzen, weil der geholte Inhalt im selben Kontext landet wie eure Anweisungen. Ein Ticket-Kommentar von außen ist damit potenziell eine Anweisung an das Modell.

Für ein mittelständisches Team heißt das nicht „Finger weg", aber es heißt: nur Server aus Quellen, die ihr benennen könnt, möglichst aus dem geprüften Verzeichnis von Anthropic, und für jeden Server die Frage beantworten, welche Daten er sehen kann. Wie wir diese Abwägung generell führen, steht in unserem Beitrag zu KI und Datenschutz.

Ein pragmatischer Einstieg

Wenn ihr heute anfangt, ist die kürzeste sinnvolle Route diese: Nehmt genau ein System, aus dem ihr regelmäßig kopiert. Bindet es mit local ein, arbeitet eine Woche damit und schaut, ob ihr es wirklich benutzt. Erst wenn die Antwort ja lautet, schiebt ihr es mit --scope project ins Repository und schreibt den Vertrauensdialog ins Onboarding.

Umgekehrt lohnt es sich, einmal im Quartal /mcp zu öffnen und zu schauen, welche Server eigentlich noch benutzt werden. Jeder verbundene Server bringt Werkzeugbeschreibungen mit, und ein Setup, das aus zwanzig Servern besteht, macht die Arbeit nicht schneller, sondern unübersichtlicher. Aufräumen ist hier eine echte Optimierung.

Falls ihr noch gar nicht so weit seid: Die Installation und den ersten Login beschreibt Claude Code installieren. Und wer die Anbindung eigener Systeme nicht als Entwicklerthema, sondern als Prozessfrage betrachtet, findet den größeren Rahmen im Leitfaden zur Prozessautomatisierung.

Fazit

MCP in Claude Code einzurichten ist eine Sache von Minuten, und genau deshalb wird der schwierigere Teil oft übersprungen. Der Befehl claude mcp add ist schnell getippt; die Entscheidung, ob ein Server nur euch, dem Projekt oder allen euren Projekten gehört, trägt dagegen über Monate. Wer sie bewusst trifft, die Genehmigungsmechanik im Team einmal erklärt und die Grenzen bei Ausgabegröße und Timeouts kennt, hat ein Setup, das auch nach einem halben Jahr noch verständlich ist.

Und wenn ihr überlegt, ob und wie sich eure eigenen Systeme sinnvoll anbinden lassen, sprecht uns gern an. Wir schauen uns an, wo bei euch tatsächlich kopiert wird, und das ist meist die ehrlichste Anforderungsliste.