MCP vs. CLI für KI-Agenten: Welche Option sollten Sie nutzen?

Die MCP-vs.-CLI-Debatte ist eine dieser Diskussionen, die auf Reddit beginnt, zu Hacker News wandert und schließlich als halbfertige Entscheidung, die niemand getroffen hat, im Architektur-Dokument Ihres Teams landet. Ich habe das oft genug erlebt, um eine klare Position zu haben: CLI ist für die meisten Agentenaufgaben die bessere Standardwahl, MCP rechtfertigt seine Komplexität nur dann, wenn Sie wirklich zentrale Authentifizierung, strukturierte Tool-Erkennung oder serviceübergreifende Orchestrierung benötigen, und die meisten Produktionssysteme, die länger als sechs Monate laufen, nutzen am Ende beides.

Wenn Sie anderer Meinung sind, umso besser. Das ist der richtige Ausgangspunkt.

Was Teams zu spät lernen

• CLI verbraucht für vergleichbare Aufgaben 4- bis 32-mal weniger Tokens als MCP – und dieser Unterschied summiert sich im großen Maßstab.
• MCP rechtfertigt seinen Overhead nur, wenn Sie zentrale Authentifizierung, schema-basierte Erkennung oder serviceübergreifende Orchestrierung in einem KI-Agenten-Workflow benötigen.
• Die eigentliche Entscheidung ist eine Portfolioentscheidung: CLI für die innere Schleife, MCP für die äußere Schleife.
• Die meisten „MCP vs. CLI“-Debatten lassen direkte HTTP-APIs aus – manchmal sind sie für beides die richtige Antwort.

MCP vs. CLI: Der Vergleich, den die meisten Teams falsch herum führen

Die übliche Einordnung behandelt dies als Frage der Funktionen. Das ist es nicht. Es ist eine Frage von Kosten und Kontext. Hier unterscheiden sich beide Ansätze in der Praxis tatsächlich.

Die MCP-Debatte bleibt meist bei der Frage hängen, ob das MCP-Protokoll „besser“ ist. Das ist die falsche Achse. Das CLI-Tool, das Sie bereits haben, funktioniert in den meisten Einzelagenten- und lokalen Umgebungen ohne zusätzliche Infrastruktur. Ein MCP-Server rechtfertigt seine Existenz, wenn das Koordinationsproblem real ist.

Warum CLI für dieselbe Aufgabe weniger Tokens als MCP verbraucht

Token-Kosten sind für KI-Agenten auf eine Weise relevant, wie sie es bei einzelnen Prompts nicht sind. Ein Agent, der pro Sitzung Dutzende Tool-Aufrufe über Hunderte Sitzungen täglich ausführt, verbrennt bei jedem zusätzlichen Token im Kontextfenster Geld. Die Entscheidung zwischen Tools und Infrastruktur wird letztlich zu einer Budgetentscheidung.

Der Benchmark, der diese Debatte für mich fundiert hat: Shareuhacks Analyse eines Vergleichs mit 75 Durchläufen zwischen direkten API-Aufrufen, MCP-Servern und CLI-Tools für KI-Agenten ergab, dass CLI 4- bis 32-mal weniger Tokens kostet als CLI-äquivalente MCP-Aufrufe. Gleichzeitig erreichten CLI-basierte Agenten in bestimmten Automatisierungs-Workflows eine Erfolgsquote von 100 % gegenüber 72 % bei ihren MCP-Pendants. Diese Spanne von 4 bis 32 ist groß genug, um zu sagen: „Es hängt von der Aufgabe ab.“ Doch selbst das Minimum liegt bei dem Vierfachen, und das Maximum ist teuer.

Die Mechanismen hinter diesem Unterschied sind es wert, einzeln verstanden zu werden, weil sie auf unterschiedliche Fehlermodi hinweisen.

Wie sich MCP-Kosten pro Anfrage summieren

Das schema-gesteuerte Design von MCP ist zugleich sein Token-Problem. Bevor ein Agent MCP-Tool-Aufrufe ausführen kann, muss er die Tool-Definitionen vom MCP-Server laden. Jedes Tool im Register trägt zu dieser anfänglichen Schema-Nutzlast bei – der Agent muss wissen, welche Tools existieren, welche Parameter sie akzeptieren und welche Ausgaben zu erwarten sind, bevor er eines davon aufrufen kann.

