Claude Code MCP Integrations: Wie Tools eine Verbindung zu KI-Codierungsagenten herstellen

1. Einführung

Ein Codierungsagent ohne Zugriff auf externe Tools kann nur eine begrenzte Menge tun. Er könnte Code erklären, Änderungen vorschlagen oder einen Patch schreiben. Aber wenn du willst, dass es ein Repository überprüft, eine API aufruft oder eine Logdatei liest, muss es über das Kontextfenster hinausgehen. An dieser Stelle beginnen die meisten Setups zu scheitern.

Ich habe Teams dabei zugesehen, wie sie diese Verbindungen von Grund auf neu hergestellt haben. Möglicherweise befindet sich an einer Stelle ein Python-Skript, an einer anderen ein benutzerdefinierter Wrapper. Eine Integration verwendet JSON über HTTP, eine andere führt Befehle über eine CLI aus und eine andere hängt von einem alten Adapter aus einem Hackathon ab. Dieses Setup funktioniert mit ein paar Tools, aber wenn Sie mehr hinzufügen, wird es chaotisch. Die Berechtigungen werden inkonsistent und das Debuggen wird schwieriger.

Claude Code entwickelt sich von einem bloßen Assistenten zu einem vernetzten Agenten. Es wird viel hilfreicher, wenn es auf Dateien, Entwicklungstools und externe Systeme zugreifen kann. Wenn es jedoch keine Standardmethode gibt, um alles zu verbinden, sind Integrationen am Ende fragil, die unerwartet kaputt gehen können.

Das ist es, was MCP adressiert.

Das Model Context Protocol bietet eine Standardmethode, um Modellen Tools zur Verfügung zu stellen. Anstatt jedes Tool mit jedem Agenten zu verbinden, verwenden Sie ein gemeinsames Discovery-Protokoll. Dies löst nicht jedes Problem, aber es verschiebt die Frage von „Wie verbinde ich das?“ auf „Wie verwalte ich, was verbunden ist“.

2. Was sind MCP-Integrationen in Claude Code?

MCP ist ein Protokoll, kein Produkt. Das ist wichtig, weil es bestimmt, wie Claude Code hinter den Kulissen arbeitet.

Das Model Context Protocol legt fest, wie sich Werkzeuge für ein Modell beschreiben und wie das Modell sie aufruft. Es standardisiert den Austausch: Erkennung, Schema, Anfrage und Antwort. Das Tool selbst wird nicht implementiert. Es kümmert sich nicht um die Zugriffskontrolle. Es enthält nur den Vertrag.

Wenn wir MCP-Integrationen in Claude Code erwähnen, beziehen wir uns auf Tools, die Claude über das Protokoll entdecken und verwenden kann. Das Modell ist nicht an jeden Endpunkt gebunden. Stattdessen sieht es eine strukturierte Oberfläche, versteht die Parameter und verwendet das Tool als Teil seines Workflows.

Angenommen, Sie möchten, dass Claude ein GitHub-Problem erstellt, wenn es während der Codeüberprüfung einen Bug findet. Ohne MCP müsstest du benutzerdefinierten Code schreiben, um Claudes Ausgabe zu verarbeiten, dich bei GitHub anmelden und den API-Aufruf tätigen. Bei MCP registrierst du einfach eine GitHub-Integration, die dem Tool create_issue Parameter wie Repository, Titel, Text und Labels zur Verfügung stellt. Claude kann dieses Tool dann direkt finden und verwenden.

MCP-Integrationen verbinden Claude nicht nur mit Tools, sie definieren, wie Claude diese Tools von Anfang an erkennt und mit ihnen interagiert.

3. Wie funktioniert MCP in Claude Code

Beim Laufen kennt Claude nur die Tools, die über MCP zur Verfügung gestellt werden. Die Art und Weise, wie es mit ihnen interagiert, folgt einer festgelegten Reihenfolge.

Dieser Schritt passiert, bevor Claude mit irgendetwas interagiert. Ein Tool ist bei einem MCP-Server registriert, einschließlich seines Namens, seiner Beschreibung und seines Eingabeschemas. Das Schema hilft dem Modell, das Tool zu verstehen. Wenn die Registrierung unklar ist, wählt Claude möglicherweise das falsche Tool aus.

