MCP verstehen: was es ist, warum die ersten Versuche scheitern und wann sich eines lohnt

Ein Team, mit dem ich gearbeitet habe, schaltete an einem Montag seinen ersten MCP-Server ein und rechnete damit, dass die KI bis Freitag einen echten Geschäftsprozess fährt. Am Freitag war sie langsamer, teurer und gelegentlich mit voller Überzeugung falsch. Das Fazit des Teams: MCP sei überschätzt.

Das klingt nach einer Geschichte über eine gescheiterte Technologie. Ist sie nicht. Es ist eine Geschichte über ein Denkmodell, das nicht zu dem passte, worauf es gerichtet war – und das ist der häufigste und zugleich am leichtesten zu behebende Grund, warum solche Projekte stecken bleiben.

„MCP“ fällt inzwischen in fast jeder Anbieterpräsentation, ohne dass ein sauberes Bild davon mitgeliefert wird, was es ist und worauf es Sie festlegt. Zwei Fragen entscheiden: wie ein KI-Modell Ihre Werkzeuge und Daten sicher erreicht, und warum so viele erste Anläufe schiefgehen. Alles Folgende dient diesen beiden, mit so viel Technik, dass Ihre IT ihr eigenes Problem wiedererkennt. Nichts davon endet vor einer Entscheidung, die Sie treffen, oder einer Frage, die Sie stellen können.

Was Sie da eigentlich einstecken

Das Model Context Protocol ist ein offener Standard, von Anthropic vorgestellt und im November 2024 als Open Source freigegeben. Im Dezember 2025 hat Anthropic es an die Agentic AI Foundation übergeben, einen zweckgebundenen Fonds unter dem Dach der Linux Foundation, mitgegründet von Block und OpenAI. Damit wird es als gemeinsame Infrastruktur der Branche verwaltet und nicht länger als Projekt eines einzelnen Anbieters. Über eine gemeinsame Schnittstelle verbindet es eine KI-Anwendung mit externen Werkzeugen, Daten und Aktionen – statt über eine Anbindung, die für jedes Werkzeug einzeln von Hand gebaut wird.

Das Problem, das es löst, kennt jede Führungskraft aus anderen Integrationsprojekten. Nehmen Sie an, Sie haben mehrere KI-Anwendungen (Claude, einen internen Chatbot, einen Assistenten in der Entwicklungsumgebung) und mehrere Systeme, die sie erreichen sollen (GitHub, Slack, Ihr CRM, eine Datenbank). Von Hand verdrahtet ist das ein M×N-Problem: jede Anwendung an jedes System, eine Verbindung nach der anderen. MCP macht daraus ein M+N-Problem: Wer ein System betreibt, baut einen MCP-Server; wer eine KI-Anwendung baut, baut einen MCP-Client; und alles spielt zusammen.

Der Standard benennt drei Rollen, und diese drei auseinanderzuhalten ist bereits der halbe Weg.

• Host: die KI-Anwendung, die Ihre Leute tatsächlich benutzen: Claude Desktop, eine Entwicklungsumgebung, ein eigener Agent. Der Host koordiniert alles.
• Client: ein Verbindungsstück im Host, das genau eine Verbindung zu genau einem Server hält. Der Host betreibt einen Client je Server, mit dem er spricht.
• Server: ein kleines Programm, das die Fähigkeiten eines Systems (Ihr GitHub, Ihre Datenbank, Ihre Dateien) im MCP-Format anbietet. Er läuft auf derselben Maschine oder entfernt.

Ein Server bietet drei Arten von Dingen an, und die offizielle Architekturdokumentation benennt sie ohne Umschweife. Tools sind Werkzeuge, also Aktionen, die das Modell ausführen kann: eine Datenbank abfragen, eine E-Mail senden, einen Pull Request öffnen. Resources sind Daten, die das Modell nur lesen und als Kontext heranziehen kann: ein Dokument, ein Datensatz, ein Schema. Prompts sind wiederverwendbare Vorlagen, die ein Mensch vor einer Aufgabe auswählt: ein geprüfter Ablauf, eine Hausvorgabe, eine Checkliste.

Der Kellner. Ein MCP-Server ist ein Kellner: Er reicht die Karte und nimmt die Bestellung auf. Er wählt das Gericht nie selbst. Das KI-Modell im Host liest die Karte und entscheidet, was bestellt wird; der Server trägt die Bestellung in die Küche und bringt das Ergebnis zurück.

Darunter, für die Leserschaft aus der IT, ist MCP mit Absicht unspektakulär. Für seine Nachrichten nutzt es JSON-RPC 2.0, und Vorbild war das Language Server Protocol – das erprobte Muster, mit dem ein Editor mit vielen Programmiersprachen sprechen kann. Ein Server läuft lokal als Unterprozess oder entfernt über HTTP mit üblicher Authentifizierung (die Spezifikation empfiehlt OAuth). Mehr Neuerung leistet sich das Protokoll nicht: ein vertrautes Verfahren, auf eine neue Aufgabe gerichtet.