Bei einem typischen MCP-Setup mit einer Handvoll Tools kann das Laden des Schemas jeder Anfrage Hunderte Tokens hinzufügen, noch bevor der eigentliche Befehl ausgeführt wird. Wenn Sie auf Dutzende Tools über mehrere Server skalieren, muss MCP den Agenten dazu bringen, pro Zyklus deutlich mehr Kontext mitzuführen. Bei hohen Aufrufvolumina ist dieser Overhead kein Rundungsfehler. Er ist ein eigener Budgetposten.

Woher die Token-Effizienz von CLI kommt

CLI-basierte Agenten tragen diesen Schema-Overhead nicht, weil sie ihn nicht brauchen. LLMs haben in ihren Trainingsdaten enorme Mengen an CLI-Syntax gesehen – git, curl, kubectl, aws, gh –, wodurch sich CLI-Befehle für das Modell natürlich anfühlen. Pro Aufruf muss kein Schema geladen werden. Das Modell weiß bereits, was git status zurückgibt und was aws s3 cp erwartet.

Das ist die Dynamik eines „Muttersprachlers für CLI“. CLI-basierte Agenten können sich bei Shell-Interaktionen auf den vorhandenen Wortschatz des Modells verlassen, weshalb sich CLI in der Praxis schlanker anfühlt. Die Vorteile von CLI im Agentenkontext ergeben sich teils aus dem Infrastrukturdesign und teils aus den Trainingsdaten – das Modell beherrscht es bereits vor dem ersten Aufruf.

📊 Die Zahlen:
Bei 75 Benchmark-Durchläufen zum Vergleich von CLI und MCP für agentenbasierte Automatisierungsaufgaben erreichten CLI-basierte Agenten in bestimmten Workflows 100 % Aufgabenabschluss, während MCP-basierte Agenten bei 72 % lagen – bei einem Unterschied der Token-Kosten um den Faktor 4 bis 32. Das sind keine festen Werte: Bei Aufgaben mit strukturierten Daten wird der Abstand kleiner, wenn der direkte API-Zugriff von MCP nachgelagerten Parsing-Aufwand reduziert. Als praktischer Ausgangspunkt sollten Sie jedoch davon ausgehen, dass CLI günstiger ist, bis Ihr Workflow das Gegenteil beweist.

Das Problem mit MCP, über das in der Produktion niemand spricht

Token-Kosten sind das sichtbare Argument gegen MCP. Das Produktionsargument ist unübersichtlicher und wird seltener diskutiert.

Das Argument gegen MCP in der Produktion ist nicht philosophisch, sondern operativ. Jeder MCP-Server kann ein Deployment-Artefakt darstellen, das versioniert, überwacht und aktualisiert werden muss, wenn sich Tool-Funktionen ändern. Viele MCP-Implementierungen, die im Staging funktionieren, brechen nach dem ersten Schema-Update stillschweigend, weil der Agent eine Tool-Definition aufruft, die nicht mehr zu dem passt, was der Server tatsächlich tut. Der Agent weiß das nicht. Im Ausführungsprotokoll sieht nichts falsch aus, bis Sie einen nachgelagerten Fehler zu einem veralteten Tool-Aufruf zurückverfolgen.

Ich sehe dieses Muster ständig im Support: Teams richten einen MCP-Server ein, er funktioniert, sie bauen Workflows darauf auf, und drei Monate später aktualisiert jemand ein Tool, woraufhin der nachgelagerte Agent nur noch Unsinn produziert. Der MCP-Server kann dabei einwandfrei laufen. Das von ihm bereitgestellte Schema ist lediglich nicht mehr mit dem tatsächlichen Verhalten des zugrunde liegenden Services synchronisiert.

Auch die Iterationsgeschwindigkeit für Entwickler ist mit MCP geringer. Ein CLI-Skript zu ändern dauert Sekunden. Ein MCP-Schema zu ändern, den Server neu bereitzustellen und die Agenteninteraktion erneut zu testen, dauert deutlich länger – und diese Reibung summiert sich in einem Team, das schnell iteriert.

Wenn das MCP-Server-Setup zum Engpass wird

Jeder MCP-Server, den Sie bereitstellen, ist Infrastruktur, für die Sie nun verantwortlich sind: Transportkonfiguration, Authentifizierung, Observability, Updates. CLI vermeidet all das – Sie kapseln einen bereits vorhandenen Befehl und führen ihn in einem Kontext aus, den Sie bereits kontrollieren.

