MCP Server oder CLI: Welche Schnittstelle passt?

MCP Server oder CLI: Wann passt welche Lösung?

Für die Entwicklungsarbeit in einem Repository ist die CLI der Ausgangspunkt. Eine Kommandozeilenschnittstelle ist ein Programm, das sich über Befehle bedienen lässt. Hat der Agent bereits eine freigegebene Umgebung zur Befehlsausführung und deckt das Tool die Aufgabe ab, kann eine weitere Integration zusätzlichen Wartungsaufwand verursachen, ohne das Ergebnis zu verbessern.

Für einen gehosteten Assistenten mit unterschiedlichen Nutzern ist ein MCP-Dienst mit begrenzten Berechtigungen einer gemeinsam genutzten Shell mit weitreichenden Rechten vorzuziehen. Model Context Protocol ist ein Standard, über den eine KI-Anwendung Tools findet und aufruft. Ein entfernter Server kann die Autorisierung jedes Nutzers entgegennehmen und die benötigten Operationen bereitstellen. Die Berechtigungen müssen dennoch durchgesetzt werden.

In einem Entwicklungsteam können beide Ansätze unterschiedliche Aufgaben übernehmen. Die Arbeit am Repository bleibt in der Befehlsumgebung. Gemeinsame Geschäftsprozesse gehören hinter einen Dienst, der Identität und Befugnisse des Aufrufenden prüft.

Den Ausschlag geben der Zugriff auf die Laufzeitumgebung, die Zuordnung der Zugangsdaten, die verfügbaren Operationen und die Informationsmenge, die das Modell erhält. Der Protokollname ist nachrangig.

Die Herstellerdokumentation für diesen Vergleich wurde am 11. November 2026 überprüft. Grundlage sind dokumentierte Abläufe und architektonische Einschätzungen, kein Benchmark und kein behaupteter Praxistest.

CLI und MCP: Wie gelangen Aufrufe zum Modell?

MCP liefert dem Agenten eine Tool-Beschreibung, eine CLI einen ausführbaren Befehl. Das Modell führt in beiden Fällen selbst keine Operation aus. Die umgebende Anwendung nimmt den vorgeschlagenen Aufruf entgegen, wendet ihre Kontrollen an, führt ihn aus und gibt das Ergebnis zurück.

Bei MCP fragt der Client die verfügbaren Tools beim Server ab. Jedes Tool beschreibt seinen Namen, seinen Zweck und sein Eingabeschema, also die akzeptierten Felder. Die Anwendung kann dem Modell diese Definitionen bereitstellen. Das Modell wählt ein Tool aus und übergibt strukturierte Argumente. Die MCP-Spezifikation für Tools legt Erkennung und Aufruf fest; wie die Interaktion mit dem Nutzer aussieht, entscheidet die Anwendung.

Bei einer CLI startet der Agent über ein Tool zur Befehlsausführung ein installiertes Programm. Gängige Befehle kennt er möglicherweise bereits. Mit --help kann er die Syntax des installierten Tools prüfen. Als Antwort sind Text, strukturiertes JSON oder ein Dateipfad möglich. „CLI-Ausgabe“ bedeutet also nicht automatisch „unstrukturierter Text“.

Aus „Meine offenen Pull Requests auflisten“ kann beispielsweise ein GitHub-Tool-Aufruf mit Argumenten oder ein Befehl wie gh pr list werden. Das verwendete Konto benötigt weiterhin die Berechtigung, diese Pull Requests zu lesen. Eine andere Schnittstelle schafft keine Zugriffsrechte.

Mehr zur übergeordneten Rolle des Protokolls erläutert der Beitrag Was ist MCP?.

Kontextverbrauch: Bei einfachen lokalen Aufgaben liegt die CLI vorn

Eine CLI kann irrelevante Tool-Details aus dem Modellkontext heraushalten. Kontextverbrauch verschwindet dadurch aber nicht. Zum Kontext gehören die Informationen, die das Modell bei der Entscheidung über den nächsten Schritt erhält. Tool-Beschreibungen und Parameterschemas belegen Tokens, sobald die Host-Anwendung sie einbindet – ebenso wie Hilfetexte und Befehlsausgaben.