Der Ablauf selbst ist kurz und nachprüfbar. Der Host startet und legt je Server einen Client an. Der Client fragt, was der Server anbietet, und bekommt Namen, Beschreibungen und Eingabeschemata zurück. Der Host reicht sie an das Modell weiter, das Modell wählt ein Werkzeug und dessen Argumente, und der Server führt die eigentliche Logik aus und liefert das Ergebnis. Jede Governance-Entscheidung im weiteren Verlauf dieses Beitrags sitzt auf genau dieser einen Nahtstelle.

Diagramm – ein Host, ein Client je Server, und jeder Server eine einzige kontrollierte Tür in genau ein System. Das Modell liest, was jeder Server anbietet, und entscheidet dann, was es aufruft.

Ist das also nur eine API in klügerer Verpackung?

Diese Frage stellt jeder technische Leser, und sie zeugt von gutem Instinkt. Unter der Haube ruft ein MCP-Server tatsächlich meist eine gewöhnliche REST- oder RPC-API auf. Die Demos sehen aus wie „Werkzeug aufrufen, Ergebnis bekommen“, und genau so sieht auch ein HTTP-Request aus. Also übertragen die Leute MCP auf ihr API-Denkmodell, und genau diese Übertragung bringt die Einführung zu Fall. Darauf zielt auch das Engineering-Team von Docker mit dem unverblümten Titel „You Are Doing MCP Wrong“.

Was MCP über die eingepackte API hinaus leistet, lässt sich klar benennen.

• Auffindbarkeit. Eine schlichte API setzt voraus, dass der Aufrufer ihre Endpunkte bereits kennt; ein MCP-Server kündigt seine Werkzeuge, Schemata und Beschreibungen zur Laufzeit selbst an, sodass ein Modell, das ihn noch nie gesehen hat, herausfinden kann, was im Angebot ist.
• Ein Vertrag über alle Anbieter hinweg. OpenAI, Anthropic und Google definieren den Werkzeugaufruf jeweils anders. MCP ist das eine Format, also läuft ein einmal gebautes Werkzeug in Claude, ChatGPT, Gemini und weiteren: der M+N-Gewinn, eingelöst.
• Das Modell entscheidet, wann aufgerufen wird. Eine schlichte API wird an einer festen Stelle im Code aufgerufen, die eine Entwicklerin gesetzt hat; bei MCP wird das Werkzeug einem Modell angeboten, das selbst wählt, ob und wann es zugreift. Genau dort trifft nicht-deterministisches Schließen auf deterministische Ausführung.
• Beschreibungen, mit denen ein Modell arbeiten kann. Wo eine API-Definition eine URL und Parameter trägt, trägt die Definition eines MCP-Werkzeugs die Absicht, die Voraussetzungen und die Frage, woran sich Erfolg erkennen lässt. Das Modell braucht ein sauberes Werkzeug, das eine Aufgabe von Anfang bis Ende erledigt, nicht Ihre gesamte Fachdomäne.
• Mehr als Werkzeuge. Resources, Prompts und Elicitation (ein geregelter Weg, auf dem ein Server innehält und einen Menschen um Bestätigung oder um eine fehlende Eingabe bittet) haben in einer nackten API keine Entsprechung. Sie zu übersehen ist der häufigste Grund, warum Teams MCP unter Wert nutzen.
• Eine definierte Grenze. MCP legt fest, wo die Authentifizierung sitzt und wie die Verbindung zustande kommt: eine nachprüfbare Nahtstelle zwischen dem Modell und Ihren Systemen statt vieler.

Der USB-C-Anschluss. Vor dem einheitlichen Anschluss brachte jedes Gerät seinen eigenen Stecker und seinen eigenen Treiber mit. MCP ist das USB-C der KI-Werkzeuge: eine genormte Buchse, in die jede standardkonforme KI-Anwendung und jedes standardkonforme System passt.

Die ehrliche Lesart: Die Skeptiker haben einen Punkt. Ein Modell kann eine schlichte API längst aufrufen, und „dafür gibt es doch OpenAPI“ ist keine törichte Position. Der Vorteil von MCP liegt in der Normierung, in der Auffindbarkeit und in Werkzeugverträgen, die auf ein Modell zugeschnitten sind. Sagen Sie das ruhig jedem, der Ihnen mehr verspricht.

Diagramm – unten dieselbe API. Was MCP hinzufügt, sitzt darüber: Auffindbarkeit, ein einziger, dem Modell zugewandter Vertrag über alle Anbieter hinweg, die Entscheidung des Modells über den Zeitpunkt des Aufrufs und eine einzige authentifizierte Grenze.

