CLI und MCP lösen verschiedene Probleme
Ein gutes CLI lohnt sich — Auth, Listen, Pull, Push, Publish aus der Shell. Agenten, die Terminal-Befehle ausführen, profitieren direkt. Aber: Mit dem CLI kauft ihr Distribution ein: macOS, Linux, Windows, Node-Versionen, PATH, Shell-Quirks, Desktop-Clients ohne Shell.
MCP ist kein Ersatz für jedes CLI — es ist ein Protokoll. Die Frage verschiebt sich von „Kann der Nutzer unser Binary korrekt installieren?“ zu „Spricht der Client MCP?“ Das ist schmaler, standardisierter und altert besser.
Für DACH-Agenturen, die Kunden-CLIs oder Docs-Workflows bauen: CLI für Power-User behalten, MCP für breite Agent- und Desktop-Clients — siehe Remote MCP.
Was das CLI gut abdeckt — und wo es bricht
CLI glänzt bei technischen Nutzern in der Shell: Token-Auth, lokale Previews, explizite Befehle, Scripting. Terminal-native Agenten mappen das oft 1:1 auf run_terminal_cmd.
Brüche entstehen bei falscher npx-/Node-Auflösung, kaputtem PATH, unterschiedlichen Umgebungen pro Rechner — Packaging-Probleme, keine Docs-Probleme. Jede Plattform × Runtime × Client wird Support-Oberfläche.
„Technische User finden es schon raus“ skaliert nicht, wenn Produktmanager, Support-Leads oder Gründer Docs über Desktop-MCP pflegen sollen — ohne Terminal-Debug.
Was MCP verändert: eine Protokoll-Oberfläche
Remote MCP hält Business-Logik in eurer Infrastruktur — monitorbar, rate-limitierbar, versionierbar. Tools wie list_documentations, pull_documentation, publish_documentation hängen an einer authentifizierten URL statt an lokalen Binaries.
Auth explizit, Schemas explizit, Request/Response explizit. Onboarding kann Richtung OAuth gehen: Connector-URL, Sign-in, Consent — statt Token kopieren und mcp-remote-Bridges.
Grundlagen zum Protokoll: MCP für Docs und SaaS. Skills für Nutzungswissen: skill.md.
Ehrliche Einordnung: CLI behalten, MCP ergänzen
MCP ersetzt das CLI nicht. CLI bleibt für lokale Preview, Automation und Nutzer, die explizite Kommando-Kontrolle wollen. Unterschiedliche Distribution: CLI = Workflow lokal ausführen; MCP = stabile Oberfläche ohne eure Packaging-Story auf jedem Client.
Win für SaaS und Beratung: weniger Cross-OS-Binary-Overhead, weniger „works on my machine“, bessere Desktop-Client-Kompatibilität, niedrigere Schwelle für nicht-technische Rollen.
Formulierung für Angebote: Einmal verbinden, dauerhaft sprechen schlägt denselben Workflow als wachsenden Stapel Binaries.
Entscheidungshilfe für Agentur-Projekte
Nur internes Engineering-Tool, alle auf macOS mit gleichem Stack → CLI kann reichen. Ziel: Cursor, Claude, VS Code, gemischte OS, auch nicht-technische Redakteure → Remote MCP planen.
Roadmap: CLI-Prototyp für Tool-Kohärenz → gleiche Tools hinter Streamable HTTP → OAuth/Discovery — Reihenfolge aus Remote MCP Setup.
Discovery-Schicht parallel nicht vergessen: llms.txt und Content Negotiation für read-only Public Docs.