Ein Dateireader könnte einen Pfadparameter verfügbar machen. Eine GitHub-Integration könnte Repository, Branch und issue_id verfügbar machen. Ein Logging-Tool könnte service_name, time_range und severity_filter verwenden.

Erkennung von Tools

Wenn Claude eine Verbindung herstellt, sendet es eine Tools/List-Anfrage:

{
  "method": "tools/list"
}

Der Server sendet die verfügbaren Tools und ihre Schemas zurück. Diese Liste wird zu Claudes Satz möglicher Aktionen. Claude rät nicht, er liest eine klar definierte Oberfläche.

Aufruf

Wenn Claude ein Tool benötigt, sendet es eine call_tool-Anfrage mit Argumenten. Nehmen wir an, Claude findet während der Überprüfung ein Sicherheitsproblem. Es könnte die GitHub-Integration wie folgt aufrufen:

{
  "method": "call_tool",
  "params": {
    "name": "github_create_issue",
    "arguments": {
      "repository": "acme/payment-service",
      "title": "SQL injection vulnerability in user input handler",
      "body": "Found unsanitized user input in src/handlers/payment.py line 142...",
      "labels": ["security", "high-priority"]
    }
  }
}

Wenn die Argumente falsch sind oder die Werkzeugdefinitionen nicht klar sind, kann es in dieser Phase zu Problemen kommen.

Umgang mit Antworten

Das Werkzeug wird unabhängig vom Modell ausgeführt und gibt ein Ergebnis zurück. Claude liest dieses Ergebnis und fährt fort. Manchmal ist das Ergebnis klar, aber manchmal ist es unübersichtlich oder unvollständig. In jedem Fall wirkt es sich darauf aus, was als Nächstes passiert.

Dieser Zyklus von Registrierung, Entdeckung, Aufruf und Reaktion ist die Art und Weise, wie MCP innerhalb von Claude Code funktioniert.

4. Arten von MCP-Integrationen

MCP-Integrationen verwenden alle dasselbe Protokoll, aber sie funktionieren nicht alle auf die gleiche Weise. Unterschiede zeigen sich darin, wie sie mit Zuständen umgehen, wie vorhersehbar ihre Antworten sind und wie viel Kontext Claude bewältigen muss.

Dateisystemintegrationen

Dies sind die einfachsten Typen. Claude liest und schreibt Dateien in schnellen Zyklen. Das ist schnell und normalerweise vorhersehbar, aber auch fragil. Wenn ein Dateipfad fehlt oder ein Schreibvorgang unvollständig ist, kann der Arbeitsablauf unterbrochen werden, ohne dass es zu eindeutigen Fehlern kommt. Ich habe gesehen, dass Agenten nicht weiterkamen, weil beim Lesen einer Datei ein leerer Wert statt eines Fehlers zurückgegeben wurde. Repository-Integrationen

Dazu gehören GitHub, GitLab und ähnliche Tools. Claude kann Pull-Requests lesen, Commits überprüfen, Issues erstellen und Änderungen pushen. Das ist mächtig, kann aber riskant sein. Wenn die Berechtigungen nicht richtig eingerichtet sind, führt ein Agent möglicherweise Code zusammen, den er nicht sollte. Du musst vorsichtig mit Berechtigungen umgehen. Das Lesen von Pull-Requests ist nicht dasselbe wie das Schreiben in Branches.

API-Integrationen

Dies sind externe Dienste, auf die über HTTP zugegriffen wird. Sie sind strukturierter, aber weniger nachsichtig. Sie müssen sich mit Netzwerkanrufen, Authentifizierung, Ratenbeschränkungen und Timeouts auseinandersetzen. Schemakonflikte können mitten in einem Lauf auftreten. Ich habe Fälle debuggt, in denen Claude immer wieder einen Jira-Aufruf wiederholt hat, der aufgrund eines Fehlers bei der Validierung versteckter Felder fehlgeschlagen ist.

Protokoll und Beobachtbarkeit