Woran die Versuche Ihres Teams still scheitern

Fast jede Geschichte vom Typ „MCP funktioniert nicht“, die mir begegnet, folgt einem von sechs Mustern. Zu jedem gehört eine konkrete Abhilfe, die Sie am Montag angehen können.

Eine einzige Tatsache erklärt die meisten davon: MCP ist ein Protokoll, kein Produkt. Wie SMTP für E-Mail oder OAuth für die Anmeldung legt es eine gemeinsame Sprache fest, mehr nicht: keine Authentifizierung, keine Überwachung, keinen Prüfpfad, kein Hosting, keine Ratenbegrenzung, keine Fehlerbehandlung. Das alles kommt von Ihnen. Die meisten Fehlschläge entstehen, weil ein Team annimmt, das Protokoll habe ihm etwas mitgegeben, das es nie versprochen hat.

1. Das überladene Werkzeugregal. Symptom: Sie hängen zehn Server mit je rund fünf Werkzeugen ein, und die KI wird langsamer, teurer und ungenauer. Warum: Die Definition jedes einzelnen Werkzeugs wandert in den Kontext des Modells, bevor es Ihre Anfrage überhaupt liest, und Anthropics eigene Entwickler haben nachgemessen, was das kostet: Jede Definition schlägt mit ein paar hundert Token zu Buche, und in der Summe sind das Hunderttausende Token, ausgegeben vor dem ersten Wort der eigentlichen Aufgabe. Danach arbeitet sich das Modell durch Werkzeuge, die es nie benutzen wird. Abhilfe:

• Hängen Sie einen Server je Aufgabe ein, und nur bei den Agenten, die diese Aufgabe erledigen. Der Assistent im Marketing braucht den Server für die Softwareauslieferung nicht. Schneiden Sie den Zugriff auf Rollen zu, statt alles mit allem zu verbinden.
• Begrenzen Sie den aktiven Werkzeugsatz. Eine brauchbare Faustregel: Trägt ein Agent ein Werkzeug mit sich, das er seit einer Woche nicht aufgerufen hat, hängen Sie es aus.
• Laden Sie Werkzeuge bei Bedarf, nicht alle auf einmal. Anthropics Antwort für große Installationen lautet, MCP-Server als Code anzubieten, den der Agent nur bei Bedarf aufruft; das senkte den Kontextaufwand in den eigenen Tests um bis zu 98,7 Prozent (eine Messung des Anbieters an seiner eigenen Beispiellast, also als Richtung zu lesen, nicht als Zahl, die Sie erreichen werden). Sie müssen das nicht selbst bauen, um das Prinzip zu nutzen: Halten Sie den ständigen Werkzeugsatz jedes Agenten klein und bewusst gewählt.

2. Der Generalschlüssel. Symptom: Ein Server bekommt Vollzugriff auf einen Dienst oder hält die Token für E-Mail, Laufwerk und Datenbank zugleich, damit die KI „alles kann“. Warum: Ein einziger verwirrter oder gekaperter Server hat damit freie Bahn über alles, und die Schadensreichweite eines einzelnen Fehlers ist enorm. Ein Agent löscht einen ganzen Ordner, wo eine einzige Datei gemeint war. Abhilfe:

• Ein eng geschnittenes Zugangsrecht je System, mit dem geringstmöglichen Umfang. Ein CRM-Token, das Kontakte lesen, aber nicht löschen darf. Eine nur lesende Datenbankrolle für alles, was ohnehin nur hinsehen soll.
• Getrennte Server für getrennte Vertrauensbereiche. E-Mail, Datenbank und Zahlungsverkehr sind drei Server mit drei Zugangsdaten, damit ein Einbruch nicht gleich alle drei bedeutet.
• Legen Sie den echten Schlüssel nie dorthin, wo das Modell ihn sehen kann (wie das geht, steht weiter unten).
• Befristen Sie die Token. Kurzlebige OAuth-Token, die ablaufen und erneuert werden, schlagen jeden Dauerschlüssel. Und verlangen Sie eine menschliche Freigabe für alles Zerstörerische oder Unumkehrbare: löschen, an alle senden, zahlen.

3. Den Anschluss für den Agenten halten. Symptom: Das Team steckt MCP an und erwartet, dass die KI einen Prozess von Anfang bis Ende fährt, und sieht dann zu, wie sie stecken bleibt oder etwas Unsinniges tut. Warum: MCP ist Reichweite, kein Urteilsvermögen. Werkzeuge führen aus; Agenten planen, planen um, bewerten und wissen, wann Schluss ist. Das Protokoll liefert das Erste und nichts vom Zweiten. Abhilfe:

• Schreiben Sie die Betriebsregeln des Agenten auf, und zwar in der Agentenschicht, nicht in MCP: das Ziel, die ausdrücklichen Abbruchbedingungen („nach drei Fehlversuchen anhalten“; „vor jeder unumkehrbaren Aktion anhalten und nachfragen“), die Wiederholungsregel und die Stelle, an der ein Mensch freigibt.
• Fangen Sie eng an. Geben Sie dem Agenten eine klar umrissene Aufgabe mit einem prüfbaren Erfolgskriterium, nicht „führe den Prozess aus“. Erweitern Sie erst, wenn die enge Fassung unspektakulär zuverlässig läuft.
• Halten Sie Kopf und Hände getrennt. MCP sind die sicheren Hände; der planende Kopf bleibt in Ihrem Agenten-Framework.

4. Nichtssagende Werkzeugbeschreibungen. Symptom: Das Modell ruft das falsche Werkzeug auf oder das richtige mit schlechten Argumenten. Warum: Das Modell wählt Werkzeuge nach ihrer Beschreibung aus, und „macht Sachen“ gibt ihm nichts an die Hand. Abhilfe:

• Schreiben Sie jede Beschreibung wie die Einweisung einer neuen Kollegin: wann sie zu benutzen ist, wann nicht, wie eine gute Eingabe aussieht, was zurückkommt.
• Benennen Sie Werkzeuge nach ihrer Absicht, nicht nach dem Endpunkt. create_support_ticket, nicht POST /tickets.
• Geben Sie strukturierte, prüfbare Ergebnisse zurück (einen Status, an dem der Agent verzweigen kann), keine Textwand.
• Prüfen Sie es ebenfalls wie eine Neueinstellung: Geben Sie dem Modell fünf realistische Anfragen und beobachten Sie, nach welchem Werkzeug es greift. Greift es daneben, liegt die Abhilfe fast immer in der Beschreibung, nicht im Modell.

5. Blindflug. Symptom: Etwas ist schiefgegangen, und niemand kann sagen, was die KI getan hat, in welcher Reihenfolge und warum. Warum: Das Protokoll bringt keine Ablaufverfolgung mit; was Sie nicht selbst gebaut haben, sehen Sie auch nicht. Abhilfe:

• Protokollieren Sie die ganze Kette (den Plan, welches Werkzeug, welche Argumente, was zurückkam) in einen dauerhaften Speicher, sodass sich jeder Lauf nachspielen lässt.
• Versehen Sie jeden Eintrag mit der anfragenden Person und einem Zeitstempel.
• Setzen Sie das Protokoll an die MCP-Grenze (ein Gateway oder ein Proxy, durch den der Verkehr läuft), damit es alles erfasst, gleich welcher Agent aufgerufen hat, und erzwingen Sie Ratenbegrenzungen und Freigaben je Werkzeug an derselben Nahtstelle. Das ist zugleich die Governance-Antwort, die ein reguliertes Unternehmen braucht , wenn ein Prüfer fragt, was das System getan hat und in wessen Auftrag.

6. Mit Kanonen auf Spatzen. Symptom: Alles läuft in einem Programm mit einem Agenten, und trotzdem wird jede interne Funktion in MCP-Transport verpackt, was Latenz und Komplexität kostet und nichts einbringt. Warum: MCP zahlt sich an Grenzen aus – über Prozesse oder Maschinen hinweg oder zwischen mehreren Anwendungen, die sich einen Werkzeugsatz teilen. Innerhalb eines einzigen Programms gibt es keine Grenze zu überqueren. Abhilfe:

• Im selben Prozess und nur ein Abnehmer? Rufen Sie die Funktion direkt auf. Kein MCP.
• Greifen Sie zu MCP, wenn ein Werkzeug eine Grenze überschreitet (ein anderer Prozess, eine andere Maschine oder das System eines Dritten) oder wenn mehrere Agenten oder Anwendungen es gemeinsam nutzen müssen.
• Der Ein-Satz-Test: Braucht mehr als ein Abnehmer dieses Werkzeug, oder liegt es an einem Ort, den mein Code nicht direkt einbinden kann? Zweimal nein heißt: kein MCP.

Wo es schiefgeht	Die Abhilfe, in einer Zeile
Das überladene Werkzeugregal	Ein Server je Aufgabe, eingehängt nur bei den Agenten, die ihn brauchen; Werkzeuge bei Bedarf laden
Der Generalschlüssel	Ein eng geschnittenes, befristetes Zugangsrecht je System; getrennte Vertrauensbereiche; menschliche Freigabe bei zerstörerischen Aktionen
Den Anschluss für den Agenten halten	Ziel, Abbruchbedingungen und Freigaben gehören in die Agentenschicht; MCP ist Reichweite, kein Urteilsvermögen
Nichtssagende Werkzeugbeschreibungen	Jedes Werkzeug wie für eine neue Kollegin beschreiben; prüfbare Ergebnisse zurückgeben
Blindflug	Plan, Werkzeug und Ergebnis an der Grenze protokollieren, mit Angabe der anfragenden Person
Mit Kanonen auf Spatzen	Gleicher Prozess, ein Abnehmer: ein direkter Funktionsaufruf statt MCP

