MCP vs API vs CLI: Was brauchen KI-Agenten?

Ein Agent soll alle deine Rechnungen abrufen. Der Aufruf klappt. Die Antwort enthält gültiges JSON. Die Liste sieht plausibel aus. Erst später fällt auf, dass die Antwort nur die erste Seite berücksichtigt hat.

Diesen Test würde ich machen, bevor ich über MCP vs API vs CLI diskutiere. Nutze MCP, wenn dein Agent verfügbare Werkzeuge entdecken soll, eine CLI für einen Agenten im Terminal und die API direkt, wenn du einen Ablauf ausdrücklich steuern willst. Prüfe bei jedem Zugang, ob er die vollständige Aufgabe ausdrücken und deren Abschluss belegen kann.

Wir haben dieselbe lesende Rechnungsaufgabe mit Normans tatsächlichem Schnittstellencode und synthetischen Daten nachgestellt. Der kleine Datensatz funktionierte über alle drei Wege. Ein größerer zeigte eine gemeinsame Lücke unserer MCP- und CLI-Listenoperationen. Das ist ein enger Vergleich von Schnittstellenverträgen, keine Rangliste von Modellen und keine Untersuchung der Zuverlässigkeit im Produktivbetrieb.

Wie unterscheiden sich MCP, API und CLI für Agenten?

Eine REST-API bietet Endpunkte, Parameter und Antworten. Eine CLI verpackt Operationen in Befehle, Optionen, Standardausgabe und Exit-Codes. Über MCP findet und verwendet ein Agent benannte Werkzeuge mit Eingabeschemata. Die MCP-Spezifikation für Tools beschreibt diesen Vertrag zum Entdecken und Aufrufen.

Oft sind das verschiedene Zugänge zu demselben Produkt. Die CLI kann eine API aufrufen, ein MCP-Werkzeug ebenfalls. Dabei übernimmt keine Hülle automatisch jede Fähigkeit des Backends. Jemand entscheidet, welche Parameter sichtbar sind, welche Standardwerte eingefügt werden und welche Antwortfelder erhalten bleiben.

Die Frage ist aktuell: Am 1. September stellte AuditFile eine Agentenplattform mit Zugang über CLI, API und MCP vor. Am 10. September startete OpenAI die öffentliche Beta der Agents API mit verwalteter Laufzeit. Das sind Anbieterankündigungen, keine Leistungsnachweise. Sie machen die Auswahl der Werkzeuge um einen Agenten zu einer konkreten Produktentscheidung.

Unser bisheriger MCP-Marktüberblick für Buchhaltung fragt, welche Anbieter einen Server haben. Hier geht es darum, ob eine bestimmte Operation deine Aufgabe tatsächlich vollständig erledigen kann.

Wie haben wir dieselbe Rechnungsaufgabe verglichen?

Die Aufgabe lautete: alle Rechnungen abrufen und prüfen, ob die Anzahl unterschiedlicher Datensätze dem Testdatensatz entspricht. Als separate Kontrolle haben wir eine Rechnung anhand ihrer bekannten ID gelesen. Zuerst verwendeten wir eine kleine Sammlung, die auf eine Seite passte. Danach folgten einige Dutzend Rechnungen, die mit der Testkonfiguration drei Seiten benötigten.

Der Test führte das veröffentlichte Norman-CLI-Paket, registrierte Norman-MCP-Rechnungswerkzeuge mit dem echten MCP-SDK und Normans Pagination-Klasse aus. Alle HTTP-Anfragen wurden abgefangen und aus künstlichen Daten beantwortet. Die MCP-Verbindung lief im Arbeitsspeicher. Zugangsdaten, produktive Dienste, Datenbank und Sprachmodell waren nicht Teil des Versuchs.

Diese Grenze ist entscheidend. Wir erfassten die Parameter, die an der Seitennavigation ankamen, die zurückgegebenen Datensätze und die Anzahl der Backend-Anfragen. Netzwerklatenz, Anmeldung, selbstständige Planung, Tokenkosten und buchhalterische Genauigkeit wurden nicht gemessen. Auch die vollständige produktive Verarbeitung mit View, Filtern und Serialisierung war nicht eingebunden.

Der direkte API-Weg folgte den zurückgegebenen Verweisen zur nächsten Seite. MCP und CLI verwendeten ihre angebotenen Listenoperationen. Vor den Wiederherstellungsversuchen lasen wir Schema und Hilfe. Wir nahmen nicht einfach an, dass jeder REST-Parameter auch als Werkzeugargument oder Befehlsoption existiert.

Was passiert, wenn Ergebnisse mehrere Seiten brauchen?

Alle drei Wege lieferten den kleinen Datensatz vollständig. Auch der Abruf der bekannten Rechnung gelang jeweils mit einer Backend-Anfrage. Erst als die Rechnungssammlung nicht mehr auf eine Seite passte, zeigte sich ein Unterschied.

Die ersten Seiten enthielten weniger als die Hälfte aller Testdatensätze. Beide Aufrufe meldeten auf ihrer Schnittstellenebene Erfolg. Die Antworten behaupteten aber nicht, dass weitere Rechnungen fehlten: Die Metadaten zur Seitennavigation blieben erhalten. Wer Gesamtzahl und empfangene Liste verglich, konnte die Unvollständigkeit erkennen.

Die Ursache war konkret. Die Pagination-Klasse des Backends akzeptiert page und page_size. Die getesteten Hüllen boten limit, reichten diesen Parameter unverändert weiter und hatten keine Seitenauswahl. Ein höheres Limit vergrößerte das Ergebnis nicht. Mit dem tatsächlichen API-Parameter für die Seitengröße ließ sich der größere Testdatensatz dagegen in einer Anfrage abrufen.