Claude kann Logs, Traces oder Metriken abfragen. Meist handelt es sich dabei um Lesevorgänge mit großen Datenmengen. Die größte Herausforderung besteht darin, die richtige Frage zu stellen. Ein Tool, das 10.000 Protokollzeilen zurückgibt, ist nicht hilfreich, aber eines, mit dem Sie nach Zeitraum, Schweregrad und Service filtern können, ist viel besser.

Datenbank-Integrationen

Diese sind staatlich und bergen ein höheres Risiko. Claude erstellt Abfragen auf der Grundlage von Schemata, die er möglicherweise nicht vollständig versteht. Hier ist Genauigkeit wichtiger als Geschwindigkeit. Die meisten Teams richten diese als schreibgeschützt ein.

Sie verwenden alle dasselbe Protokoll, aber ihr Verhalten in der Praxis kann sehr unterschiedlich sein.

5. MCP-Architektur in Claude Code

Das System funktioniert gut, weil jede Schicht getrennt bleibt. Wenn Sie sie kombinieren, wird es schnell schwieriger, sie zu verstehen und zu verwalten.

Die Agentenebene ist Claude selbst. Es findet heraus, was Sie wollen, entscheidet, welche Informationen es benötigt und ob ein Tool verwendet werden sollte. Claude leitet nichts direkt, er plant, wählt und delegiert Aufgaben.

Die MCP-Schicht dient als Protokollgrenze und standardisiert, wie Tools beschrieben und aufgerufen werden. Für Claude erscheint jedes Tool, ob ein Dateireader, eine Datenbank oder eine externe API, als strukturierte Schnittstelle, weil MCP sie alle gleich aussehen lässt.

In der Werkzeugebene passieren die Dinge tatsächlich. Befehle werden ausgeführt, Dateien werden geändert und API-Aufrufe werden getätigt. Hier finden echte Effekte statt.

Claude denkt, ohne direkt mit dem System zu interagieren. Tools übernehmen die Ausführung, ohne Entscheidungen zu treffen. MCP setzt Claudes Absicht in echte Handlungen um.

Dieses Setup erklärt einige Designoptionen. Warum ruft Claude die GitHub-API nicht direkt auf? Es sollte nicht wissen müssen, dass es GitHub ist. Stattdessen wird nur ein Tool namens create_issue mit einem Schema angezeigt. Authentifizierung, Ratenbegrenzungen und Fehlerbehandlung finden alle in der Tool-Ebene hinter dem Protokoll statt.

6. Einschränkungen der MCP-Integrationen von Claude Code

MCP macht Konnektivität sauberer. Es macht es nicht von alleine produktionsbereit.

Keine zentralisierte Verwaltung

MCP stellt Tools zur Verfügung, kontrolliert jedoch nicht, wer was in verschiedenen Teams oder Umgebungen sehen kann. Wenn Sie weitere Integrationen hinzufügen, wird dies zu einer Herausforderung. Ein Agent sieht möglicherweise zu viele Tools, während ein anderer zu wenige sieht. Es gibt keinen zentralen Ort, an dem die Konsistenz gewährleistet werden kann.

Wenn Sie beispielsweise drei Claude-Bereitstellungen haben, eine für die Codeüberprüfung, eine für die Reaktion auf Vorfälle und eine für die Dokumentation, benötigen Sie jeweils einen anderen Toolzugriff. Der Code-Review-Agent sollte keine Tools für die Produktionsdatenbank sehen, und die Reaktion auf Vorfälle sollte nicht in das Haupt-Repository schreiben. Mit nativem MCP müssen Sie jede Bereitstellung separat konfigurieren und hoffen, dass nichts aus dem Gleichgewicht gerät.

Sicherheitslücken

Der Toolzugriff basiert auf den verwendeten Anmeldeinformationen. Viele MCP-Setups verwenden zu weit gefasste Berechtigungen auf Serviceebene. Wenn Sie sie verschärfen, können Workflows kaputt gehen. Wenn Sie sie offen lassen, erhöhen Sie das Risiko. Das Protokoll löst dieses Problem nicht.

Keine Beobachtbarkeit

Claude ruft Werkzeuge und geht weiter, sodass alles, was dazwischen passiert ist, unsichtbar bleibt. Welches Tool ausgewählt wurde, warum, mit welchen Argumenten, und die Antwort sind unbekannt. Ohne Spuren wird das Debuggen zum Rätselraten. Ich habe Stunden damit verbracht, herauszufinden, warum ein Agent ein bestimmtes Tool ausgewählt hat, nur um festzustellen, dass die Entscheidung überhaupt nicht aufgezeichnet wurde.

