Wann ein KI-Werkzeug-Steckplatz (MCP), wann eine Web-Schnittstelle (API), wann ein Kommandozeilen-Tool (CLI)?
Diese Seite vergleicht drei Arten, einen Dienst nach außen anzubieten. Sie schließen sich nicht aus, sie sind verschiedene Schnittstellen zur selben Funktion. Die Wahl hängt davon ab, wer durch die Tür kommt: ein KI-Assistent, ein anderer Server oder ein Mensch am Terminal.
Was die drei in einem Satz sind
| Tür | Kurzdefinition |
|---|---|
| KI-Werkzeug-Steckplatz (MCP, Model Context Protocol) | Ein KI-Assistent (z. B. Claude Code) startet das Programm und kann während des Gesprächs Werkzeuge daraus aufrufen. Das Programm beschreibt sich selbst, der Assistent sieht, was es kann. |
| Web-Schnittstelle (HTTP-API, oft als REST-API gebaut) | Ein dauerhaft laufender Server beantwortet Anfragen über das Web. Jeder, der die Adresse kennt und die Berechtigung hat, kann zugreifen, Browser, Handy-App, ein anderer Server. |
| Kommandozeilen-Tool (CLI, Command-Line Interface) | Ein Programm, das man im Terminal aufruft, Argumente übergibt und dessen Text-Ausgabe liest. Standard-Werkzeug auf Linux- und Mac-Systemen, gut mit anderen kombinierbar. |
Direktvergleich
Eine Zeile pro Vergleichs-Kriterium, drei Spalten, so steht alles nebeneinander.
| Vergleichs-Kriterium | MCP | HTTP-API | CLI |
|---|---|---|---|
| Wer ruft das auf? (Aufrufer-Typ) | Ein KI-Assistent (LLM-Agent) wie Claude Code, Codex, qwen-code | Browser-Frontend, Handy-App, anderer Server, Skript | Mensch am Terminal, Shell-Skript, CI-Pipeline |
| In welcher Form gehen Daten hin und zurück? (Wire-Format) | Strukturierte Nachrichten über die Standard-Ein-/Ausgabe (JSON-RPC via stdio) oder über Web (HTTP/SSE) | Strukturierte Daten über das Web (JSON über HTTP), oft im REST-Stil | Kommandozeilen-Argumente rein, Text raus, Fehler-Ausgabe und Erfolgs-Signal extra (argv, stdout, stderr, Exit-Code) |
| Wie erfährt der Aufrufer, was es überhaupt gibt? (Discovery) | Selbstauskunft: der Server liefert eine Liste aller Werkzeuge mitsamt Beschreibung und Eingabe-Bauplan (tools/list mit JSON-Schema) | Per externer Dokumentation, in der Regel eine Spec-Datei (OpenAPI / Swagger). Kein Laufzeit-Abfragen. | --help, Handbuch-Seite (manpage), README |
| Gibt es ein Gedächtnis zwischen Aufrufen? (State / Session) | Ja, Werkzeug-Aufrufe sind in ein laufendes Gespräch mit dem KI-Assistenten eingebettet (Session) | Nein, jede Anfrage steht für sich; ein Gedächtnis muss künstlich nachgebaut werden (Stateless + Token / Cookie / Session-Store) | Nein, jeder Aufruf ist ein neuer Vorgang (Stateless); Persistenz nur über Dateien, Umgebungsvariablen, Sperrdateien |
| Wie schnell antwortet es? (Latenz-Profil) | Mittel, der Server muss als Hilfsprogramm gestartet werden (Subprozess), dann sind viele Werkzeug-Aufrufe schnell hintereinander möglich | Niedrig, die Web-Welt ist dafür optimiert (Zwischenspeicherung / Caching, dauerhafte Verbindungen / Keep-Alive, Auslieferungs-Netzwerke / CDN) | Sehr niedrig, direkter Programm-Aufruf, kein Netzwerk dazwischen |
| Wie viele gleichzeitige Nutzer sind möglich? (Durchsatz / Skalierung) | Pro Client ein eigenes Hilfsprogramm (Subprocess); für mehrere Nutzer am besten mit Web-Variante (HTTP/SSE) hinter Last-Verteiler | Beliebig viele dank Last-Verteiler (Load-Balancer) und Skalierung über mehr Server (horizontale Skalierung) | Ein Aufruf nach dem anderen; Parallel-Aufrufe über Hilfen wie xargs -P oder GNU parallel |
| Wem wird vertraut? (Trust-Boundary) | Wer das Programm starten darf, darf alle Werkzeuge nutzen, Trust = Datei-Berechtigung auf demselben Rechner | Trust = gültige Eintritts-Marke (Token) im HTTP-Kopf, optional delegierte Anmeldung (OAuth) oder gegenseitige Zertifikate (mTLS); funktioniert auch über das öffentliche Netz | Trust = wer das Programm aufrufen darf; über System-Rechte (sudo, Linux-capabilities, Zugriffs-Listen / ACL) |
| Wie stabil bleibt die Schnittstelle? (Vertrags-Stabilität) | Dynamisch, die Werkzeug-Liste kann sich pro Sitzung ändern, der KI-Assistent fragt zur Laufzeit ab | Stabil und versioniert (z. B. /v1/, /v2/); abwärts-inkompatible Änderungen (Breaking Changes) bekommen einen Übergangs-Pfad | Versioniert über die Programm-Version; veraltete Flags werden in einem Übergangs-Zeitraum (Deprecation) markiert |
| Lässt sich mit anderen Tools verketten? (Kompositionsfähigkeit) | Niedrig, kein Daten-Weiterleitungs-Modell (Pipe), jeder Aufruf ist eine eigene Nachricht (JSON-RPC-Call) | Mittel, mit Helfern wie curl + jq machbar, aber nicht das natürliche Modell | Hoch, die Unix-Philosophie ist genau dafür gemacht: Daten-Weiterleitung (Pipe), Verkettung (&&, ;), Build-Werkzeuge (make), Zeitsteuerung (cron) |
| Wie wird vor Missbrauch geschützt? (Sicherheit / Sandbox) | Tool-Eingaben werden im Server gegen eine Positiv-Liste (Whitelist) geprüft; Werte sind im Bauplan auf Bereiche oder feste Auswahl gebunden (Literal, Range-Bounds) | Anmeldung im HTTP-Kopf (Header-Auth), Anfrage-Begrenzung (Rate-Limit), Web-Schutz-Firewall (WAF), Schutz vor Querverweis-Angriffen (CORS, CSRF) | Datei-System-Berechtigungen, sudo-Regeln, Sicherheits-Profile (AppArmor), Linux-Capabilities |
| Was kann man im Nachhinein sehen? (Observability / Logs) | Aufzeichnung der JSON-RPC-Nachrichten, MCP-Inspector, Fehler-Ausgabe (stderr) des Hilfsprogramms | Zugriffs-Logs des Web-Servers, OpenTelemetry-Spuren, Header-basiertes Tracing | Fehler-Ausgabe (stderr), Erfolgs-Signal (Exit-Code), System-Logs (journal / syslog), Audit-Log |
| Wie wird es installiert und betrieben? (Deployment) | Ein Wrapper-Programm auf dem Suchpfad ($PATH) + ein Eintrag in der Config des KI-Assistenten | Dauerhaft laufender Dienst (Long-running Service) hinter einem vorgelagerten Proxy (Reverse-Proxy) | Programm-Datei auf dem Suchpfad ($PATH); pro Rechner installiert |
| Was passiert, wenn ich dasselbe zweimal aufrufe? (Idempotenz) | Im Werkzeug-Docstring beschrieben; die KI sollte sich daran halten, keine harte Garantie | Durch die HTTP-Methode definiert: GET, PUT, DELETE sind wiederholbar ohne Nebeneffekte; POST nicht | Konvention pro Werkzeug; oft als Flag (--idempotent, --retry) |
| Häufiger Denkfehler (Anti-Pattern) | Aus jeder vorhandenen Web-API automatisch einen MCP machen, die Werkzeug-Liste wird unüberschaubar | Ein lokales CLI-Programm in einen Web-Server umhüllen, viel Aufwand, wenig Nutzen | Aus dem CLI heraus selbst Server starten, um parallel zu skalieren, gehört dann in eine API |
Geeignet, wenn ...
Lesehilfe: (+) erste Wahl, (o) möglich, (-) ungeeignet.
| Situation | MCP | HTTP-API | CLI |
|---|---|---|---|
| Hauptnutzer ist ein KI-Assistent (LLM-Agent) | (+) | (o) als Backend dahinter | (o) wenn der Assistent Shell-Tools nutzen darf |
| Mehrere Konsumenten teilen sich dieselbe Logik | (o) als Hülle | (+) | (-) nur lokal |
| Mensch am Terminal, ad-hoc | (-) | (o) via curl | (+) |
| Build- oder CI-Pipeline | (-) klobig | (+) | (+) |
| Browser-Frontend | (-) | (+) | (-) |
| Werkzeug-Liste situativ / kontextspezifisch | (+) | (-) starr | (-) starr |
| Compliance verlangt formales Schnittstellen-Verzeichnis (OpenAPI) | (o) JSON-RPC-Schema | (+) | (-) |
| Auf demselben Rechner, Trust = Datei-Berechtigungen | (+) | (o) Overhead | (+) |
| Aufrufer kommt über das öffentliche Netz | (-) außer HTTP-Transport | (+) | (-) |
| Hohe Anfrage-Frequenz, niedrige Antwort-Zeit | (o) | (+) | (+) |
| Lange Gesprächs-Sitzungen mit Gedächtnis | (+) | (o) mit Session-Store | (-) |
| Verkettung mit jq / grep / xargs / make | (-) | (o) via curl | (+) |
Entscheidungs-Fragen in Reihenfolge
Wenn die Tabellen schon helfen, kann diese Liste übersprungen werden. Falls nicht, fünf Fragen, in dieser Reihenfolge beantwortet:
- Ist der Hauptnutzer ein KI-Assistent, der Werkzeuge braucht? → MCP (KI-Werkzeug-Steckplatz).
- Brauchen Browser, App oder andere Server dieselbe Funktion auch? → HTTP-API ist die Wahrheit, der MCP wird ein dünner Adapter darüber.
- Ist der Aufrufer ein Mensch oder Skript am selben Rechner? → CLI (Kommandozeilen-Tool).
- Soll der Aufrufer die Werkzeug-Liste zur Laufzeit entdecken? → MCP gewinnt gegen API, weil das Protokoll Selbstbeschreibung mitbringt.
- Soll die eigentliche Logik nur an einer Stelle leben? → sie gehört in die API. MCP und CLI werden dann zu dünnen Hüllen.
So sieht das Muster im aktuellen Projekt aus
| Schicht | Verantwortung | In diesem Projekt |
|---|---|---|
| Geschäftslogik (Kern, Use Cases) | Eingaben-Prüfung (Validierung), HTML-Bereinigung (Sanitization), Datenspeicherung (Persistence) | PHP-Code in /var/www/ki.karlkratz.com/src/ |
| Web-Schnittstelle (HTTP-API) | Stabile, versionierbare Außenseite | /api/pages, Anlegen / Lesen / Ändern / Löschen (POST / GET / PATCH / DELETE) |
| KI-Werkzeug-Steckplatz (MCP-Adapter) | Werkzeug-Schemata bereitstellen, Selbstbeschreibung, Kommunikation per stdio | /var/www/mcp/, startbar via /usr/local/bin/ki-web |
| Kommandozeilen-Tool (CLI, optional) | Skript-, Cron- oder Pipe-Zugriff | Nicht implementiert; würde denselben HTTP-Aufruf gegen /api/pages machen |
Drei Schnittstellen über einer gemeinsamen Geschäftslogik. Mehr zur Architektur unter /mcp-ki-web, die Regeln, an denen wir messen, in /mcp-server-erstellen-regeln.
Was die drei nicht ersetzen
Keine dieser Schnittstellen ersetzt das Nachdenken darüber, welche Operation überhaupt erlaubt sein soll. Die Prüf- und Positiv-Listen-Logik (Validierung und Whitelist) gehört unabhängig von der Hülle an genau eine Stelle, sonst entsteht das klassische Problem, dass das CLI strenger prüfen als die API, oder dass der MCP einen Pfad freigibt, den der Browser nicht aufrufen darf. Wer alle drei Hüllen baut, baut sie um einen einzigen, sauber abgegrenzten Kern.