Claude Code und MCP-Server: wie externe Tools integriert werden

Die eingebauten Tools von Claude Code (Bash, Read, Write, Edit, Grep etc.) decken das Wesentliche eines Coding-Workflows ab. Wirklich spannend wird es, sobald eigene Werkzeuge dazukommen: ein interner Issue-Tracker, eine produktive Datenbank, ein API für Kunden- oder Content-Daten. Genau dafür gibt es das Model Context Protocol — kurz MCP.

Dieser Artikel beschreibt, wie MCP-Server in Claude Code eingebunden werden, was sie liefern können und warum die Berechtigungs-Strategie an dieser Stelle wichtiger ist als beim normalen Tool-Use.

Was ist MCP — in zwei Sätzen

MCP ist ein offener Standard von Anthropic, der definiert, wie KI-Anwendungen und externe Tool-Provider miteinander reden. Statt für jedes Modell und jede Integration ein eigenes Protokoll zu erfinden, sprechen Claude Code (und perspektivisch viele weitere Hosts) mit allen MCP-Servern in derselben Sprache. Mehr Hintergrund im Glossar-Eintrag zu MCP.

Wie Claude Code MCP-Server einbindet

Die Einbindung läuft über eine .mcp.json-Konfiguration im Projekt (oder global im Benutzer-Profil). Dort wird pro Server festgelegt, wie er gestartet wird und welche Berechtigungen er bekommt. Es gibt zwei gängige Transport-Varianten:

• Lokale stdio-Server. Werden als Subprozess gestartet (z. B. node, python, npx) und kommunizieren über Standard-Input/Output. Vorteil: laufen vollständig auf dem eigenen Rechner, keine Netzwerk-Latenz, kein Auth-Aufwand.
• Remote HTTP-Server. Werden als HTTP-Endpunkt angesprochen, typischerweise mit Token-Auth. Praktisch für Team-weite oder gemanagte MCP-Integrationen.

Wer einen MCP-Server zum ersten Mal in einer Session sieht, kann sich via /mcp einen Überblick verschaffen: Welche Server sind verbunden, welche Tools, Resources und Prompts stellen sie zur Verfügung.

Was ein MCP-Server bereitstellt

MCP kennt drei Arten von Bausteinen, die ein Server anbieten kann:

• Tools — ausführbare Funktionen mit definiertem Input/Output-Schema. Aus Sicht von Claude Code sehen sie aus wie eingebaute Tools, werden aber an den jeweiligen Server delegiert. Beispiele: create-ticket, list-table-rows, approve-deployment.
• Resources — strukturierte Daten, die das Modell lesen kann (z. B. der Inhalt einer Tabelle, ein Dokument, ein Datenbank-Snapshot). Sie können in den Kontext gezogen werden, ohne dass ein Tool-Call nötig ist.
• Prompts — vordefinierte Prompt-Templates, die der Server für bestimmte Workflows mitliefert. Praktisch, um wiederkehrende Aufgaben standardisiert anzustoßen.

In der Praxis sind Tools der häufigste Baustein. Resources und Prompts kommen ins Spiel, wenn der MCP-Server eigene Datenmodelle oder eigene Workflows mitbringen will.

Konkrete Use-Cases

Wo sich eigene MCP-Server in der Praxis lohnen:

• Eigene Datenbank. Statt jedes Mal SQL über Bash abzusetzen, gibt es typisierte Tools wie list-table-rows, write-table-row oder approve-table-row — mit eingebauter Validierung und klaren Berechtigungen.
• Issue-Tracker. Ein MCP-Server vor dem internen Ticketsystem ermöglicht es, neue Tickets anzulegen, Status zu setzen oder Kommentare zu schreiben — direkt aus der Session, ohne den Browser zu öffnen.
• Internes API. Ein bestehendes REST- oder GraphQL-Backend bekommt einen MCP-Wrapper. Damit kann Claude Code Daten ziehen, Berichte erzeugen oder Operationen anstoßen — mit denselben Auth-Regeln, die auch andere Clients haben.
• Content-Pipelines. RAG-Maps, Note-Maps, Phasen-Items oder semantische Suche werden als Tools angeboten. Die Session arbeitet inhaltlich, ohne dass der Anwender jedes Mal die zugrundeliegende Struktur erklären muss.

Sicherheit: MCP läuft durch den Auto-Classifier

Ein wichtiger Punkt, der gerne übersehen wird: Jeder MCP-Tool-Call läuft durch dieselben Sicherheits-Mechanismen wie ein interner Tool-Call. Die Permission-Engine prüft die Allowlist, der Auto-Classifier bewertet die Semantik, und erst dann erreicht der Call den Server.

Das bedeutet zwei Dinge:

1. Die Berechtigungs-Strategie für MCP-Tools muss sauber sein — pauschale Allowlists für schreibende Tools sind gefährlich.
2. Der MCP-Server selbst sollte zusätzlich validieren, was er bekommt — niemals davon ausgehen, dass schon der Classifier alles abfängt.

Ein Beispiel aus der eigenen Praxis: Ein approve-table-row-Tool, das State-Transitions validiert. Wenn ein Aufruf von failed direkt auf approved springen will, lehnt der Server mit E_INVALID_STATE_TRANSITION ab — selbst wenn der Classifier den Call zufällig durchgewunken hätte. Das ist Defense in Depth in der Praxis.

Empfehlung für den Einstieg

Wer zum ersten Mal einen eigenen MCP-Server bauen will, ist mit folgendem Pfad gut beraten:

1. Klein starten — ein einzelner Lesezugriff (z. B. „Liste alle offenen Tickets”) als erstes Tool.
2. Schemata sauber halten — JSON-Schema für Input und Output, damit Claude die Calls korrekt formuliert und Antworten interpretiert.
3. Lokal entwickeln — stdio-Transport, im eigenen Projektordner. Erst wenn der Server stabil läuft, in ein Team-Setup heben.
4. Schreibende Operationen explizit gestalten — keine pauschale Allowlist; jeder Schreibzugriff geht durch den Classifier und idealerweise durch eine Tool-eigene Plausibilitäts-Prüfung.

Fazit

MCP ist das Element, das Claude Code von einem reinen Coding-Werkzeug zu einer Plattform für domänenspezifische KI-Workflows macht. Wer eigene Daten und Tools sauber anbindet, erweitert den Aktionsradius enorm — und kann mit derselben Session deutlich mehr ausrichten als mit den eingebauten Werkzeugen allein.

Das gelingt nur, wenn die Berechtigungsschicht auf beiden Seiten ernst genommen wird: in der /permissions-Konfiguration des Clients und in der internen Logik des Servers. Beides zusammen macht den Unterschied zwischen einer beeindruckenden Demo und einem System, das produktiv tragfähig ist.