Ein MCP-Server mit umfangreichem Tool-Angebot kann deshalb bereits viel Kontext beanspruchen, bevor die eigentliche Arbeit beginnt. Entscheidend ist dabei, wann die Host-Anwendung dieses Angebot einbindet. Nicht jede Anwendung lädt sämtliche verfügbaren Definitionen in jede Modellanfrage. Eine kleinere Tool-Auswahl oder das Ermitteln von Tools bei Bedarf verändert den Vergleich.

Beim CLI-Ansatz kann zunächst die Definition des Tools zur Befehlsausführung genügen. Die Hilfe für einzelne Programme kommt erst bei Bedarf hinzu. Außerdem lassen sich Daten filtern, bevor sie das Modell erreichen. Nur Titel und URLs von Pull Requests anzufordern ist sinnvoller, als vollständige Datensätze zurückzugeben, von denen das Modell den Großteil ignorieren soll.

Eine CLI mit riesigen Protokollausgaben oder ein Skill, der ein langes Handbuch lädt, kann diesen Vorteil allerdings aufheben. Umgekehrt kann ein MCP-Tool mit einer knappen Antwort effizienter sein als wiederholte Erkundung in der Shell. Gemessen werden sollte die gesamte Aufgabe: Definitionen, Hilfetexte, Ausgaben, Wiederholungen und die Korrektheit des Ergebnisses. Ein kurzer Befehl allein sagt wenig aus.

Empfehlung in dieser Kategorie: CLI für lokale Routineaufgaben mit gezielt begrenzter Ausgabe. MCP bleibt konkurrenzfähig, wenn Tool-Auswahl und Ergebnisse schlank bleiben. Ein allgemeingültiger Token-Multiplikator lässt sich daraus nicht ableiten.

Authentifizierung und Rechte: MCP überzeugt, wenn der Dienst die Grenze durchsetzt

Die Autorisierung pro Nutzer ist wichtiger als die Frage, ob der Agent JSON oder eine Befehlszeichenfolge sendet. OAuth ist ein delegierter Anmeldeablauf: Ein Nutzer autorisiert einen Client, ohne ihm sein Passwort zu überlassen. Ein entfernter MCP-Dienst kann anhand dieser Identität entscheiden, auf welche Konten, Datensätze und Aktionen der Client zugreifen darf.

Ein Support-Assistent für unterschiedliche Kundenorganisationen sollte beispielsweise die Datensätze des angemeldeten Kunden abrufen, ohne die Zugangsdaten eines Entwicklers zu erhalten, die sämtliche Konten lesbar machen. Zwischen einem korrekt begrenzten entfernten MCP-Dienst und einer gemeinsam genutzten Administrator-Shell fällt die Wahl auf den Dienst. In diesem Fall kann MCP unter diesen beiden Implementierungen die einzig vertretbare Option sein.

Andere sichere Architekturen sind ebenfalls möglich. Eine direkte API-Integration kann dieselbe Grenze durchsetzen. MCP allein schafft sie auch nicht automatisch: Die MCP-Autorisierungsspezifikation macht Autorisierung optional, definiert den HTTP-Autorisierungsablauf und grenzt lokale STDIO-Server ab, die Zugangsdaten aus ihrer Umgebung beziehen.

Auch eine CLI kann Browser-Anmeldung und eingeschränkte Zugangsdaten verwenden. Das Risiko ergibt sich aus den Zugriffsmöglichkeiten ihres Prozesses: Zugangsdaten, Dateien, Netzwerkziele und andere ausführbare Programme. Eine abgeschottete Befehlsumgebung mit eng begrenzten Zugangsdaten ist anders zu beurteilen als uneingeschränkter Zugriff auf einen Entwicklerrechner.

Empfehlung in dieser Kategorie: entferntes MCP mit begrenzten Rechten für delegierten Zugriff unterschiedlicher Nutzer. Bei beiden Ansätzen müssen Konto- und Objektberechtigungen im Code durchgesetzt, Zugangsdaten aus modellseitig sichtbaren Ausgaben herausgehalten und die Autorisierung jeder Aktion einem Nutzer zugeordnet protokolliert werden.

GitHub CLI oder GitHub MCP: Repository-Arbeit oder gemeinsamer Dienstzugriff?

