SaaS für KI-Agenten: Weboberfläche, API oder MCP-Zugang?

Ein SaaS ist eine Software, die als Dienst angeboten wird. Ein Dokumentenprüfer lässt sich etwa im Browser bedienen, in einen festen automatischen Ablauf einbauen oder durch einen KI-Agenten aufrufen. Ein Agent wählt mithilfe eines Sprachmodells passende Funktionen für eine Aufgabe aus. Alle drei Zugänge sollen dieselbe Arbeit zuverlässig erledigen; ein zusätzlicher Anschluss allein schafft noch keine Nachfrage.

Die Oberfläche eignet sich für Sichtprüfung

Eine Weboberfläche zeigt Eingaben, Vorschau und Ergebnisse zusammen. Bei einer Dokumentenprüfung können markierte Fehlerstellen sichtbar sein, bevor die geprüfte Datei zum Export freigegeben wird. Das hilft besonders bei seltenen Aufgaben und Entscheidungen, die eine fachkundige Person bestätigen muss.

Auch nach dem Einbau automatischer Zugänge bleibt eine verständliche Auftragsübersicht hilfreich. Ein Auftrag kann beispielsweise warten, laufen, fertig sein oder an einer fehlenden Berechtigung scheitern. Solche Angaben erleichtern die Fehlersuche auch ohne Kenntnis technischer Protokolle.

Die API eignet sich für festgelegte Abläufe

Eine API ist eine Schnittstelle für andere Programme. Ein festgelegter Ablauf kann darüber eine Prüfung starten, den Bearbeitungsstand abfragen und das Ergebnis herunterladen. Die Dokumentation legt fest, welche Eingaben erlaubt sind, wann eine Anfrage abbricht und wie Fehler gemeldet werden. Versionsangaben helfen, Änderungen an der Schnittstelle planbar einzuführen.

Eine Auftragsnummer allein verhindert keine doppelte Ausführung. Dafür muss der Server eine Wiederholungskennung speichern und weitere Anfragen mit derselben Kennung demselben Auftrag zuordnen, auch bei gleichzeitigen Anfragen. Der Client muss dieselbe Kennung erneut senden; abweichende Eingaben benötigen eine klare Fehlerbehandlung. Diese Eigenschaft heißt Idempotenz. [4] Bei langen Vorgängen bestätigt die erste Antwort nur die Annahme; das Ergebnis folgt später. Eine angenommene Prüfung kann noch scheitern.

MCP macht Werkzeuge für geeignete Clients zugänglich

MCP steht für Model Context Protocol. Das Protokoll legt unter anderem fest, wie eine Anwendung verfügbare Werkzeuge und deren benötigte Eingaben abfragt und ein Werkzeug aufruft. [1] Für den Dokumentenprüfer wären „Prüfung starten“, „Status lesen“ und „Ergebnis lesen“ klar begrenzte Werkzeuge. MCP garantiert weder eine passende Werkzeugwahl noch ein fachlich richtiges Ergebnis.

Eine Werkzeugbeschreibung muss deutlich machen, was ein Aufruf verändert. Eine Datei zu prüfen ist etwas anderes, als die Datei zu versenden oder zu löschen. Kritische Aktionen brauchen eine passende Freigabe und eine Prüfung der Berechtigung auf dem Server. Eine bloße Kennzeichnung als „nur lesend“ ersetzt diese Kontrolle nicht.

Der Server prüft jeden Zugriff

Ein Agent braucht nur Zugriff auf die Daten und Funktionen der jeweiligen Aufgabe. Beispielsweise darf ein Auftrag für Firma A keine Dokumente von Firma B lesen. Der Server muss deshalb bei jedem Auftrag Identität, Kundenkonto und erlaubte Aktion prüfen. Eine mitgesendete Kontobezeichnung allein beweist keine Berechtigung.

Für geschützte HTTP-Verbindungen beschreibt MCP einen OAuth-basierten Ablauf: Ein Zugriffstoken weist die erteilte Berechtigung gegenüber dem vorgesehenen Server nach. Lokale stdio-Verbindungen, also der Datenaustausch über Ein- und Ausgabe eines gestarteten Programms, verwenden diesen Ablauf nicht. [2] MCP verbietet die Annahme von Tokens, die nicht für den MCP-Server ausgestellt wurden. Sonst könnte ein Vermittler fremde Zugriffsrechte missbrauchen. Auch die Freigabe für einen angebundenen Client darf nicht ungeprüft für einen anderen gelten. [3]

Abrechnung an Arbeit statt Gespräch koppeln

Für die Abrechnung eignet sich ein klar definierter Auftrag besser als die Zahl der Gesprächsrunden. Ein Agent kann mehrfach nach dem Bearbeitungsstand fragen, ohne eine neue Dokumentenprüfung auszulösen. Ein mögliches Modell reserviert vor dem Start einen Betrag aus dem Budget und rechnet die tatsächlich vereinbarte Leistung ab. Regeln für Fehler und abgebrochene Aufträge müssen ausdrücklich feststehen.

Ein frei gewähltes Beispiel nimmt 1.000 Dokumentaufträge und insgesamt 100 zusätzliche Verarbeitungsversuche an. Bei 0,02 Geldeinheiten je Versuch entstehen 1.100 × 0,02 = 22 variable Kosten. Das sind Kosten tatsächlich ausgeführter Versuche, etwa nach einem Verarbeitungsfehler, nicht automatisch jeder wiederholten HTTP-Anfrage. Der Schutz gegen doppelte Aufträge soll gerade unnötige Mehrfacharbeit vermeiden. Reine Statusabfragen können ein eigenes Kontingent erhalten; auch diese Abfragen verursachen etwas Serveraufwand. Das Beispiel ist kein Plattformtarif.

Ein Pilot ohne vollständigen Plattformumbau

Ein kleiner Probelauf kann zunächst drei Funktionen über Oberfläche und API anbieten: Prüfung starten, Status abfragen und Ergebnis lesen. Ein MCP-Anschluss nutzt anschließend dieselben Prüfregeln und dieselbe Auftragsverarbeitung. Die Pilotgruppe hält fest, wie viele Aufgaben gelingen, wo Freigaben nötig sind, ob doppelte Aufträge entstehen und wie viel Unterstützung nötig ist.

Eine kurze Anleitung mit einem vollständigen Beispiel erleichtert den Einstieg mehr als eine lange Liste unklarer Werkzeuge. Ein MCP-Anschluss lohnt sich vor allem dann, wenn konkrete Kunden eine kompatible Anwendung verwenden und der neue Zugang nachweislich Arbeitsschritte spart.

Quellen

1. MCP: tools specification
2. MCP: authorization
3. MCP: security best practices
4. Stripe: Wiederholungen mit Idempotenz-Schlüssel

Quellen geprüft: 25. Oktober 2026.