Claude Code und MCP: welche Systeme dein KI-Agent überhaupt sehen darf

Was MCP eigentlich ist - und warum es mehr als ein Protokoll ist

Das Model Context Protocol, kurz MCP, ist ein offener Standard, den Anthropic entwickelt hat, um KI-Modellen strukturierten Zugang zu externen Werkzeugen, Datenquellen und Diensten zu geben. Technisch gesehen definiert MCP, wie ein Sprachmodell mit sogenannten MCP-Servern kommuniziert - kleine Dienste, die bestimmte Fähigkeiten bereitstellen, etwa Datenbankabfragen, Websuchen oder den Zugriff auf interne APIs.

Wenn du Claude Code mit einem MCP-Server verbindest, siehst du in der Dokumentation vor allem technische Details: Welches Format die Nachrichten haben, wie die Authentifizierung funktioniert, was der Server zurückgibt. Was dabei leicht untergeht: Du entscheidest in diesem Moment, welche Systeme dein Agent grundsätzlich wahrnehmen und benutzen kann.

Das ist keine Kleinigkeit. Ein Agent, der Zugang zu deinem CRM hat, kann Kundendaten lesen. Einer mit GitHub-Anbindung kann Code pushen. Einer mit Datenbankzugriff kann Einträge verändern. Die technische Frage «Wie verbinde ich diesen Server?» ist schnell beantwortet. Die eigentliche Frage lautet: «Soll mein Agent das überhaupt dürfen?»

Claude Code SDK als universelles Agent-Gerüst

Anthropics Developer Platform hat in den vergangenen Monaten eine klare Richtung eingeschlagen, die es wert ist, genauer zu betrachten. Wie das Team selbst beschreibt, hat sich der Fokus verschoben: weg von schwerem Scaffolding mit festen Strukturen hin zu leichten Agenten-Schleifen, in denen Claude autonom Werkzeuge auswählt und ausführt - mit minimalen äußeren Einschränkungen.

Das Claude Code SDK ist dabei mehr als ein Coding-Assistent. Anthropic positioniert es explizit als allgemeines Agent-Gerüst. Neue serverseitige Funktionen wie Websuche, kontextbewusstes Abrufen von Inhalten und das automatische Entfernen veralteter Werkzeugaufrufe aus dem Kontext machen deutlich: Claude Code soll nicht nur Code schreiben, sondern eigenständig in Arbeitsabläufe eingreifen.

Wie Every in einem Artikel über die Entstehungsgeschichte von Claude Code berichtet, wurde das Werkzeug von Anfang an so konzipiert, dass es sowohl für technische als auch für nicht-technische Nutzer zugänglich ist - von einfachen Anwendungsfällen bis hin zu komplexen Migrationen und Multi-Agent-Workflows. Das klingt nach einer guten Nachricht. Und es ist eine - solange die Frage, welche Werkzeuge dem Agenten zur Verfügung stehen, bewusst beantwortet wird.

Subagenten und der Multiplikationseffekt

Claude Code unterstützt sogenannte Subagenten - spezialisierte Teilprozesse, die vom Hauptagenten delegiert werden. Das ist mächtig, weil es parallele Arbeit ermöglicht. Es bedeutet aber auch, dass sich die Frage der Sichtbarkeit multipliziert. Wenn dein Hauptagent fünf Subagenten startet und jeder von ihnen Zugang zu drei MCP-Servern hat, entsteht eine Zugriffsfläche, die schnell unübersichtlich wird.

Kontext ist eine knappe Ressource - behandle ihn so

Kenny Liao bringt es auf den Punkt: «Context engineering is building dynamic systems that provide the right information at the right time» - und er behandelt Kontext dabei ausdrücklich als knappe Ressource, vergleichbar mit Aufmerksamkeit. Das ist keine Metapher. Forschungsergebnisse zeigen, dass die Modellleistung messbar sinkt, sobald irrelevante Texte oder zu viele Eingabe-Tokens den Kontext auffüllen.

Für die MCP-Konfiguration bedeutet das: Jeder aktive MCP-Server, den du deinem Agenten zur Verfügung stellst, nimmt potenziell Platz im Kontext ein - durch Werkzeugbeschreibungen, Schemata und Ergebnisse. Wenn dein Agent zwölf MCP-Server sieht, von denen er in einem typischen Workflow nur zwei benötigt, verschwendest du nicht nur Kontext. Du senkst aktiv die Qualität seiner Ausgaben.

Dan, der sich intensiv mit Context Engineering für Claude Code beschäftigt hat, formuliert dazu zwei klare Strategien: Reduce und Delegate. Auf die MCP-Konfiguration übertragen heißt das: Entferne MCP-Server, die du nicht aktiv brauchst (Reduce), und delegiere spezifische Aufgaben an spezialisierte Subagenten mit eigenen, begrenzten Werkzeugsets (Delegate). Dieses Prinzip der progressiven Offenlegung - der Agent sieht immer nur, was er gerade braucht - ist der entscheidende Hebel für stabile Agent-Performance.

