Wie KI-Agenten über eine CLI und MCP Ihr BSS erreichen

Eine Kundin ruft an einem Dienstagnachmittag an und fragt, wann ihr Glasfaseranschluss eingeschaltet wird. Die Person am Servicedesk öffnet den Kundendatensatz, dann den Auftrag, dann die Rückmeldung des Installationspartners, und setzt die Antwort aus drei Bildschirmen zusammen. Ein KI-Agent, dem man dieselbe Frage stellt, hat dasselbe Problem, nur ohne Bildschirme. Er braucht einen festgelegten Zugang zu diesen Systemen.

Dieser Artikel richtet sich an die IT-Leitung eines ISP, MVNO oder Resellers, die von MCP gehört hat und wissen möchte, was sie damit anfangen soll. Er behandelt, was eine Kommandozeilenschnittstelle (CLI) einem Agenten bietet, was das Model Context Protocol ist, wie beides zusammenhängt, wie eine sinnvolle erste Integration aussieht und was Sie von jedem Hersteller verlangen sollten, der eines von beiden anbietet.

Warum Agenten einen festgelegten Zugang brauchen

Bildschirme sind für Menschen gebaut. Ein Agent, der sich durch eine Weboberfläche klickt, scheitert, sobald eine Schaltfläche verschoben wird, und er sieht, was die angemeldete Person gerade zu sehen bekommt. Programmierschnittstellen geben Agenten einen festgelegten Zugang zu Daten und Aktionen: Jede Operation hat einen Namen, ihre Eingaben sind beschrieben, ihr Ergebnis hat eine feste Form, und das System kann prüfen, wer fragt, bevor es antwortet.

Für einen Anbieter ist das aus einem praktischen Grund wichtig. Die Frage „Wo steht dieser Auftrag?“ berührt das CRM, die Auftragsverwaltung, die Rückmeldungen aus der Provisionierung und manchmal die Abrechnung. Antwortet jedes dieser Systeme über eine festgelegte Operation, kann ein Agent die Antworten so zusammenführen, wie es ein guter Disponent tut. Antworten sie nur über Bildschirme, beginnt jedes Agentenprojekt mit Screen-Scraping, und jede neue Version jedes Tools kann es zum Scheitern bringen.

Was eine CLI einem Agenten bietet

Eine Kommandozeilenschnittstelle bietet einen festen Satz von Befehlen. Ein Agent, der auf einem Rechner Befehle ausführen kann, ruft sie auf und liest das strukturierte Ergebnis. Nehmen wir ein hypothetisches Werkzeug namens bss und eine Auftragsprüfung:

$ bss order show 48213 --json
{
  "order": "48213",
  "customer": "C-10442",
  "product": "Fibre 1000",
  "state": "awaiting_installation",
  "appointment": "2026-11-04",
  "missing": ["ont_serial"]
}

Der Agent muss keine Seite interpretieren. Er erhält den Auftragsstatus, den Termin und das eine, was die Aktivierung blockiert, und er kann das einer Person in einfachen Worten erklären oder an den nächsten Befehl weitergeben.

Eine gute CLI für Agenten hat einige Eigenschaften, auf die es sich zu achten lohnt. Jeder Befehl kann sich selbst beschreiben (Eingaben, ob er etwas liest oder ändert, welche Berechtigung er braucht), sodass der Agent eine Operation nachschlagen kann, bevor er sie ausführt. Datenbefehle geben auf Wunsch JSON zurück. Fehler kommen als klare Meldungen mit stabilen Exit-Codes zurück. Alles, was etwas ändert oder versendet, bietet einen Probelauf, der die Anfrage zeigt, ohne sie auszuführen.

Eine CLI läuft dort, wo der Agent läuft, meist auf dem Arbeitsplatzrechner einer Mitarbeiterin oder eines Mitarbeiters, und handelt mit den Zugangsdaten der Person, die sie eingerichtet hat. Damit passt sie gut zu Menschen, die bereits an ihrem Arbeitsplatz mit einem Agenten arbeiten, und zu skriptgesteuerten Prüfungen, die nach Zeitplan laufen.

Was MCP ist

Das Model Context Protocol (MCP) ist ein quelloffener Standard, um KI-Anwendungen mit externen Systemen wie Datenquellen, Werkzeugen und Arbeitsabläufen zu verbinden (Model Context Protocol, 2026). Es wird von KI-Assistenten wie Claude und ChatGPT und von Entwicklungswerkzeugen wie Visual Studio Code und Cursor unterstützt.

Die Architektur kennt drei Beteiligte. Der Host ist die KI-Anwendung. Für jedes System, mit dem er sich verbindet, erzeugt der Host einen Client. Der Server ist das Programm, das die Funktionen eines Systems bereitstellt. Ein Server kann Tools anbieten (Funktionen, die die KI-Anwendung aufrufen kann), Ressourcen (Daten, die Kontext liefern) und Prompts (wiederverwendbare Vorlagen). Nachrichten verwenden JSON-RPC 2.0. Ein lokaler Server kommuniziert mit dem Client über Standardeingabe und Standardausgabe, ein entfernter über HTTP (MCP-Architekturübersicht).