GitHub CLI, der Kommandozeilenclient gh, ist die naheliegende Wahl für einen Coding-Agenten, der bereits in einem ausgecheckten Repository arbeitet. Für eine Übersicht der eigenen offenen Pull Requests lassen sich nach der Anmeldung innerhalb des Repositorys diese dokumentierten Optionen verwenden:

gh pr list --author "@me" --json number,title,url

Der Befehl fordert nur die für die Übersicht benötigten Felder an. Die CLI unterstützt außerdem --jq, um JSON zu filtern, bevor es das Modell erreicht. Das ist eine konkrete Möglichkeit, Kontext zu sparen, ohne damit einen Token-Benchmark zu behaupten.

Die Grenzen der CLI setzt ihre Ausführungsumgebung. Ein Befehl, der auf dem eigenen Laptop funktioniert, ist damit noch keine geeignete Schnittstelle für alle Beschäftigten oder Kunden. Laut GitHub-CLI-Anmeldehandbuch speichert die Browser-Anmeldung einen Token normalerweise im Zugangsdaten-Speicher des Systems. Ist dieser nicht verfügbar, kann stattdessen Klartextspeicherung zum Einsatz kommen. Entscheidend ist die tatsächliche Ablage der Zugangsdaten; „lokal“ bedeutet nicht automatisch „isoliert“.

GitHub MCP Server, GitHubs offizieller Tool-Server, eignet sich für einen Assistenten, der Repository-Operationen über MCP benötigt. Für dieselbe Übersicht werden die passenden Pull-Request-Tools bereitgestellt, die Autorisierung des vorgesehenen Nutzers verwendet und dessen offene Anfragen abgefragt. GitHub betreibt einen entfernten Server und bietet auch eine lokale Variante an.

GitHub dokumentiert Toolsets, die Auswahl einzelner Tools und einen schreibgeschützten Modus, der Schreib-Tools auslässt. Die OAuth-Unterstützung des entfernten Servers setzt außerdem voraus, dass die Host-Anwendung die passende GitHub- oder OAuth-App konfiguriert. Ein kompatibler Transport allein klärt die Authentifizierung nicht.

Fazit dieses Vergleichs: gh für die persönliche Entwicklerübersicht und Repository-Skripte. MCP ist für einen gemeinsam genutzten Assistenten vorzuziehen, dessen Client den erforderlichen Authentifizierungsablauf unterstützt. Beide Varianten benötigen weiterhin Repository-Berechtigungen. Eine kleinere MCP-Tool-Auswahl kann sowohl die Übersichtlichkeit als auch den Kontextverbrauch verbessern.

Playwright CLI oder MCP: Coding-Aufgaben oder erkundende Browserabläufe?

Playwright CLI, Microsofts Befehlsschnittstelle für Browseraktionen, ist die erste Wahl für einen Coding-Agenten, der eine Webänderung prüft. Die Entwickler empfehlen CLI plus Skills für Coding-Agenten, weil sich mit Befehlen das Laden umfangreicher Schemas und Seitendaten in den Kontext vermeiden lässt. Das ist ihre Entwurfsempfehlung, keine in diesem Artikel gemessene Geschwindigkeitsaussage.

Bei der Prüfung eines Formulars besteht der Ablauf darin, die Seite zu öffnen, relevante Elemente zu untersuchen, mit ihnen zu interagieren und das Ergebnis zu prüfen. Dafür muss der Agent nicht nach jeder Aktion sämtliche Seitendetails lesen.

playwright-cli install: Mit den dokumentierten Herstellerbefehlen beginnen

Die dokumentierte Installation und eine rein lesende Seitenprüfung sehen so aus:

npm install -g @playwright/cli@latest
playwright-cli --help
playwright-cli open https://playwright.dev
playwright-cli snapshot
playwright-cli close

Diese Befehle untersuchen eine öffentliche Seite; sie bilden keine Testsuite. Der erzeugte Snapshot dient dazu, Ziele zu identifizieren, bevor Interaktionen mit der eigenen Anwendung ergänzt werden.

Playwright-CLI-Skill: Anweisungen für den Ablauf ergänzen

Nach der CLI-Installation lautet der dokumentierte Befehl für Skills:

playwright-cli install --skills

Die wesentliche Einschränkung betrifft das notwendige Umfeld: eine ausführbare Umgebung, eine geeignete Browsersitzung und Anweisungen, die den Erfolg definieren. Ein Skill unterstützt das Vorgehen. Ob eine echte Kundentransaktion autorisiert ist, kann er nicht entscheiden.