Werkzeuge, die niemand nutzt, schaden trotzdem

Ein häufiges Muster in der Praxis: Beim ersten Aufsetzen eines Claude Code-Agenten werden viele MCP-Server angebunden, weil man «schon mal alles drin haben» möchte. Drei Monate später sind acht Server aktiv, von denen regelmäßig zwei genutzt werden. Die anderen sechs belasten den Kontext, erzeugen potenzielle Sicherheitsflächen und verlangsamen das Modell bei komplexen Anfragen.

Welche Systeme darf dein Agent sehen - und welche nicht?

Die Antwort hängt von zwei Dimensionen ab: Sensibilität der Daten und Reichweite der möglichen Aktionen. Beides zusammen ergibt das Risikoprofil eines MCP-Servers. Folgende Tabelle gibt dir eine Orientierung für typische Systeme:

Diese Einordnung ist keine abschließende Liste - sie zeigt das Denkmuster, das du auf jede Anbindung anwenden solltest. Lesen ist weniger riskant als Schreiben. Öffentliche Daten sind weniger heikel als personenbezogene. Reversible Aktionen sind besser als irreversible.

MCP ist eine Rechtsfrage, keine Technikfrage

Scott Wu, CEO von Cognition Labs, hat in einem Gespräch über autonome Coding-Agenten eine Unterscheidung getroffen, die weit über Coding-Werkzeuge hinausgeht: Autonome Agenten arbeiten asynchron an vollständigen Aufgaben, während Co-Pilot-Werkzeuge synchron neben dem Menschen arbeiten. Diese Unterscheidung verändert die Frage der Verantwortung fundamental.

Wenn Claude Code als autonomer Agent arbeitet - und das ist die Richtung, in die Anthropic das Werkzeug entwickelt - dann trifft er Entscheidungen ohne menschliche Bestätigung im Einzelfall. Das bedeutet: Die Zugangsentscheidungen, die du vor dem Start triffst, sind die einzigen Kontrollen, die in diesem Moment greifen. Es gibt keinen zweiten Moment, in dem du prüfen kannst, ob der Agent wirklich auf das interne ERP-System zugreifen sollte.

Diese Verschiebung macht MCP-Konfiguration zu einer Governance-Aufgabe. Sie gehört nicht in den Ermessensspielraum eines einzelnen Entwicklers, der an einem Freitagnachmittag einen neuen Server anbindet. Sie gehört in einen Prozess, der Datenschutzverantwortliche, Systemverantwortliche und - bei sensiblen Systemen - die Geschäftsführung einbezieht.

Der Unterschied zwischen verbunden und freigegeben

In der Praxis sehen wir regelmäßig Setups, in denen MCP-Server technisch korrekt konfiguriert sind - Authentifizierung funktioniert, die Werkzeuge werden erkannt, der Agent kann auf das System zugreifen. Gleichzeitig fehlt jede organisatorische Grundlage: kein Eintrag im Verarbeitungsverzeichnis, kein definierter Verantwortlicher, kein Log der Agent-Aktionen auf dem verbundenen System.

«Verbunden» beschreibt den technischen Zustand. «Freigegeben» beschreibt den organisatorischen. Beide müssen vorhanden sein, bevor ein Agent produktiv auf ein System zugreift. Unsere Prüfliste für Werkzeug-Anbindungen trennt diese beiden Ebenen systematisch - und hilft dir, keine davon zu vergessen.

MCP-Server praktisch konfigurieren - worauf du achten musst

Wenn die organisatorische Freigabe vorliegt, geht es an die technische Konfiguration. Hier sind die Stellschrauben, die den Unterschied machen:

Scope-Einschränkungen nutzen

Viele MCP-Server unterstützen Scope-Parameter, die den Zugriff auf bestimmte Ressourcen einschränken. Ein GitHub-Server kann so konfiguriert werden, dass er nur auf bestimmte Repositories zugreift. Ein Datenbankserver kann auf Read-Only-Rollen beschränkt werden. Nutze diese Möglichkeiten konsequent - auch wenn du technisch Vollzugriff haben könntest.

Aufgabenspezifische Konfigurationen

Anstatt einen universellen Agenten mit allen MCP-Servern zu konfigurieren, lohnt es sich, aufgabenspezifische Profile zu definieren. Ein Agent für Code-Reviews braucht andere Werkzeuge als ein Agent für Kundenanfragen. Context Engineering bedeutet hier: Der Agent bekommt genau die Werkzeuge, die er für seine aktuelle Aufgabe braucht - nicht alles, was theoretisch nützlich sein könnte.