Für ein Back-Office sind die Tools am wichtigsten. Jedes Tool hat einen Namen, eine Beschreibung und ein JSON Schema für seine Eingaben, und es kann ein Ausgabeschema deklarieren, damit Ergebnisse als strukturierte Daten zurückkommen. Der Client fragt den Server, welche Tools es gibt (tools/list), und ruft eines mit Argumenten auf (tools/call). Die Spezifikation legt ausserdem fest, dass Server alle Tool-Eingaben validieren, Zugriffskontrollen umsetzen und Tool-Aufrufe begrenzen müssen und dass Clients die nutzende Person bei sensiblen Operationen um Bestätigung bitten und die Tool-Nutzung für Audits protokollieren sollten (MCP-Spezifikation, Tools).

Wie beides zusammenhängt

Eine CLI und ein MCP-Server sind zwei Zugänge zu denselben Geschäftsfunktionen. „Zeige Auftrag 48213“ sollte eine einzige Operation im Geschäftssystem sein, erreichbar als Befehl für Agenten, die Befehle ausführen, und als MCP-Tool für KI-Anwendungen, die sich über das Protokoll verbinden.

Entscheidend ist, wo die Logik und die Rechte liegen. Weder die CLI noch der MCP-Server sollte Geschäftsregeln enthalten oder selbst entscheiden, was ein Aufrufer darf. Beide geben die Anfrage an das Geschäftssystem weiter, und dieses System prüft Identität, Rolle und Berechtigung und liefert das Ergebnis. Hat der MCP-Server eines Herstellers eine eigene Vorstellung davon, wer welchen Kunden sehen darf, pflegen Sie zwei Regelwerke, und die werden auseinanderlaufen.

In der Praxis werden viele Anbieter mit der CLI beginnen, weil sie sich leicht testen lässt: Sie können denselben Befehl von Hand ausführen und sehen genau, was der Agent sieht. Ein entfernter MCP-Server wird nützlich, wenn mehrere KI-Anwendungen, oder später die eigenen Assistenten Ihrer Kundinnen und Kunden, dieselben Funktionen brauchen, ohne etwas zu installieren.

Eine erste Integration im Telekom-Back-Office

Beginnen Sie mit einer wiederkehrenden Frage, die Ihr Team jede Woche Zeit kostet, und beschränken Sie den Agenten aufs Lesen. Ein guter Kandidat sind offene Umzüge: Der Agent prüft jeden Umzugsauftrag, vergleicht den Auftragsstatus mit der technischen Rückmeldung des Netzteams und listet für den Kundendienst auf, was fehlt (ein bestätigtes Datum, ein Zugangscode für das Gebäude, eine neue ONT-Seriennummer). Ein weiterer Kandidat sind die Glasfaseraktivierungen der nächsten Woche, bei denen noch ein Hindernis offen ist.

Die Reihenfolge der Arbeit ist wichtig, deshalb hier als Schritte:

1. Benennen Sie die Frage und die Person, die für das Ergebnis zuständig ist. Diese Person prüft die Liste und entscheidet, was als Nächstes geschieht.
2. Listen Sie die Lesebefehle auf, die der Agent braucht: Kundensuche, Dienste eines Kunden, Auftragsstatus, Rückmeldungen aus der Provisionierung, offene Tickets. Gewähren Sie nichts weiter.
3. Legen Sie für den Agenten eine eigene Identität mit einer Rolle mit reinem Lesezugriff an, damit sich seine Anfragen von denen der Person unterscheiden lassen, die ihn betreibt.
4. Lassen Sie ihn einige Wochen lang neben dem manuellen Prozess laufen und vergleichen Sie die Liste des Agenten mit dem, was das Team gefunden hat.
5. Besprechen Sie Schreibaktionen erst danach, eine nach der anderen, jede mit einer ausdrücklichen Bestätigung durch eine Person.

Der Agent liest, der Mensch entscheidet. So bleiben Fehler billig, während Sie lernen, wo Daten veraltet sind oder wo sich zwei Systeme widersprechen.

Eine weitere Entscheidung gehört an den Anfang. Der Agent kann zurückgegebene Daten an seinen KI-Anbieter senden. Legen Sie fest, welche Felder die Lesebefehle zurückgeben (der Disponent braucht die Adresse und den Termin, der Agent braucht die Bankverbindung der Kundin nicht), und wählen Sie Agent und Hosting passend zu Ihrer Datenrichtlinie.

Was Sie von jedem Hersteller verlangen sollten

Ob es um Ihren BSS-Hersteller, Ihr CRM oder ein Netzmanagement-Tool geht: Verlangen Sie Folgendes, bevor Sie einen Agenten anbinden.

