Claude · 9 Min.
Claude Code MCP fuer Teams: Tools sicher ueber Projekt-Scopes teilen
Claude Code wird deutlich staerker, 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 ueber MCP auf Tools, Datenbanken, APIs, Monitoring und Issue Tracker zugreifen. Fuer Teams ist das ein Produktivitaetshebel, aber auch ein Governance-Thema. Projekt-Scopes und `.mcp.json` machen gemeinsame MCP-Konfiguration moeglich, brauchen aber klare Regeln fuer Trust, Secrets, Auth und Review. Managed MCP, Tool Search, OAuth-Scopes und erlaubte Server sind die Hebel, um Claude-Code-Workflows teamfaehig 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 veraendert Claude Code ist nicht nur ein Chat im Terminal. Mit MCP kann Claude Code externe Systeme lesen und teilweise Aktionen vorbereiten oder ausfuehren. Das veraendert 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. Fuer einzelne Entwickler ist das praktisch. Fuer Teams ist es strategisch: Agentic Coding wird anschlussfaehig an die echte Arbeitsumgebung.
Aber sobald Tools geteilt werden, entstehen Fragen:
MCP macht Claude Code staerker. Ohne Team-Governance macht es den Workflow aber auch riskanter.
Welche MCP-Server duerfen im Projekt genutzt werden? Welche davon sind lokal, welche remote? Welche Credentials sind erlaubt? Welche Tools duerfen schreiben? Wer reviewed `.mcp.json`-Aenderungen? Was passiert bei Prompt Injection aus externen Datenquellen? Lokaler, Projekt- und User-Scope richtig verstehen Claude Code unterscheidet MCP-Scopes. Das ist fuer Teams entscheidend.
Ein lokaler Scope ist nur fuer die eigene Maschine oder Session relevant. Ein User-Scope kann ueber Projekte hinweg gelten. Ein Project-Scope kann ueber `.mcp.json` mit dem Team geteilt werden.
Fuer Unternehmen ist Project-Scope besonders wichtig, weil er reproduzierbare Team-Setups erlaubt. Neue Entwickler koennen dasselbe Projekt oeffnen und dieselben vorgesehenen MCP-Server sehen.
Der Nachteil: Eine geteilte Konfiguration ist auch eine geteilte Angriffs- und Fehlerflaeche. Deshalb sollte `.mcp.json` wie Code behandelt werden: reviewed, versioniert, dokumentiert und begrenzt.
HTTP, SSE und stdio nicht wahllos mischen Claude Code unterstuetzt Remote-HTTP-Server, Remote-SSE-Server und lokale stdio-Server. Die Doku weist darauf hin, dass HTTP fuer cloudbasierte Remote-MCP-Server empfohlen ist, waehrend SSE als deprecated gilt. Lokale stdio-Server sind sinnvoll fuer direkte System- oder Projektzugriffe.
Eine einfache Team-Regel:
Das klingt klein, verhindert aber spaeter viel Chaos.
Remote HTTP fuer zentrale, cloudfaehige Tools stdio fuer lokale Projektwerkzeuge SSE nur bewusst fuer Legacy-Faelle keine zufaelligen 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 muessen. 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 laedt Tool-Definitionen nicht mehr pauschal upfront, sondern entdeckt relevante Tools bei Bedarf. Fuer grosse MCP-Landschaften ist das wichtig, weil Kontextfenster nicht mit 200 Tool-Schemas geflutet werden sollten.
Gleichzeitig unterstuetzen MCP-Server dynamische Updates ihrer Tools, Prompts und Ressourcen. Das ist nuetzlich, aber im Team-Kontext muss klar sein, ob solche Aenderungen erwartet sind.
Gute Regeln:
Ein Agent soll Tools finden koennen. 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-Aenderungen in Logs sichtbar machen `.mcp.json` ist Infrastruktur-Code Eine project-scoped `.mcp.json` gehoert 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 fuer jede Aenderung pruefen:
So wird MCP nicht zu einer Schattenintegration, sondern zu kontrollierter Engineering-Infrastruktur.
Kommt der Server aus einer vertrauenswuerdigen Quelle? Ist der Transport bewusst gewaehlt? Werden Secrets nur ueber sichere Umgebungsvariablen oder Auth-Flows genutzt? Sind Read- und Write-Tools getrennt? Gibt es einen Owner fuer den Server? Sind Servername und Tool-Beschreibungen stabil genug fuer Tool Search? Ist klar, welche Datenquellen untrusted Content liefern? OAuth und Scopes: Nicht jedes Tool braucht Vollzugriff Remote MCP -Server koennen Authentifizierung und OAuth nutzen. Fuer 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 noetig? Koennen sensible Aktionen zusaetzlich bestaetigt werden? Sind Logs frei von Credentials und geheimen Parametern? Managed MCP fuer Enterprise-Governance Claude Code dokumentiert Managed-MCP-Konfigurationen und policy-basierte Kontrolle mit Allow- und Denylisten. Das ist genau die Ebene, die groessere Teams brauchen.
Managed MCP kann helfen, wenn:
Fuer kleine Teams kann das anfangs zu viel sein. Fuer 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 koennen erlaubte Server, Permission-Regeln, Hook-Policies und einzelne `.mcp.json`-Server zentral steuern. Wichtig ist auch der Subagent-Fall: Wenn Subagents standardmaessig 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 duerfen gefaehrliche Commands oder URLs blockiert werden muessen Security zentrale Kontrolle ueber MCP-Konfiguration braucht Audits zeigen sollen, welche Server genutzt werden duerfen Prompt Injection bleibt ein reales Risiko Claude Code weist selbst darauf hin, dass Server, die externen Content holen, Prompt-Injection-Risiken einbringen koennen. 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 koennen Pre-Tool-Use-Hooks zusaetzliche Pruefungen 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 fuer externe Datenquellen begrenzte Schreibtools keine geheimen Werte in Tool-Ausgaben menschliche Freigabe fuer riskante Aktionen Tests mit Prompt-Injection-Beispielen Der SYSTEMS-Blick auf Claude Code MCP Claude Code MCP fuer Teams ist einer der praktischsten Wege, agentisches Arbeiten in Entwicklerorganisationen einzufuehren. Der Mehrwert entsteht aber nicht durch moeglichst 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-Faelle 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.