Dan beschreibt in seiner Analyse zu Context Engineering mit Claude Code den Ansatz von Context Bundles: vordefinierte Kombinationen von Werkzeugen und Kontextinformationen für spezifische Aufgabentypen. Diese Bundles lassen sich wie Vorlagen verwenden und stellen sicher, dass ein Agent immer nur die für seine Aufgabe relevante Sichtbarkeit erhält.

Logging und Nachvollziehbarkeit

Jede Aktion, die ein Agent über einen MCP-Server ausführt, sollte protokolliert werden - nicht als Misstrauenssignal, sondern als Grundlage für Verbesserungen und als Nachweis im Fehlerfall. Anthropic hat mit der agentic memory-Funktion einen Mechanismus eingeführt, durch den Agenten aus früheren Ausführungen lernen können. Dieser Mechanismus setzt voraus, dass Logs existieren und ausgewertet werden.

Häufige Fehler in der Praxis - und wie du sie vermeidest

Aus der Arbeit mit verschiedenen Teams und Setups lassen sich einige Muster identifizieren, die immer wieder auftreten. Die gute Nachricht: Sie sind alle vermeidbar, wenn du die richtigen Fragen frühzeitig stellst.

Fehler 1: Maximale Anbindung als Standard

Der häufigste Fehler ist, einen Agenten mit allen verfügbaren Werkzeugen auszustatten, weil man nicht weiß, was er brauchen wird. Das mag kurzfristig bequem sein, führt aber zu den beschriebenen Kontextproblemen und einer unnötig großen Angriffsfläche. Der Ansatz sollte umgekehrt sein: Starte minimal und füge Werkzeuge hinzu, wenn sich ein konkreter Bedarf zeigt.

Fehler 2: Keine Trennung zwischen Entwicklungs- und Produktionsumgebung

Ein Agent, der in der Entwicklungsumgebung getestet wurde und dabei Zugang zu einer Testdatenbank hatte, sollte nicht mit denselben Berechtigungen in die Produktionsumgebung übertragen werden. Das klingt selbstverständlich - in der Praxis passiert es regelmäßig, weil die Konfigurationsdatei einfach kopiert wird.

Fehler 3: Werkzeuge ohne Werkzeugbeschreibungen

Claude Code entscheidet auf Basis der Werkzeugbeschreibungen, wann und wie es ein Werkzeug einsetzt. Schlechte oder fehlende Beschreibungen führen dazu, dass der Agent Werkzeuge falsch oder zu häufig einsetzt. Investiere Zeit in klare, präzise Beschreibungen für jeden MCP-Server - das ist kein Luxus, sondern Grundvoraussetzung für zuverlässiges Verhalten.

Fehler 4: Fehlende Revision bei Personalwechsel

MCP-Server werden oft von einzelnen Personen konfiguriert und dann vergessen. Wenn die Person das Unternehmen verlässt, bleibt die Konfiguration - und häufig auch die zugehörigen Credentials - bestehen. Baue eine MCP-Inventur in Offboarding-Prozesse ein.

Checkliste für den produktiven Einsatz von Claude Code mit MCP

Die folgenden Punkte fassen zusammen, was vor dem produktiven Einsatz eines Claude Code-Agenten mit MCP-Anbindungen geprüft sein sollte. Sie sind bewusst nicht rein technisch formuliert, weil die technische Umsetzung ohne die organisatorische Grundlage nicht ausreicht.

Die vollständige Prüfliste mit allen Kontrollpunkten - aufgeteilt nach technischer und organisatorischer Ebene - findest du als Download. Sie ist so aufgebaut, dass du sie sowohl mit deinem Entwicklungsteam als auch mit nicht-technischen Stakeholdern durcharbeiten kannst.

Der Wettbewerb schläft nicht - aber Sicherheit bleibt Pflicht

Der Competitive Pressure rund um KI-Agenten ist enorm. Wie verschiedene Marktbeobachter beschreiben, führt die Konkurrenz zwischen Anthropic, OpenAI und Google dazu, dass neue Fähigkeiten in immer kürzeren Zyklen veröffentlicht werden. Claude Opus 4.5 führt derzeit bei Coding- und Enterprise-Workflows, aber die nächste Version ist bereits in Arbeit.

Dieser Druck verleitet dazu, schnell zu implementieren und Sicherheitsfragen auf später zu verschieben. Das ist verständlich - aber die Erfahrung zeigt, dass «später» bei MCP-Konfigurationen selten kommt. Die Grundstruktur, die du beim ersten Deployment festlegst, bleibt oft monatelang bestehen. Investiere diese Zeit einmal richtig.

Fragen aus der Praxis