Sechs Muster, sechs Abhilfen. Die Governance darunter ist unspektakulär und liegt längst im Regal: geringstmögliche Rechte, eine geprüfte Grenze, menschliche Freigabe bei folgenreichen Aktionen.

Was Ihrer IT-Sicherheit wirklich den Schlaf raubt

Die sechs Muster oben lassen MCP enttäuschend wirken. Die nächsten vier bringen ein Sicherheitsteam dazu, Nein zu sagen, und es hat recht damit, sie aufzuwerfen – deshalb steht zu jedem gleich die Abhilfe daneben. Das Muster darunter bleibt gleich: MCP normiert mächtige Zugriffe und senkt die Hürde davor, verstärkt also vertraute Risiken aus der Web-Ära, solange Sie die Leitplanken nicht selbst ziehen.

Prompt Injection. Eine versteckte Anweisung, vergraben in einer E-Mail, einem Ticket oder einer Webseite, die die KI liest – und der sie dann folgt, als hätten Sie sie selbst eingetippt. Abhilfe: Behandeln Sie alles, was ein Werkzeug zurückgibt, als nicht vertrauenswürdige Daten, nie als Anweisung. Halten Sie die festen Anweisungen des Modells von abgerufenen Inhalten getrennt, und stellen Sie vor jede folgenreiche Aktion eine menschliche Freigabe, statt abgerufenen Text sie unmittelbar auslösen zu lassen.

Tool Poisoning. Ein Werkzeug, dessen eigene Beschreibung heimliche Anweisungen trägt. Invariant Labs führte ein schlichtes Werkzeug zum Addieren zweier Zahlen vor, das still eine Datei mit Zugangsdaten nach draußen schleuste; am sichtbaren Namen war davon nichts zu erkennen. Abhilfe: Pinnen Sie die Beschreibungen der Werkzeuge, hinterlegen Sie deren Prüfsumme und schlagen Sie bei jeder Änderung Alarm, damit kein Server nachträglich umschreiben kann, was er tut. Das fängt gleich den nächsten Fall mit ab.

Rug Pull. Ein Server, der sich an dem Tag, an dem Sie ihn freigeben, tadellos benimmt und sich eine Woche später anders verhält. Abhilfe: dieselben gepinnten Beschreibungen, dazu eine echte Prüfung, bevor Sie einen fremden Server aufnehmen, und der Betrieb unbekannter Server in einer Sandbox (siehe unten), damit ein Verhaltenswechsel nichts Wertvolles mehr erreicht.

Gestohlene Token und der verwirrte Stellvertreter. Ein einziges gestohlenes Token wird zur stillen Kontoübernahme, die im Protokoll wie gewöhnlicher Verkehr aussieht. Schlimmer noch: Ein MCP-Server handelt für jeden, der ihn fragt. Eine Person mit geringen Rechten (oder eine eingeschleuste Anweisung) kann ihn also dazu bringen, etwas zu tun, das nur jemandem mit hohen Rechten zusteht – das klassische Confused-Deputy-Problem, das Sicherheitsforscher inzwischen als den Auslieferungszustand von MCP beschreiben, solange Sie nicht dagegen konstruieren. Abhilfe: Halten Sie das Token vollständig aus der Reichweite des Modells (das Muster dafür steht im nächsten Abschnitt), schneiden Sie es eng zu und prüfen Sie bei der heiklen Aktion die Berechtigung der fragenden Person, nicht nur die des Servers.

Was Ihre IT vorzeigen können muss, bevor ein MCP etwas Echtes berührt.

• Jeder fremde Server ist geprüft, und seine Werkzeugbeschreibungen sind gepinnt (Alarm bei Änderung).
• Server, denen Sie nicht vollständig trauen, laufen in einer Sandbox mit Netzwerk-Allowlist; Anthropic liefert eine quelloffene Sandbox-Laufzeitumgebung, die genau dafür gebaut ist.
• Zugangsdaten werden an einem Gateway injiziert, nie an das Modell übergeben (nächster Abschnitt).
• Folgenreiche Aktionen verlangen eine menschliche Freigabe; abgerufene Inhalte lösen sie nie von allein aus.
• Alles wird an einer Grenze protokolliert, mit Angabe der Person, die gefragt hat.

Ein gemeinsames MCP oder ein Login pro Person?

Eine echte Weggabelung im Entwurf kommt in dem Moment, in dem MCP den Laptop einer einzelnen Entwicklerin verlässt und ein Team bedient. Nehmen Sie an, Sie wollen der gesamten Marketingabteilung ein MCP geben, das Ihre Analytics und Ihr CMS erreicht. Die Standardantwort der Spezifikation lautet OAuth: Jede Person meldet sich einzeln an, und der Server handelt mit deren Rechten. Für die Zurechenbarkeit ist das sauber, aber es reibt: Jede Person im Marketing authentifiziert sich an jedem System, und irgendjemand pflegt all diese Token.