Probleme bei der Skalierung

Eine kleine Anzahl von Integrationen ist überschaubar, aber Dutzende von Integrationen zu haben, wird kompliziert. Namen ändern sich, Schemata unterscheiden sich und Teams definieren Tools auf ihre eigene Art und Weise. Claude muss mit diesem inkonsistenten Setup arbeiten, was die Zuverlässigkeit beeinträchtigt. Wenn beispielsweise sowohl github_create_issue als auch gh_new_issue registriert sind, muss Claude raten, welches verwendet werden soll.

Fragmentierte Werkzeugabdeckung

Es gibt keine klare Grenze dafür, was ein Agent sehen sollte. Die Tool-Listen werden mit der Zeit länger. Einige Tools sind veraltet, während andere zu mächtig sind. Eine überfüllte Liste verschlechtert Leistung und Kontrolle.

7. Warum Teams über native MCP-Integrationen hinausgehen

MCP verwaltet Verbindungen, aber nicht die Steuerung.

Wenn Teams von wenigen Integrationen zur vollständigen Produktion übergehen, ändern sich ihre Anforderungen. Tools müssen verwaltet und nicht nur gefunden werden. Welcher Agent kann welches Tool verwenden? Unter welchen Bedingungen? Mit welchen Grenzen? Native MCP beantwortet diese Fragen nicht eindeutig.

Hier werden Gateways nützlich. Sie sind nicht nur zusätzlicher Aufwand, sie helfen auch, die wachsende Komplexität zu bewältigen.

Ein Gateway befindet sich zwischen den Claude- und den MCP-Servern. Es schränkt die Sichtbarkeit des Tools auf der Grundlage der Agentenidentität ein. Es erzwingt die Authentifizierung, bevor Anfragen die nachgelagerten Tools erreichen. Es wendet Ratenbegrenzungen an, protokolliert Aufrufe und lehnt Richtlinienverstöße ab.

Auditing funktioniert auf die gleiche Weise. Wenn Agenten mit Produktionssystemen interagieren, beispielsweise Probleme erstellen, Datenbanken abfragen oder Protokolle lesen, müssen die Teams wissen, was, von wem und warum getan wurde. Andernfalls sind Debugging und Compliance reaktiv, Sie erfahren von Problemen erst, wenn sie auftreten.

Aus einer einfachen Integration wird etwas mehr: eine Steuerungsebene zwischen Agenten und Tools, die bestimmt, wie der Zugriff in realen Situationen funktioniert.

8. Bewährte Methoden für MCP-Integrationen

MCP-Integrationen funktionieren am besten, wenn Sie sie als Schnittstellen und nicht als Abkürzungen behandeln.

Der Zugriff auf das Scope-Werkzeug ist eng begrenzt.

Der Zugriff sollte zur Aufgabe passen. Wenn eine Integration nur Repository-Metadaten lesen muss, sollte sie keine Anmeldeinformationen haben, mit denen Branches gelöscht werden können. Das klingt offensichtlich, wird aber oft ignoriert, da umfassendere Berechtigungen schneller eingerichtet werden können. Am Anfang ist es schneller, aber vielleicht verbringen Sie Wochen damit, Dinge zu reparieren, nachdem ein Agent etwas gelöscht hat, das er nicht löschen sollte.

Tool-Sichtbarkeit pro Agent einschränken

Das Modell sollte nur sehen, was es braucht. Wenn ein Agent nur Dateien liest und nach Problemen sucht, benötigt er keinen Zugriff auf die Bereitstellungssteuerung oder um in die Datenbank zu schreiben. Weniger Optionen bedeuten weniger Fehler.

Entwerfen Sie klare Werkzeugdefinitionen.

Explizite Namen. Enge Zuständigkeiten. Vorhersagbare Schemata. Wenn ein Tool fünf Dinge tut, leitet Claude zu viel ab. Gute Integrationen sind langweilig. Jedes Tool macht eine Sache sauber.