Die Reibung bei Produktions-Deployments ist real genug, dass die meisten MCP-Implementierungen ins Stocken geraten, bevor sie die Produktion erreichen. Teams entdecken die Einrichtungskosten nicht während der Planung, sondern nachdem das erste Schema-Update um 2 Uhr morgens einen nachgelagerten Agentenaufruf bricht. Dann wird die Entscheidung „Wir betreiben dafür einfach einen MCP-Server“ erneut hinterfragt.

Remote-Bereitstellungen von MCP-Servern fügen eine weitere Ebene hinzu: Netzwerkzuverlässigkeit, Endpunktsicherheit und die Frage, wer ihn wartet, wenn die Person, die ihn gebaut hat, im Urlaub ist. CLI stellt diese Fragen nicht. Es läuft dort, wo der Agent läuft.

Tool-Explosion und Schema-Drift mit MCP

Eine neue Fähigkeit zu einem CLI-Agenten hinzuzufügen bedeutet, einen Befehl hinzuzufügen. Sie zu einem MCP-Tool-Register hinzuzufügen bedeutet, eine Schema-Definition zu ergänzen, die Dokumentation zu aktualisieren, neu bereitzustellen und zu prüfen, dass sich das bestehende Verhalten des Agenten nicht verändert hat, weil das neue Tool die Tool-Liste beeinflusst, die der Agent beim Laden sieht.

Mehrere MCP-Server verschärfen dies. Drei MCP-Server mit überlappenden Tool-Namespaces sind das Kompositionsproblem, vor dem Sie niemand warnt, bevor Sie mittendrin stecken. Der Agent beginnt mehrdeutige Tool-Auswahlen zu treffen, weil ähnliche Tools auf unterschiedlichen Servern existieren. Schema-Drift – wenn die Tool-Definition im Lauf der Zeit vom tatsächlichen Verhalten abweicht – wird schwieriger zu erkennen und schwieriger zu beheben, ohne abhängige Workflows zu beeinträchtigen.

Das ist keine theoretische Sorge. Dort beginnen die meisten Tickets mit dem Thema „Unser MCP-Setup ist kompliziert geworden“.

Nutzen Sie CLI, wenn Ihr Agenten-Workflow so aussieht

CLI gewinnt in bestimmten, klar erkennbaren Fällen. Wenn Ihr Workflow zu einem dieser Muster passt, beginnen Sie mit CLI und fügen Sie MCP erst hinzu, wenn Sie tatsächlich an dessen Grenzen stoßen.

• Datei- und Verzeichnisoperationen in einer kontrollierten Umgebung

  Dateien in einem lokalen oder verwalteten Serverkontext zu lesen, zu schreiben, zu verschieben und umzuwandeln, ist genau das, wofür CLI konzipiert wurde. Die Shell erledigt das seit Jahrzehnten zuverlässig. Ein Agent, der find, grep, awk oder Python-Skripte über CLI kapselt, gibt Ihnen sofortigen Zugriff auf eine ausgereifte, praxiserprobte Toolchain – ohne Schema-Overhead.

• Git-Workflows und Repository-Verwaltung

  Wenn Ihr Agent Commits erstellt, Branch-Operationen ausführt oder Merges vorbereitet, bieten GitHub CLI (gh) und natives git direkten Shell-Zugriff auf den vollständigen Befehlssatz mit vorhersehbarem Verhalten. Ein Agent, der gh pr create und git log --oneline ausführen kann, benötigt für Einzel-Repository-Operationen keine MCP-Schicht.

• Cloud-Management-Aufgaben über CLI

  AWS CLI, gcloud, kubectl, az – all diese Tools bieten leistungsstarke, gut dokumentierte Befehlsoberflächen, die LLMs nativ kennen. Ein Agent, der Cloud-Ressourcen in einer kontrollierten Pipeline über CLI-Zugriff auf diese Tools verwaltet, ist schneller und günstiger, als dieselben Operationen über einen MCP-Server zu leiten, der dieselben API-Aufrufe kapselt.