Playwright MCP, Microsofts Browser-Tool-Server, passt besser, wenn ein MCP-Client bei einem erkundenden Ablauf von strukturierten Seiteninformationen profitiert. Für die Browserinteraktion verwendet er Accessibility-Snapshots, also strukturierte Beschreibungen der Seitenelemente.

Dabei sind zwei Grenzen wichtig. Erstens ist dauerhafter Browserzustand kein Alleinstellungsmerkmal von MCP: Playwright CLI bewahrt Cookies und Speicher zwischen Aufrufen innerhalb einer Sitzung auf und bietet persistente Profile über Browserneustarts hinweg. Zweitens weist das MCP-Repository ausdrücklich darauf hin, dass der Server keine Sicherheitsgrenze bildet. Auch die Hinweise zu seinen Origin-Kontrollen warnen, dass diese weder eine solche Grenze schaffen noch Weiterleitungen beeinflussen.

Fazit dieses Vergleichs: CLI plus Skills für Routineprüfungen im Coding-Workflow; MCP für Clients und Aufgaben, die von der Interaktion über seine Browser-Tools profitieren. Allein für den Sitzungszustand lohnt sich kein Wechsel. Der Leitfaden zur Einrichtung von Playwright MCP und zu Browsertests behandelt diesen Ansatz ausführlicher.

Stripe CLI oder Stripe MCP: Webhook-Entwicklung oder Kontoverwaltung?

Stripe CLI, Stripes Terminal-Tool, liegt bei Entwicklung und Fehlersuche rund um eine Zahlungsintegration vorn. Eine typische Aufgabe ist der Empfang von Webhook-Ereignissen in einer lokal laufenden Anwendung – Benachrichtigungen, die Stripe bei bestimmten Vorgängen sendet. Die CLI dokumentiert stripe listen zum Empfangen und Weiterleiten dieser Ereignisse sowie stripe trigger zum Erzeugen von Beispielereignissen.

Dieser Ablauf gehört in eine Sandbox. Das Auslösen von Ereignissen erstellt API-Objekte und kann weitere Ereignisse erzeugen; es gibt nicht bloß eine beispielhafte Nutzlast aus. Die CLI unterstützt außerdem API-Operationen und die Einsicht in Anfrageprotokolle. Ihr Nutzen geht also über die Webhook-Weiterleitung hinaus.

Bei der Authentifizierung greift die Gleichsetzung „CLI bedeutet kopierter API-Schlüssel“ zu kurz. Stripe dokumentiert Browser-Anmeldung pro Nutzer, lokale sichere Zugangsdaten-Speicherung, soweit verfügbar, sowie Sitzungserneuerung und Widerruf. Für Entwickler kann das passen. Bei einem gehosteten Assistenten braucht der CLI-Ansatz dennoch eine Möglichkeit, Laufzeitumgebung und Zugangsdaten jedes Nutzers zu isolieren.

Stripe MCP, Stripes Dienstschnittstelle für Agenten, eignet sich besser für Kontooperationen aus einem kompatiblen Assistenten ohne lokale Befehlsumgebung. Eine autorisierte Person kann den Assistenten beispielsweise auffordern, relevante Stripe-API-Daten zu finden und zu lesen. Der Server stellt Tools für API-Suche, Parameterermittlung sowie Lese- und Schreibzugriffe bereit. Eine eigene Tool-Definition für jede Operation ist damit nicht erforderlich.

Stripe unterstützt OAuth für Zugriffe im Namen eines Nutzers und Agenten-API-Schlüssel für unabhängigen Zugriff. Das allgemeine Tool stripe_api_write kann zahlreiche Operationen abdecken. Stripes Anforderungen an eine menschliche Bestätigung hängen von der Aktion ab und gelten unabhängig von der clientseitigen Tool-Freigabe. Die Freigabe einer Tool-Kategorie ist daher nicht gleichbedeutend mit der Genehmigung jeder Geschäftsaktion, die sie ermöglicht.

Fazit dieses Vergleichs: CLI für lokale Webhook-Entwicklung; MCP für delegierte Kontoarbeit in einem Assistenten. Maßgeblich ist die benötigte Operation, nicht die Anzahl der Befehle oder Tools. Eine MCP-Verbindung, die Kontodaten liest, ersetzt keinen lokalen Webhook-Listener im Entwicklungsablauf.

