Claude · 9 Min.
Claude Code MCP für Teams: Tools sicher über Projekt-Scopes teilen
Claude Code wird deutlich stärker, wenn Teams MCP-Server sauber teilen. Aber Projekt-Scopes, OAuth, Tool Search und Managed MCP brauchen klare Regeln.
SYSTEMS Grafik zu Claude Code MCP Teams: Explore -> Plan -> Verify. Fokus: Wie Entwicklerteams Claude Code mit MCP produktiv nutzen, ohne Tool-Zugriff und Projekt-Scopes unkontrolliert wachsen zu lassen.
Kurzfassung
Claude Code kann über MCP auf Tools, Datenbanken, APIs, Monitoring und Issue Tracker zugreifen. Für Teams ist das ein Produktivitätshebel, aber auch ein Governance-Thema. Projekt-Scopes und `.mcp.json` machen gemeinsame MCP-Konfiguration möglich, brauchen aber klare Regeln für Trust, Secrets, Auth und Review. Managed MCP, Tool Search, OAuth-Scopes und erlaubte Server sind die Hebel, um Claude-Code-Workflows teamfähig zu machen.
Strategischer Lesepfad
Baue das Thema im passenden Cluster weiter aus und verknüpfe es mit den nächsten Architekturentscheidungen.
Warum MCP Claude Code im Team verändert Claude Code ist nicht nur ein Chat im Terminal. Mit MCP kann Claude Code externe Systeme lesen und teilweise Aktionen vorbereiten oder ausführen. Das verändert den Arbeitsmodus.
Statt Jira-Tickets, Sentry-Fehler, Datenbankauszuege oder GitHub-Kontext manuell in den Chat zu kopieren, kann Claude Code direkt mit verbundenen Tools arbeiten. Für einzelne Entwickler ist das praktisch. Für Teams ist es strategisch: Agentic Coding wird anschlussfähig an die echte Arbeitsumgebung.
Aber sobald Tools geteilt werden, entstehen Fragen:
MCP macht Claude Code stärker. Ohne Team-Governance macht es den Workflow aber auch riskanter.
Welche MCP-Server dürfen im Projekt genutzt werden? Welche davon sind lokal, welche remote? Welche Credentials sind erlaubt? Welche Tools dürfen schreiben? Wer reviewed `.mcp.json`-Änderungen? Was passiert bei Prompt Injection aus externen Datenquellen? Lokaler, Projekt- und User-Scope richtig verstehen Claude Code unterscheidet MCP-Scopes. Das ist für Teams entscheidend.
Ein lokaler Scope ist nur für die eigene Maschine oder Session relevant. Ein User-Scope kann über Projekte hinweg gelten. Ein Project-Scope kann über `.mcp.json` mit dem Team geteilt werden.
Für Unternehmen ist Project-Scope besonders wichtig, weil er reproduzierbare Team-Setups erlaubt. Neue Entwickler können dasselbe Projekt öffnen und dieselben vorgesehenen MCP-Server sehen.
Der Nachteil: Eine geteilte Konfiguration ist auch eine geteilte Angriffs- und Fehlerfläche. Deshalb sollte `.mcp.json` wie Code behandelt werden: reviewed, versioniert, dokumentiert und begrenzt.
HTTP, SSE und stdio nicht wahllos mischen Claude Code unterstützt Remote-HTTP-Server, Remote-SSE-Server und lokale stdio-Server. Die Doku weist darauf hin, dass HTTP für cloudbasierte Remote-MCP-Server empfohlen ist, während SSE als deprecated gilt. Lokale stdio-Server sind sinnvoll für direkte System- oder Projektzugriffe.
Eine einfache Team-Regel:
Das klingt klein, verhindert aber später viel Chaos.
Remote HTTP für zentrale, cloudfähige Tools stdio für lokale Projektwerkzeuge SSE nur bewusst für Legacy-Fälle keine zufälligen externen Server ohne Review Tool Search und dynamische Tools Claude Code kann mit Tool Search arbeiten, damit nicht alle Tools dauerhaft in den Kontext geladen werden müssen. Das ist bei vielen MCP-Servern wichtig, weil Teams sonst schnell zu viele Tools in einer Session haben.
Stand Mai 2026 ist Tool Search kein Detail mehr, sondern eine Team-Skalierungsfunktion. Claude Code lädt Tool-Definitionen nicht mehr pauschal upfront, sondern entdeckt relevante Tools bei Bedarf. Für grosse MCP-Landschaften ist das wichtig, weil Kontextfenster nicht mit 200 Tool-Schemas geflutet werden sollten.
Gleichzeitig unterstützen MCP-Server dynamische Updates ihrer Tools, Prompts und Ressourcen. Das ist nützlich, aber im Team-Kontext muss klar sein, ob solche Änderungen erwartet sind.
Gute Regeln:
Ein Agent soll Tools finden können. Er soll aber nicht in einem undurchsichtigen Werkzeugkasten verschwinden.
grosse Tool-Kataloge nur mit Tool Search nutzen Servernamen stabil halten Tool-Beschreibungen konkret und risikobewusst schreiben Schreibtools getrennt von Lesetools anbieten dynamische Tool-Änderungen in Logs sichtbar machen `.mcp.json` ist Infrastruktur-Code Eine project-scoped `.mcp.json` gehört in denselben Review-Prozess wie CI, Deployment-Konfiguration oder Datenbank-Migrationen. Der Grund ist einfach: Sie definiert, welche Werkzeuge ein Agent im Projekt sehen kann.
Ein Team sollte für jede Änderung prüfen:
So wird MCP nicht zu einer Schattenintegration, sondern zu kontrollierter Engineering-Infrastruktur.
Kommt der Server aus einer vertrauenswürdigen Quelle? Ist der Transport bewusst gewählt? Werden Secrets nur über sichere Umgebungsvariablen oder Auth-Flows genutzt? Sind Read- und Write-Tools getrennt? Gibt es einen Owner für den Server? Sind Servername und Tool-Beschreibungen stabil genug für Tool Search? Ist klar, welche Datenquellen untrusted Content liefern? OAuth und Scopes: Nicht jedes Tool braucht Vollzugriff Remote MCP -Server können Authentifizierung und OAuth nutzen. Für Teams ist das besser als geteilte pauschale Tokens, aber nur wenn Scopes eng bleiben.
Ein guter MCP-Zugriff fragt:
Der schlechteste Zustand ist ein "funktioniert bei allen"-Token mit zu breiten Rechten. Der beste Zustand ist per-user Auth mit klaren Scopes und nachvollziehbaren Aktionen.
Braucht Claude Code Lesen oder Schreiben? Gilt der Zugriff pro Nutzer oder pro Service? Wie werden Tokens rotiert? Welche OAuth-Scopes sind minimal nötig? Können sensible Aktionen zusätzlich bestätigt werden? Sind Logs frei von Credentials und geheimen Parametern? Managed MCP für Enterprise-Governance Claude Code dokumentiert Managed-MCP-Konfigurationen und policy-basierte Kontrolle mit Allow- und Denylisten. Das ist genau die Ebene, die größere Teams brauchen.
Managed MCP kann helfen, wenn:
Für kleine Teams kann das anfangs zu viel sein. Für Unternehmen ist es der Weg, aus "jeder verbindet irgendwas" einen kontrollierten Entwicklerarbeitsplatz zu machen.
Managed Settings gehen dabei weiter als eine zentrale `.mcp.json`. Teams können erlaubte Server, Permission-Regeln, Hook-Policies und einzelne `.mcp.json`-Server zentral steuern. Wichtig ist auch der Subagent-Fall: Wenn Subagents standardmäßig Tools aus dem Hauptkontext erben, muss ein Team bewusst beschraenken, welche MCP-Tools in welchem Spezialagenten erlaubt sind.
Das ist der Unterschied zwischen "Claude Code hat Tools" und "Claude Code ist ein kontrollierter Team-Arbeitsplatz".
nur bestimmte Server erlaubt sein sollen Projektteams nicht beliebige Remote-URLs eintragen dürfen gefährliche Commands oder URLs blockiert werden müssen Security zentrale Kontrolle über MCP-Konfiguration braucht Audits zeigen sollen, welche Server genutzt werden dürfen Prompt Injection bleibt ein reales Risiko Claude Code weist selbst darauf hin, dass Server, die externen Content holen, Prompt-Injection-Risiken einbringen können. Das ist bei Entwickler-Tools besonders relevant.
Ein Issue, eine Website, ein Log-Eintrag oder eine Datenbankzeile kann Text enthalten, der den Agenten manipulieren soll. Wenn Claude Code diesen Inhalt liest und gleichzeitig Tools nutzen darf, wird aus Text ein potenzieller Angriff auf den Workflow.
Deshalb brauchen Teams:
Technisch können Pre-Tool-Use-Hooks zusätzliche Prüfungen erzwingen: etwa riskante Tool Calls blockieren, Ticket-Inhalte klassifizieren oder Write-Aktionen nur mit expliziter Freigabe zulassen. Solche Hooks ersetzen keine Architektur, aber sie sind ein starkes Betriebsmittel, wenn viele Entwickler und Subagents dieselben MCP-Werkzeuge nutzen.
MCP ist kein Prompt-Injection-Schutz. Es ist die Stelle, an der man Schutz einbauen muss.
klare Trennung zwischen untrusted Content und Anweisungen Review für externe Datenquellen begrenzte Schreibtools keine geheimen Werte in Tool-Ausgaben menschliche Freigabe für riskante Aktionen Tests mit Prompt-Injection-Beispielen Der SYSTEMS-Blick auf Claude Code MCP Claude Code MCP für Teams ist einer der praktischsten Wege, agentisches Arbeiten in Entwicklerorganisationen einzuführen. Der Mehrwert entsteht aber nicht durch möglichst viele Server. Er entsteht durch wenige, gut geschnittene Tools, klare Scopes, kontrollierte Auth und sichtbare Ergebnisse.
SYSTEMS baut solche Setups wie Infrastruktur: Project-Scopes, Tool-Grenzen, Managed-MCP-Regeln, Review-Flows, Eval-Fälle und produktionsnahe Arbeitsweisen.
Wenn Claude Code nicht nur lokal stark sein soll, sondern ein Team wirklich schneller und sauberer machen soll, muss MCP als Governance-Schicht behandelt werden. Dann wird aus einem Coding-Agenten ein kontrollierter Engineering-Co-Pilot.