• Sequenzielle DevOps-Aufgaben mit klaren Erfolgs- oder Fehlerergebnissen

  Build-Pipelines, Deployment-Skripte, Health Checks, Log-Tailing – all das ist CLI-nativ. Das Argument für CLI lautet hier: Die Toolchain ist bereits vorhanden, die Befehle sind gut verstanden und die Ausgabe (Exit-Codes, stdout, stderr) kann von jedem Agenten geparst werden, der auf Shell-Interaktionen trainiert wurde. CLI eignet sich hervorragend für Aufgaben, bei denen die Frage lautet: „War es erfolgreich oder ist es fehlgeschlagen?“, statt: „Welche strukturierten Daten soll dies zurückgeben?“

• Schnelle Iteration, bei der die Developer Experience wichtiger ist als die Komplexität der Authentifizierung

  CLI bietet Ihnen den schnellsten Weg von „Ich möchte, dass der Agent X tut“ zu „Der Agent tut X“. Wenn Sie Prototypen entwickeln, experimentieren oder interne Tools für ein einzelnes Team auf einem kontrollierten Server bauen, erzeugt der Overhead eines MCP-Setups Reibung, ohne Mehrwert zu schaffen.

Konkretes Beispiel: Ein Staff Engineer in einem mittelgroßen SaaS-Unternehmen benötigt einen Agenten, der jeden Morgen Datenqualitätsprüfungen ausführt, stdout erfasst und eine Zusammenfassung in einfacher Sprache in Slack veröffentlicht. Die Prüfungen existieren bereits als CLI-Skripte. Der Agent ruft sie über einen JavaScript-Node auf, erfasst die Ausgabe, übergibt sie an ein KI-Modell zur Interpretation in einfacher Sprache und veröffentlicht das Ergebnis. Kein MCP-Server. Kein Schema. Die gesamte Einrichtung dauert weniger als eine Stunde. Im Abrechnungsmodell von Latenode pro Ausführung zählt dieser mehrstufige Ablauf – Daten abrufen, CLI ausführen, KI-Modell aufrufen, in Slack posten – als eine Ausführung statt als vier separate Tasks. Der CLI-Agent übernimmt die Hauptarbeit, der Workflow die Koordination.

Nutzen Sie MCP, wenn der Workflow mehr als Shell-Zugriff benötigt

MCP wurde für Fälle entwickelt, in denen das Shell-basierte Modell von CLI nicht ausreicht. Das sind zugleich die Fälle, in denen sich der Einrichtungsaufwand auszahlt.

• Mehrmandantenumgebungen, in denen Nutzer begrenzten Tool-Zugriff benötigen

  MCP gewinnt, wenn Ihr Agent im Namen unterschiedlicher Nutzer mit verschiedenen Berechtigungsgrenzen handeln muss. CLI übernimmt die Zugangsdaten der Shell – alle erhalten denselben Zugriff. MCP löst das Delegierungsproblem nativ durch zentrale Authentifizierung, die Berechtigungen pro Tool und Nutzer begrenzen kann.

• Serviceübergreifende Workflows mit Anforderungen an strukturierte Metadaten

  Wenn der Agent Aktionen über Jira, MCP-kompatible Atlassian-Services, ein CRM und eine Datenbank hinweg koordinieren muss – und die nachgelagerte Verarbeitung von strukturierten JSON-Antworten jedes Systems abhängt –, spielt MCP seine Stärken aus. Freiform-CLI-Ausgaben erfordern Parsing-Logik, die bei jeder Änderung des Ausgabeformats brechen kann. Die strukturierten Antworten von MCP sind vertraglich stabil.

• Organisationsweite Tool-Erkennung über Teams hinweg

  Wenn ein Agent Tools erkennen und aufrufen soll, für die er nicht vorprogrammiert wurde – weil unterschiedliche Teams unterschiedliche Services besitzen und Sie eine einheitliche Oberfläche wünschen –, wurde MCP genau dafür entwickelt. Ein gemeinsames MCP-Gateway ermöglicht Agenten, von anderen Teams veröffentlichte Tools zu finden und zu nutzen, ohne jede Integration fest zu codieren.