Die verlockende Alternative ist ein vorab authentifiziertes, gemeinsames MCP: ein einziger Dienstzugang, den die ganze Abteilung nutzt, ohne persönliche Anmeldung. Das wirkt elegant. Und genau dort ballt sich das Risiko. Lesen Sie den Tausch ohne Beschönigung.

	OAuth je Person (jede meldet sich an)	Vorab authentifiziertes, gemeinsames MCP (ein Zugang)
Reibung	Hoch: Jede Person authentifiziert sich an allem	Niedrig: Niemand meldet sich an
Zurechenbarkeit	Jede Aktion nennt eine echte Person	Aktionen nennen „das Marketing-MCP“, nicht wer gehandelt hat
Geringstmögliche Rechte	Folgen dem Zugriff der jeweiligen Person	Ein Dauerzugang, meist weit gefasst
Schadensreichweite bei Missbrauch	Der Zugriff einer Person	Der Zugriff der ganzen Abteilung, auf einen Schlag
Entzug	Eine Person sauber sperren	Ein Schlüsselwechsel wirft alle hinaus
Anfälligkeit für den verwirrten Stellvertreter	Geringer: Der Rechteumfang folgt der Person	Höher: Eine eingeschleuste Anweisung läuft mit dem weiten, geteilten Rechteumfang

Lesen Sie die Spalte mit dem gemeinsamen Zugang von oben nach unten, und Sie sehen den Einwand des Sicherheitsteams entstehen: Sie haben ein wenig Bequemlichkeit gegen einen fetten, dauerhaft offenen, niemandem zurechenbaren Zugang getauscht, und eine einzige Prompt Injection oder ein gestohlenes Token bewegt sich jetzt im Maßstab der ganzen Abteilung.

Die beiden Optionen sind allerdings ein falsches Entweder-oder, und die Auflösung ist der brauchbare Teil. Halten Sie auseinander, wer fragt und welcher Zugang das System erreicht. Lassen Sie jede Person sich günstig an der Vordertür anmelden, über Ihr vorhandenes Single Sign-on, damit die Identität an der Person hängt und jede Aktion zurechenbar bleibt. Halten Sie dann genau einen kontrollierten, eng geschnittenen Dienstzugang für das dahinterliegende System vor und injizieren Sie ihn an einem Gateway, durch das die Anfrage läuft, sodass weder Mensch noch Modell je den echten Schlüssel in der Hand hält. Gemeinsamer Zugriff, persönliche Zurechenbarkeit, geringstmögliche Rechte und eine einzige Stelle zum Protokollieren, Zuschneiden und Entziehen. Die Frage lautete nie „gemeinsames MCP oder persönliche Logins“: Der richtige Entwurf teilt den Zugriff und hält Identität und Geheimnis auseinander.

CLI oder MCP? Wann die schlichte Kommandozeile weiter reicht

Bevor Sie irgendetwas davon bauen, wiegen Sie einen älteren und leiseren Weg ab, einer KI Hände zu geben: Lassen Sie sie ein Kommandozeilenwerkzeug so benutzen, wie eine Entwicklerin es tut (git, gh, aws, ein Shell-Skript), statt einen MCP-Server zu bauen. Lange war das Argument für die CLI schlicht und stark: Sie ist sparsam im Kontext. Ein MCP-Client lädt die Definition jedes Werkzeugs üblicherweise vorab in den Kontext des Modells, und Anthropics eigene Messungen beziffern die Kosten dafür auf Hunderttausende Token, sobald genug Server angeschlossen sind. Eine CLI trägt fast nichts davon: Das Modell weiß bereits, wie eine Kommandozeile funktioniert, und gibt seinen Kontext für die eigentliche Aufgabe aus. Ein unabhängiger Vergleich sieht die CLI bei vielen Agenten-Abläufen um 60 bis 90 Prozent sparsamer im Tokenverbrauch (die Messung eines Teams an seinen eigenen Lasten, kein geprüfter Benchmark).

Ist die CLI damit rundheraus die klügere Wahl? Für den Agenten einer einzelnen Entwicklerin auf einer Maschine oft ja. Sobald Sie aber im ganzen Unternehmen ausrollen, verschiebt sich das Bild, und zwar in zwei Richtungen zugleich.