Das entspricht dem Unterschied zwischen Seitennummern und Limit-Parametern in der REST-Framework-Dokumentation. Ein sinnvoll klingender Parameter wirkt nur, wenn die empfangende Schnittstelle ihn verarbeitet.

Auch eine einzelne REST-Anfrage mit der Standardpagination lieferte nur die erste Seite. Die API vervollständigte die Sammlung nicht automatisch. Unser aufrufender Code steuerte die Schleife. Ihr Vorteil war hier die verfügbare Möglichkeit zum Weiterblättern.

Eine Anfrage sah günstiger aus als drei. Sie hatte aber weniger Arbeit erledigt. Deshalb würde ich einen Benchmark zurückweisen, der Aufrufe zählt, bevor er die Ergebnismenge prüft.

Kann ein Agent einen fehlenden Parameter ausgleichen?

Wir probierten den naheliegenden nächsten Schritt. Die CLI wies eine nicht unterstützte Option --page zurück, bevor eine Backend-Anfrage entstand. Ein zusätzliches, nicht angebotenes Argument page im MCP-Aufruf lieferte in der getesteten SDK-Konfiguration erneut die erste Seite. Der Parameter erreichte das Backend nicht.

Das beschreibt diese Versionen, keine grundsätzliche Grenze von CLI oder MCP. Andere Implementierungen können Seitennavigation anbieten oder alle Seiten intern abrufen. Auch die Seitennavigation beim Entdecken von MCP-Werkzeugen blättert nicht automatisch durch Rechnungen, die ein Werkzeug zurückgibt.

Eine hilfreiche Agentenantwort wäre hier: Ich habe eine Seite erhalten und sehe, dass weitere Datensätze existieren. Diese Operation bietet mir aber keinen Weg zur nächsten Seite. Der Agent sollte weder einen vollständigen Bestand behaupten noch dieselbe Anfrage unverändert wiederholen.

Hat der Agent zusätzlich einen separat eingerichteten API-Zugang, könnte er diesen nutzen. Dann wäre es ein Ablauf über zwei Schnittstellen. Der Vergleich müsste diesen Wechsel erfassen. Damit wäre nicht bewiesen, dass der ursprüngliche Listenbefehl die Aufgabe allein erledigt hat.

Welche Schnittstelle passt zu deinem KI-Ablauf?

Für einen regelmäßigen Export oder die Datengrundlage eines Abgleichs bevorzuge ich eine direkte API mit ausdrücklicher Seitennavigation und einer Vollständigkeitsprüfung. Der aufrufende Code steuert die Schleife. Das ist wertvoll, wenn ein ausgelassener Datensatz die Bedeutung des Ergebnisses verändert.

Für einen Agenten im Terminal kann eine CLI auffindbare Befehle und maschinenlesbare Ausgaben ohne separate Werkzeugintegration bieten. Unsere Einführung in die CLI beschreibt diesen Einsatz. Prüfe die Hilfe und JSON-Ausgabe des einzelnen Befehls. Ein großer Befehlskatalog beweist nicht, dass sämtliche API-Parameter unterstützt werden.

Für einen Assistenten mit MCP-Unterstützung sind benannte Werkzeuge und Schemata ein naheliegender Zugang. Fachlich zugeschnittene Werkzeuge können unnötige Auswahlmöglichkeiten reduzieren. Das Schema muss aber die erforderlichen Steuermöglichkeiten enthalten. Alternativ muss das Werkzeug diese Arbeit übernehmen und einen klaren Abschlussnachweis zurückgeben.

Ich würde die Backend-Operation gemeinsam halten und jede Hülle gegen dieselben Testdaten prüfen. Unser Artikel zum Agent Harness behandelt Ausführung und Prüfung rund um Werkzeuge. Eine ausreichende Schnittstellenabdeckung gehört ebenfalls dazu. Eine stärkere Laufzeit erzeugt keinen fehlenden Parameter.

Wie testest du das vor dem Anschluss eines Agenten?

Beginne mit einem einfachen Einzelabruf und überschreite anschließend eine Seitengrenze. Halte die erwarteten IDs außerhalb der Agentenantwort vor, damit der Prüfer unabhängig vergleichen kann. Teste sowohl eine größere angeforderte Seite als auch das Weiterblättern. Das sind unterschiedliche Fähigkeiten.

Für einen stabilen Testdatensatz lässt sich der Abschluss so prüfen:

assert next_page is None
assert len(set(returned_ids)) == expected_count

Das ist eine Testbedingung, keine allgemeine Garantie für veränderliche Produktivdaten. Während mehrere Seiten geladen werden, können neue Einträge entstehen. Solche Konsistenzfragen müssen separat untersucht werden.

Prüfe danach das Verhalten beim Abbruch. Erkennt der Aufrufer fehlende Daten, erklärt er die Grenze und hält an? Verändert ein neuer Versuch die Anfrage sinnvoll? Gibt es einen verfügbaren und ausdrücklich eingerichteten anderen Zugang? Erfasse diese Ergebnisse, bevor du Geschwindigkeit oder Kosten vergleichst.

Ein nächster Vergleich könnte ein Modell mit derselben Aufgabe, denselben Daten und identischen Abschlussprüfungen einsetzen. Unser Test endet vor diesem Schritt. Er liefert bereits eine praktische Regel: Wähle den Zugang, der die benötigten Operationen erhält, und lass das System Vollständigkeit prüfen, statt sie vom Assistenten voraussetzen zu lassen.