MCP vs Skills: Anweisungen liegen auf einer anderen Ebene

Ein Skill beschreibt, wie der Agent arbeiten soll; MCP und CLI ermöglichen ihm zu handeln. Im Agent-Skills-Format enthält eine Datei namens SKILL.md einen Namen, eine Beschreibung und Aufgabenanweisungen, optional ergänzt durch Skripte und Referenzdateien. Agenten ermitteln zunächst die Metadaten und laden ausführlichere Anweisungen bei Bedarf.

Beim Vergleich „MCP vs CLI vs Skills“ ist eine CLI mit einem Skill oft eine sinnvolle Kombination. Die CLI führt die Operation aus. Der Skill legt fest, welche Befehle und welche Umgebung zu verwenden sind, welche Belege geprüft werden und wann Schluss ist. Ein Skill kann genauso einen Agenten anleiten, der MCP-Tools verwendet.

Für eine Pull-Request-Übersicht könnte ein Skill ausschließlich offene Anfragen vorgeben, knappe Felder auswählen und das Veröffentlichen von Kommentaren während der Berichterstellung untersagen. Die tatsächliche Zugriffsgrenze müssen Zugangsdaten und Laufzeitumgebung durchsetzen. Schriftliche Anweisungen unterstützen korrektes Verhalten; sie entziehen keine Berechtigungen.

Empfehlung in dieser Kategorie: Skills für wiederholbare Abläufe. Sie ergänzen beide Schnittstellen und beanspruchen beim Laden selbst Kontext.

MCP vs API vs CLI: Die Dienstlogik zusammenhalten

Geschäftsregeln gehören in den Dienst; darüber werden die benötigten Schnittstellen bereitgestellt. Eine API ist die programmatisch nutzbare Schnittstelle einer Anwendung. Sowohl eine CLI als auch ein MCP-Server können sie aufrufen, wie Stripes Schnittstellen zeigen.

Wer beide pflegt, sollte Autorisierung und Validierung gemeinsam nutzen, statt konkurrierende Implementierungen für die Frage aufzubauen, wer einen Datensatz ändern darf. Der Vergleich MCP vs API erläutert, wann sich die zusätzliche Protokollschicht lohnt.

Eine Hülle, die beliebigen Shell-Text entgegennimmt, ist ein schwacher Grund für eine Migration. Sie macht möglicherweise eine bestehende Befehlsumgebung über MCP erreichbar, behält deren Befugnisse aber bei. Ein sinnvoller Adapter stellt eine begrenzte Operation bereit, validiert ihre Eingaben und liefert nur die Belege zurück, die der Agent benötigt.

Entscheidungstabelle: Die Einsatzumgebung gibt den Ausschlag

Die kleinste Schnittstelle wählen, die die Aufgabe abdeckt, ohne Befugnisse auszuweiten. Die folgenden Konfigurationen sind Ausgangspunkte, keine dauerhafte Bindung an einen Ansatz.

Von MCP zur CLI wechseln – oder zurück

Einzelne Arbeitsabläufe migrieren. Der aufwendige Teil besteht oft darin, Berechtigungen, Ausgaben und Fehlerbehandlung zu erhalten, weniger darin, einen Tool-Namen in einen Befehl zu übersetzen.

Der Wechsel zur CLI erfordert Installation, Zugangsdaten, eine Befehlsumgebung, Ausgabefilter und reproduzierbare Anweisungen. Für MCP müssen ein Server ausgewählt oder betrieben, die Client-Authentifizierung eingerichtet, die verfügbaren Tools definiert und Fehler über diese Schnittstelle behandelt werden. Bei Browserabläufen ist zusätzlich ausdrücklich zu klären, wem Sitzung und Profil zugeordnet sind.

Ein funktionierender CLI-Ablauf braucht keinen Wechsel allein für die Protokollunterstützung. Eine entfernte MCP-Integration, die Menschen ohne Shell bedient, sollte nicht bloß deshalb entfallen, weil ein Befehl kürzer aussieht.

Weitere Praxisleitfäden zur Auswahl und Begrenzung von Agentenabläufen gibt es im Newsletter.

Häufig gestellte Fragen