• GitHub MCP, Jira MCP und ähnliche First-Party-Integrationen, bei denen umfangreiche Metadaten wichtig sind

  Der GitHub MCP-Server ermöglicht Agenten Zugriff auf Issue-Listen, Pull Requests und Branch-Operationen mit OAuth-basierter Authentifizierung und strukturierten API-Antworten. Für Workflows, in denen der Agent PR-Daten mit Code-Review-Kontext und nachgelagertem CI-Status korrelieren muss, ist das strukturierte Antwortformat die zusätzliche Komplexität gegenüber reinem GitHub CLI wert. Nutzen Sie MCP, wenn die Datenstruktur ebenso wichtig ist wie die Aktion.

• Situationen, in denen Sie konsistentes Tool-Verhalten über mehrere Clients oder Codebases hinweg benötigen

  Wenn mehrere Agenten in unterschiedlichen Kontexten denselben Service auf dieselbe Weise aufrufen müssen, erzwingt der schema-basierte Vertrag von MCP diese Konsistenz. CLI überlässt Konsistenz Konventionen. Konventionen driften. Schemas lassen sich nicht so leicht versehentlich beschädigen.

Wie Agenten CLI und MCP gemeinsam nutzen, ohne eines von beiden zu beeinträchtigen

Die Einordnung, die diese Entscheidung klarer macht: Behandeln Sie CLI und MCP als Portfolio, nicht als binäre Entscheidung. Das Ökosystem für KI-Agenten entwickelt sich in Richtung Architekturen, in denen beide im selben Workflow bestehen – nicht weil Teams sich nicht entscheiden konnten, sondern weil die beiden Protokolle tatsächlich unterschiedliche Probleme in unterschiedlichen Umfängen lösen.

Praktiker, die lange genug damit gearbeitet haben, hören auf, darüber zu streiten, welches der beiden besser ist. Sie fragen stattdessen: „Welche Art von Aufgabe ist das?“ und leiten entsprechend weiter. KI-Systeme mit Tools zu verbinden, erfordert keinen einzigen Standard. Es erfordert den passenden Standard für den passenden Interaktionstyp.

CLI für die innere Schleife, MCP für die äußere Schleife

Die innere Schleife ist der Bereich, in dem der Agent eng getaktete Iterationen ausführt: Dateiänderungen, Shell-Befehle, lokale Statusmanipulationen, schneller Austausch mit der lokalen Umgebung. Hier dominieren CLI-Aufrufe. Sie sind schnell, token-effizient und das Modell kennt den Befehlswortschatz bereits. Aufgaben, die CLI in der inneren Schleife erledigt, benötigen selten strukturierte Authentifizierung – der Agent arbeitet in einem bereits festgelegten Berechtigungskontext.

Die äußere Schleife ist der Bereich, in dem der MCP-Agent nach außen greift: zur Authentifizierung bei externen Services, zum Aufrufen von APIs mit begrenzten Berechtigungen und zur Rückgabe strukturierter Daten an nachgelagerte Prozesse. Hintergrundagenten, die serviceübergreifend orchestrieren, Mehrnutzerberechtigungen verwalten oder konsistente Tool-Schnittstellen in einer Organisation aufrechterhalten müssen, gehören hierher. Der Einsatz von CLI in diesem Umfang stößt schnell an die Grenze der Shell-Berechtigungen – Sie können begrenzte Zugangsdaten nicht über einen Shell-Befehl delegieren, wie MCP dies nativ ermöglicht.

Die Kombination ist praktisch, nicht theoretisch. Ein Agent, der Code baut und testet, verwendet intern CLI. Wenn er im Namen eines bestimmten Nutzers einen PR öffnen oder strukturierte Metadaten zurück nach Jira schreiben muss, überschreitet er die MCP-Grenze.

Wann direkte APIs die bessere dritte Option sind

Hier ist der Teil, den die MCP-vs.-CLI-Debatte meist auslässt: Für stabile, produktionsreife Integrationen, bei denen Zuverlässigkeit und Latenz die wichtigsten Anforderungen sind, sind weder MCP noch CLI die richtige Antwort. Direkte HTTP-API-Aufrufe über ein Sprach-SDK sind es.

Eine agentenvermittelte Schnittstelle – CLI oder MCP – zu einem stabilen Stripe-Webhook-Handler, einer gut getesteten Salesforce-Synchronisierung oder einem Produktivprozess zur Zahlungsabwicklung hinzuzufügen, führt unnötige Fragilität ein. Agenten benötigen weiterhin Override-Pfade und Ausweichmöglichkeiten zu direkten APIs für alles, bei dem die Folgen eines Parsing-Fehlers oder eines verpassten Tool-Aufrufs relevant sind. Das MCP-Ökosystem ist gereift, aber Reife bedeutet nicht, dass es überall eingesetzt werden sollte.