Gegen die CLI im Unternehmensmaßstab spricht: Eine offene Shell ist die größtmögliche Angriffsfläche und das, was sich am schwersten steuern lässt. Ein Agent, den sich die ganze Marketingabteilung teilt und der beliebige Befehle ausführen kann, ist eine erheblich größere Sorge als einer, der nur drei benannte, eng geschnittene Werkzeuge aufrufen darf. Ein MCP-Werkzeug ist konstruktionsbedingt begrenzt: typisierte Eingaben, ein fester Satz von Aktionen, eine Stelle zum Protokollieren und Freigeben. Genau das wollen ein Prüfer und ein Sicherheitsteam. Der Tausch ist derselbe, der unter jedem Abschnitt hier läuft: Die CLI ist auf einen schlanken Kontext hin gebaut, MCP auf eine kontrollierte Grenze.

Und das Token-Argument, die stärkste Karte der CLI, sticht nicht mehr so klar wie früher. Anthropics Antwort auf den aufgeblähten Kontext lautet nicht „weg von MCP, hin zur Shell“, sondern Codeausführung mit MCP: Der Agent ruft MCP-Server als Code auf und lädt nur die Werkzeuge, die eine Aufgabe braucht. Das holt den Großteil der Effizienz der CLI zurück und behält zugleich den typisierten, kontrollierten und anbieterübergreifenden Vertrag von MCP. Was beim Tokenverbrauch gegen die CLI verliert, ist eben die naive Art, MCP zu betreiben: jeden Server einhängen, jede Definition laden. Eine disziplinierte Installation tut das meist nicht.

Greifen Sie zur CLI, wenn: es um eine Entwicklerin oder einen Agenten auf einer Maschine geht; das Werkzeug ohnehin ein gutes Kommandozeilenwerkzeug ist; das Token-Budget die bindende Grenze ist und Sie eine weite, schwer steuerbare Fläche in Kauf nehmen können.

Greifen Sie zu MCP, wenn: mehrere Personen oder Agenten sich den Werkzeugsatz teilen; Sie typisierte Eingaben, Zuschnitt, Freigaben und eine geprüfte Grenze brauchen; Sie Werkzeuge einem Modell zugänglich machen, das Sie nicht vollständig kontrollieren. Halten Sie dann den aktiven Werkzeugsatz jedes Agenten klein, damit die Tokenkosten dort bleiben, wo eine disziplinierte Installation sie hält.

MCP, verwaltete Agenten, Sandboxes: drei Aufgaben, keine drei Alternativen

Führungskräfte sollen sich immer wieder zwischen MCP, verwalteten Agenten und Sandboxes entscheiden, und schon die Frage ist der Fehler. Es sind drei Schichten desselben Aufbaus. Sauber auseinanderhalten lassen sie sich so: erreichen, ausführen, isolieren.

• MCP erreicht. Es ist der Weg, auf dem der Agent Ihre Werkzeuge und Daten erreicht: die genormte Steckdose zwischen einem Modell und Ihren Systemen. Es bringt weder eine eigene Laufzeitumgebung noch eine eigene Isolation mit.
• Ein verwalteter Agent führt aus. Er ist die betriebene Laufzeitumgebung, in der die Agentenschleife tatsächlich läuft: Zeitsteuerung, Gedächtnis, Identität, Zugangsdaten und Prüfpfad als Leistungen der Plattform. Hier wohnt das Denken, und hier überdauert es.
• Eine Sandbox isoliert. Sie ist die verschlossene Box, in der der Code des Agenten läuft, damit ein Fehler oder eine bösartige Aktion weder den Wirtsrechner noch das übrige Netz berührt. Container und Micro-VMs mit kontrolliertem ausgehendem Zugriff erledigen diese Aufgabe.

Sie ergänzen sich, statt zu konkurrieren. Eine echte Installation nutzt alle drei zugleich: Ein verwalteter Agent (ausführen) arbeitet innerhalb einer Sandbox (isolieren) und erreicht Ihre Systeme über MCP (erreichen). Zu fragen, ob man MCP oder verwaltete Agenten nehmen soll, ist eine Verwechslung der Kategorien, so als fragte man, ob man eine Steckdose oder einen Elektriker braucht.

Der Handwerker auf Ihrer Baustelle. MCP sind die genormten Anschlüsse in der Wand: Strom, Wasser, Daten. Der verwaltete Agent ist der Handwerker, der anrückt, die Arbeit plant und sie über Tage ausführt. Die Sandbox ist die abgesperrte Baustelle mit Helmpflicht, die er nicht verlassen darf, damit nichts von dem, was er tut, den Rest des Gebäudes beschädigt. Drei verschiedene Dinge – und bei einem ernsthaften Auftrag wollen Sie alle drei.

Ein Detail macht die Sandbox zu mehr als einer netten Zugabe, und genau dort bekommt die Frage nach den Zugangsdaten aus den letzten beiden Abschnitten ihre Antwort. Richtig gebaut ist die Sandbox die äußere Grenze, und der verwaltete Agent läuft strikt innerhalb davon. Der Agent hält Ihre echten API-Schlüssel nie. Er hält nur eine Variable, einen Platzhalter oder eine Basis-URL, die auf das Gateway der Sandbox zeigt. In dem Moment, in dem eine Anfrage die Box verlässt, tauscht das Gateway an der Grenze den Platzhalter gegen die echten Zugangsdaten und leitet sie weiter.