Authentifizierung. Jede Anfrage trägt eine Identität, bei Menschen und bei Agenten. Für entfernte MCP-Server folgt die Autorisierungsspezifikation OAuth 2.1, und Server müssen prüfen, dass ein Zugriffstoken für sie ausgestellt wurde (MCP-Spezifikation, Autorisierung). Im Protokoll ist die Autorisierung optional, fragen Sie also nach, ob sie eingeschaltet ist.

Eingegrenzte Berechtigungen. Ein Agent erhält die Rechte, die seine Aufgabe braucht, und nicht mehr. Die MCP-Hinweise empfehlen kurzlebige Tokens und Scopes mit minimalen Rechten, aufgeteilt pro Tool oder Funktion und bei jedem Aufruf auf dem Server geprüft (Understanding Authorization in MCP). Fragen Sie, wie ein Agent mit reinem Lesezugriff eingerichtet wird und was geschieht, wenn er zu schreiben versucht.

Protokollierung. Jeder Aufruf hinterlässt einen Eintrag: welcher Agent, in wessen Auftrag, welcher Befehl, welche Datensätze, wann und mit welchem Ergebnis. Lassen Sie sich den Eintrag für eine abgelehnte Anfrage zeigen.

Aufruflimits. Ein Agent, der in einer Schleife festhängt, kann das Auftragssystem weit schneller aufrufen als jeder Servicedesk. Limits pro Agent schützen das System und zeigen Ihnen, wenn etwas nicht stimmt.

Versionierung. Befehle und Tool-Schemas ändern sich. MCP selbst kennzeichnet Protokollversionen mit einem Datum, und die aktuelle Version ist 2026-07-28 (MCP-Versionierung). Fragen Sie, wie der Hersteller seine eigenen Befehle versioniert, wie lange ein abgekündigter Befehl weiter funktioniert und wo Änderungen angekündigt werden.

Ein nützlicher Test in jeder Demo: Bitten Sie den Hersteller, einen Befehl auszuführen, den der Agent nicht ausführen darf, und Ihnen dann den Protokolleintrag zu zeigen, den dieser Versuch hinterlassen hat.

Die METAVSHN CLI und der MCP-Server

Wir betreiben selbst einen ISP (Ticinocom, wo die Gründer 30+ Jahre in der Telekommunikation verbracht haben), deshalb haben wir diese Schnittstellen für die Fragen gebaut, die unser eigener Servicedesk stellt. Die METAVSHN CLI und der MCP-Server sind im Frühzugang verfügbar.

Die CLI läuft auf Ihrem Rechner und funktioniert mit dem Agenten, den Ihr Unternehmen bereits freigegeben hat, mit jedem Agenten, der Befehle ausführen kann. Sie fragt Kunden, Dienste und Richtlinien ab. Die Suche nach einem Befehl und seine Beschreibung funktionieren offline, ohne Anfrage an Ihr BSS. Datenbefehle geben JSON zurück, und jeder Befehlsvertrag listet die Eingaben, den Operationstyp und einen Berechtigungshinweis auf. Der MCP-Server stellt dieselben Funktionen für KI-Anwendungen bereit, die MCP sprechen.

Jede Anfrage, ob von der CLI oder vom MCP-Server, wird von METAVSHN gegen Identität, Rolle und Berechtigung geprüft. Die Berechtigungshinweise sagen dem Agenten, was eine Operation voraussichtlich braucht. Für sich allein gewähren sie nichts. Etwas zu löschen oder etwas nach aussen zu versenden erfordert eine ausdrückliche Bestätigung, und ein Probelauf zeigt die Anfrage, bevor etwas gesendet wird.

Wenn Sie eine erste Integration mit reinem Lesezugriff auf Ihre eigenen Kunden- und Auftragsdaten ausprobieren möchten, sagen Sie uns, welchen Agenten Ihr Team verwendet, und wir nehmen Sie in die Frühzugangsgruppe auf: die METAVSHN CLI und der MCP-Server.

Quellen

Alle Quellen abgerufen am 31. Oktober 2026.

1. Model Context Protocol, „What is the Model Context Protocol (MCP)?“, Dokumentation zur Protokollversion 2026-07-28, Juli 2026. modelcontextprotocol.io
2. Model Context Protocol, „Architecture overview“, Protokollversion 2026-07-28, Juli 2026. modelcontextprotocol.io
3. Model Context Protocol, „Tools“, Spezifikationsversion 2026-07-28, Juli 2026. modelcontextprotocol.io
4. Model Context Protocol, „Authorization“, Spezifikationsversion 2026-07-28, Juli 2026. modelcontextprotocol.io
5. Model Context Protocol, „Understanding Authorization in MCP“, Juli 2026. modelcontextprotocol.io
6. Model Context Protocol, „Versioning“, aktuelle Version 2026-07-28. modelcontextprotocol.io