In einem von The New Stack beschriebenen Bit-Cloud-Test rief eine frische Claude-Code-Sitzung per Model Context Protocol (MCP) die Beziehungen zwischen mehreren Komponenten ab – darunter eine gemeinsame Ticket-Komponente für App und Service. Der Bericht zeigt einen praktischen Nutzen von MCP: Eine Sitzung kann externe Projektinformationen abrufen, die lokal nicht vorliegen. Für die Änderung und Prüfung des Codes waren anschließend Quellcodeanalyse und Tests nötig. The New Stack
MCP verbindet Claude Code mit externen Diensten und Werkzeugen. Anthropic unterscheidet diese Verbindungen von Skills, die wiederverwendbares Wissen oder Arbeitsabläufe bereitstellen. Anthropic erklärt die Erweiterungsmöglichkeiten von Claude Code.
Was die frische Sitzung über das Projekt herausfand
Der Test begann mit einem leeren Arbeitsbereich ohne lokalen Code und ohne vorherigen Gesprächsverlauf. Der Autor, ein Bit-Cloud-Ingenieur, berichtete, dass zwei MCP-Aufrufe – read_scope und read_components – vier Komponenten und ihre Abhängigkeiten sichtbar machten. Dazu gehörten eine React-App, ein Express-Service mit MongoDB, eine gemeinsame Ticket-Komponente und ein Gateway. App und Service verwendeten dieselbe Version der Ticket-Komponente. The New Stack schildert den Testablauf.
Die Komponenten hingen laut Bericht von 16 bereits bestehenden Komponenten ab; zehn davon stammten aus Bit Design Sparks. In diesem Bit-Cloud-Setup waren die Abhängigkeitsangaben mit den jeweiligen Komponenten-Versionen verknüpft. So konnte die Sitzung den gemeinsamen Baustein und seine Beziehungen finden, obwohl Code und Konversationsverlauf fehlten.
Was danach noch geprüft werden musste
Claude importierte die vier Komponenten, untersuchte den Quellcode und ergänzte in der App Filter für Ticketstatus und zuständige Person. Die Änderung blieb auf die App beschränkt; Ticket-Komponente und Service wurden nicht geändert. Der Autor berichtete von 41 bestandenen Tests, darunter neun neue Tests für die Filterung. MongoDB-Integrationstests konnten jedoch übersprungen werden, falls der Testlauf keine temporäre Datenbank starten konnte. Der Bericht beschreibt Ergebnis und Einschränkung.
Die API-Referenz der App führte vier Routen für einen Test-Service auf. Der Autor prüfte nicht, ob diese Routen zum echten Service passten. Die gefundenen Abhängigkeitsdaten halfen also dabei, den passenden gemeinsamen Baustein zu lokalisieren; sie ersetzten weder die Prüfung des Quellcodes noch Tests gegen das tatsächliche Laufzeitverhalten.
MCP in Claude Code einrichten: lokal, im Projekt oder für den eigenen Nutzer
Anthropic unterscheidet drei Konfigurationsbereiche. local gilt für das aktuelle Projekt auf dem eigenen Rechner und ist laut Schnellstart die Standardeinstellung. project teilt die Konfiguration über eine .mcp.json im Projektverzeichnis mit dem Team. user gilt für die Projekte des jeweiligen Entwicklers. Anthropics Schnellstart erläutert die Konfigurationsbereiche.
| Bereich | Geltungsbereich | Zweck |
local | Aktuelles Projekt auf dem eigenen Rechner | MCP für ein einzelnes Projekt einrichten |
project | Projektverzeichnis mit .mcp.json | Konfiguration im Team teilen |
user | Projekte des jeweiligen Entwicklers | Eigene MCP-Konfiguration projektübergreifend nutzen |
Anthropics Schnellstart verwendet claude mcp add ..., um einen Server hinzuzufügen. Für eine persönliche Einrichtung kommen local oder user infrage; soll das Team dieselbe Konfiguration verwenden, ist project der dafür vorgesehene Bereich.
Was MCP in den Kontext lädt
Anthropic zufolge lädt Claude Code die Namen der MCP-Werkzeuge zu Beginn einer Sitzung; die vollständigen Werkzeugschemas werden erst bei Bedarf geladen. Anthropic beschreibt inaktive MCP-Werkzeuge als mit geringem Kontextaufwand verbunden. Das bedeutet nicht, dass die Nutzung eines Werkzeugs oder die Verarbeitung seiner Ergebnisse keinen Kontext beansprucht. Anthropics Übersicht zu Claude-Code-Erweiterungen beschreibt das Ladeverhalten.