Genau so arbeitet Anthropics eigenes Agenten-Sandboxing: Die Umgebung des Agenten bekommt überhaupt keine Schlüssel, ein Egress-Gateway injiziert sie am Rand, und weil das Geheimnis außerhalb des Agenten liegt, kann keine Prompt Injection und kein gekapertes Werkzeug in der Box es lesen oder abfließen lassen. Diese eine Entwurfsentscheidung beantwortet drei der oben genannten Ängste auf einmal: den verwirrten Stellvertreter (der Zugang ist eng geschnitten und wird injiziert, der Agent kann ihn gar nicht missbrauchen), den Diebstahl von Token (der Agent hat kein Token, das sich stehlen ließe) und das Abfließen durch Prompt Injection (in Reichweite liegt nichts, was abfließen könnte).

Diagramm – die Sandbox ist die äußere Box. Der verwaltete Agent läuft darin und hält für jedes Geheimnis nur einen Platzhalter; das Gateway an der Grenze löst diesen Platzhalter beim Verlassen der Box in die echten Zugangsdaten auf und erreicht Ihre Systeme über MCP. Der Agent sieht nie einen echten Schlüssel.

Der Begleitbeitrag nimmt sich die Schichten ausführen und isolieren in derselben nüchternen Sprache vor: welchem Anbieter einer verwalteten Laufzeitumgebung Sie lange laufende Arbeit anvertrauen sollten und was eine Sandbox Ihnen tatsächlich verschafft.

Wann sich ein MCP lohnt, und wann nicht

Beginnen Sie mit den Fällen, in denen es sich klar auszahlt. Ein MCP-Server lohnt den Bau, wenn Ihr KI-Assistent echte Unternehmenssysteme durch eine einzige kontrollierte Tür erreichen soll: Kontext aus einem gemeinsamen Laufwerk oder Wiki ziehen, in Slack, Jira oder einem CRM handeln und jedem Team denselben geprüften Werkzeugsatz geben, gleich welche KI-Anwendung es benutzt. Zum Start lieferte Anthropic Referenz-Server für Google Drive, Slack, GitHub und Postgres mit und nannte Block und Apollo als frühe Anwender; das Muster ist also nicht theoretisch.

Der Gewinn ist deutlich genug: ein Server je System statt einer Anbindung je Anwendung, eine Modellwahl, die Ihnen erhalten bleibt, und eine einzige Nahtstelle für Authentifizierung, Zuschnitt, Protokollierung und Freigaben. Auch das Umfeld bewegt sich in Ihre Richtung: OpenAI, Google und neue Systeme kommen zunehmend MCP-fähig auf den Markt.

Was es kostet, ist der Anfang der Geschichte von Montag bis Freitag, und wer das beschönigt, läuft genau dort hinein. Jedes Werkzeug ist eine Angriffsfläche und jede Berechtigung eine Haftung. Das Protokoll bringt keine Leitplanken mit, also landen Hosting, Überwachung, Prüfpfad und Ratenbegrenzung bei Ihrem Betrieb. Die Spezifikation ist jung und noch in Bewegung. Und am falschen Ort ist sie reiner Aufwand ohne Gegenwert.

Die Entscheidung, kurz genug zum Behalten.

Greifen Sie zu MCP, wenn: mehrere KI-Anwendungen sich einen geprüften Werkzeugsatz teilen müssen; die Werkzeuge über Prozesse, Maschinen oder das System eines Dritten verteilt liegen; Sie eine einzige kontrollierte Grenze für Authentifizierung und Prüfpfad wollen; oder Sie sich die Wahl des Modells offenhalten wollen.

Lassen Sie es, wenn: ein einzelner Agent im selben Prozess ein paar Funktionen aufruft; die Aufgabe eine feste, deterministische Kette ist, in der ein Modell nichts zu entscheiden hat; oder Sie die Leitplanken, die das Protokoll voraussetzt, noch nicht finanzieren können. Trifft das Letzte zu, finanzieren Sie zuerst die Leitplanken, und schließen Sie erst dann an.

Jede gescheiterte Einführung, die ich gesehen habe, lässt sich auf einen einzigen fehlenden Satz zurückführen. Lassen Sie Ihr Team ihn laut aussprechen, bevor es baut. Ein MCP gibt einer KI sicheren Zugriff auf Ihre Werkzeuge. Es gibt ihr kein Urteilsvermögen, keine Laufzeitumgebung und keinen Zaun. Das fügen Sie hinzu, mit Absicht, bevor Sie es einschalten.