Wenn die eigentliche Frage lautet: „Wie mache ich diese Integration zuverlässig?“, lautet die Antwort oft weder MCP noch CLI.

🤔 Denken Sie darüber nach:
Die meisten Gespräche über „MCP vs. CLI“ stellen eigentlich die falsche Frage. Die zugrunde liegende Frage lautet: Benötigt dieser Workflow überhaupt eine agentenvermittelte Schnittstelle? Bei produktionsreifen SaaS-Integrationen, bei denen Zuverlässigkeit wichtiger ist als Flexibilität, sind direkte HTTP-APIs und Sprach-SDKs die besser vertretbare Wahl. Bauen Sie die Agentenschicht auf eine stabile Integration – nicht anstelle einer solchen.

So entscheiden Sie zwischen MCP und CLI für Ihren konkreten Agentenaufbau

Bevor Sie sich auf eine Architektur festlegen, prüfen Sie diese Punkte. Sie sind danach geordnet, wie häufig sie tatsächlich entscheidend sind.

Die Entscheidung für KI-Tools hängt auch von der Wartungskapazität ab. Die besten CLI-Schnittstellen verschlechtern sich kontrolliert, wenn sich Befehlsausgabeformate ändern – sofern die Parsing-Logik aktualisiert wird. Die besten MCP-Spezifikationsimplementierungen erzwingen Schema-Verträge, die Drift erkennen, bevor sie den Agenten erreicht. Keiner der beiden Ansätze wartet sich selbst. Wählen Sie den, den Ihr Team tatsächlich aktuell halten kann.

Wenn Sie auf Latenode entwickeln, ermöglicht der JavaScript-Node Agenten, CLI-Tools direkt auf dem Canvas aufzurufen, während der MCP Server Builder die Fälle abdeckt, in denen Sie Funktionen mit strukturierter Authentifizierung für Claude Desktop oder Cursor bereitstellen müssen. Diese Kombination deckt sowohl CLI- als auch MCP-vermittelte Workflows aus einer Umgebung ab, was wichtig ist, wenn sich die Architektur weiterentwickelt. Lassen Sie Agenten beide Wege nutzen, ohne bei veränderten Anforderungen alles von Grund auf neu bauen zu müssen. Auch das Abrechnungsmodell pro Ausführung hilft: Ein Workflow, der CLI-Ausführung, KI-Interpretation und durch MCP abgesicherte externe Aufrufe umfasst, zählt als eine Ausführung und nicht als fünf separate CLI-Schnittstellen.

Die Fragen, die Sie vor der Wahl eines MCP-Ansatzes stellen sollten

Beantworten Sie diese Fragen ehrlich, bevor Sie standardmäßig MCP wählen:

• Benötigen Sie tatsächlich serviceübergreifende Tool-Erkennung, oder wissen Sie genau, welche Tools der Agent aufrufen wird?
• Benötigen Sie delegierte, begrenzte Authentifizierung über mehrere Nutzer hinweg – oder deckt ein einzelner Satz Zugangsdaten Ihren Workflow ab?
• Hat Ihr Team die Kapazität, ein Schema-Register zu warten, während sich Tools weiterentwickeln, oder wird MCP für alles zu einem Wartungsrückstand?
• Gibt es bereits einen MCP-Client in Ihrem Stack, der MCP sinnvoll und naheliegend macht, oder führen Sie Client und Server gleichzeitig als neue Infrastruktur ein?
• Könnte CLI für alles Sie mit einem einfacheren Wartungsweg zum selben Ergebnis führen, zumindest in den ersten sechs Monaten?
• Greifen Sie zu MCP, weil es ein tatsächliches Problem löst, oder weil es robuster klingt? MCP zu unterstützen ist nicht dasselbe wie MCP zu benötigen.

Wenn Sie die ersten beiden Fragen nicht mit Ja beantworten können, beginnen Sie mit CLI. Sie können MCP später ergänzen, wenn das Koordinationsproblem real ist. Es ist deutlich schwieriger, eine MCP-Architektur wieder aufzulösen, wenn Sie feststellen, dass sie hinzugefügt wurde, bevor der Anwendungsfall überhaupt existierte.