Anstatt beispielsweise ein GitHub-Betriebstool mit vielen Parametern zu haben, teilen Sie es in GitHub_Read_PR, GitHub_Create_Issue und GitHub_Add_Comment auf. Dadurch wird der Zweck der einzelnen Tools klar und begrenzt.

Zersiedelung verhindern

Zu viele ähnliche Tools machen es schwieriger, das richtige auszuwählen, und verlangsamt das Debuggen. Es ist besser, ein kleineres, gut organisiertes Toolset zu haben als ein großes, unübersichtliches. Überprüfe die Registrierungen der Tools regelmäßig, entferne ungenutzte Tools und kombiniere überlappende Tools.

9. MCP-Integrationen im Vergleich zu APIs im Vergleich zu SDKs

Diese lösen verwandte Probleme auf verschiedenen Ebenen.

APIs sind die grundlegende Schnittstelle in den meisten Systemen, und SDKs erleichtern die Verwendung dieser APIs. MCP setzt auf beiden Funktionen und macht den Zugriff auf Tools zu einem konsistenten Format, das Agenten verwenden können.

MCP ersetzt keine APIs oder SDKs. Deine GitHub-Integration verwendet weiterhin die GitHub-API. MCP standardisiert lediglich, wie Claude diese Integration findet und verwendet.

10. Fazit

MCP bringt Ordnung in einen früher chaotischen Prozess. Es standardisiert, wie Modelle Tools bereitstellen, entdecken und verwenden. Das macht es einfacher, verbundene Agenten zu erstellen.

Aber es ist immer noch nur ein Ausgangspunkt. Es beantwortet keine Fragen zu Kontrolle, Sichtbarkeit oder Richtlinien. Es entscheidet nicht, welcher Agent auf welches Tool zugreift oder wie Interaktionen geprüft werden. Hier muss sich die Architektur Ihres Systems weiterentwickeln. Sie gehen von einfachen Integrationen über und fügen ihnen eine verwaltete Ebene hinzu. MCP macht Verbindungen möglich, aber was Sie darauf aufbauen, entscheidet darüber, ob diese Verbindungen verwaltbar bleiben.

Häufig gestellte Fragen

Was passiert, wenn ein MCP-Toolaufruf fehlschlägt?

Claude erhält die Fehlerantwort und entscheidet, wie es weitergeht. Es versucht es möglicherweise erneut, versucht es mit einem anderen Tool oder deckt den Fehler auf. Das Problem ist, dass die Fehlerbehandlung je nach Integration unterschiedlich ist. Einige geben strukturierte Codes zurück. Andere geben vage Nachrichten zurück. Ohne konsistente Fehlerschemas wird die Wiederherstellung unvorhersehbar.

Kann ich einschränken, welche Tools ein Claude-Einsatz sieht?

Nicht durch MCP selbst. Das Protokoll verarbeitet die Erkennung und den Aufruf. Die Zugriffskontrolle erfolgt extern. Sie konfigurieren jeden MCP-Server separat oder fügen ein Gateway hinzu, das die Sichtbarkeit anhand der Agentenidentität filtert.

Wie gehen MCP-Integrationen mit der Authentifizierung um?

Auf der Werkzeugebene, nicht auf der Protokollebene. Jeder MCP-Server verwaltet die Anmeldeinformationen für die Dienste, die er umschließt. Claude sieht diese Anmeldeinformationen nicht. Es ruft nur Tools auf. Sie sichern jede Integration separat.

Wie hoch ist der Leistungsaufwand von MCP?

In den meisten Fällen minimal. MCP erhöht den Protokollaufwand für Erkennung und Aufruf, aber die eigentliche Ausführung erfolgt immer noch durch das, was das Tool verwendet — in der Regel direkte API-Aufrufe oder lokale Befehle. Der Aufwand liegt in der Standardisierung, nicht im Ausführungspfad.

Wie debugge ich eine schlechte Toolauswahl?

Schwer ohne Beobachtbarkeit. Protokollieren Sie jede Tool-/List-Antwort und jede call_tool-Anfrage und rekonstruieren Sie dann die Entscheidungen manuell. Eine Gateway-Ebene automatisiert diese Protokollierung und vereinfacht das Debuggen.

‍