MCP-Server
Admin Power Pack bringt einen MCP-Server mit. Über ihn kann ein KI-Agent – Claude, ChatGPT oder ein selbst gebauter Agent – die STARFACE bedienen: Zustand und Verzeichnisse abfragen, Logdateien durchsuchen und, sofern Sie es freigeben, Benutzer anlegen, Endgeräte provisionieren, Module installieren oder Systemupdates und Wartungen auslösen.
Zu finden unter , Card MCP-Server.
Wie sich das anfühlt, zeigt das nebenstehende Beispiel. Die Frage lautet: „Über welche Leitung kam der letzte Telefonanruf herein?" Der Agent entscheidet selbst, dass er dafür die Rufliste und die Leitungen ansehen muss, ruft beides ab und antwortet mit dem Leitungsnamen. Niemand hat ihm gesagt, welche Maske er dafür öffnen soll – es gibt keine Maske mehr, es gibt nur noch die Frage.
Das Model Context Protocol ist ein offener Standard, über den KI-Agenten mit fremden Systemen sprechen. Ein System stellt „Werkzeuge" bereit und beschreibt in Worten, was jedes davon kann; der Agent liest diese Beschreibungen und wählt selbst aus, welche er für die gestellte Aufgabe braucht. Für Sie heißt das: Sie geben die Werkzeuge frei – welchen Weg der Agent daraus baut, müssen Sie nicht vorher wissen.
Was sich dadurch ändert
Administrieren ohne Einloggen & Benutzerlizenz
Ein Systemadministrator, benötigte bisher zum Verwalten der Anlage ein Konto und eine Benutzerlizenz – ein Konto, das nie telefoniert hat und trotzdem lizenziert werden musste.
Der MCP-Server geht einen anderen Weg: Ein Agent meldet sich mit einem statischen API-Token an, nicht mit einem STARFACE-Benutzerkonto. Es gibt keinen Anmeldevorgang, keine Sitzung und keinen Benutzer, dem die Anfrage zugerechnet würde. Damit benötigt die Administration per MCP keine Benutzerlizenz.
Weil kein Benutzer hinter der Anfrage steht, greifen auch keine benutzerbezogenen Berechtigungen. Was ein Agent darf, entscheiden ausschließlich die Freigaben im Bereich MCP-Server – siehe Werkzeuge freigeben.
Viele Anlagen an einem Arbeitsplatz
Ein Systembetreuer kann beliebig viele MCP-Server gleichzeitig anbinden – einen je Kundenanlage.
In der Konfigurationsdatei seines Agenten steht dann nicht ein Eintrag starface, sondern
kunde-a, kunde-b, kunde-c. Aus der Anweisung „Prüfe auf allen Anlagen, ob eine Leitung
nicht registriert ist" wird ein automatisierter Durchlauf über alle angebundenen Systeme.
Dafür ist keine zusätzliche Portfreigabe nötig: Der Endpunkt liegt auf demselben HTTPS-Port, über den Sie ohnehin die Administrationsoberfläche erreichen. Wer die Anlage heute administrieren kann, erreicht auch ihren MCP-Endpunkt.
Aus einem Klickpfad wird eine Frage
Eine Log-Analyse war bisher eine Kette: Web-Oberfläche aufrufen → Zugangsdaten heraussuchen → anmelden → Administration öffnen → Logdatei wählen → Zeitraum eingrenzen → lesen → deuten. Sechs Schritte, bevor die eigentliche Arbeit beginnt.
Mit einem angebundenen Agenten ist es ein Satz:
„Was ist bei der X GmbH am 22.08. um 09:30 Uhr im Rufablauf passiert?"
Der Agent sucht die passende Logdatei, grenzt den Zeitraum ein, liest die Zeilen und legt Ihnen das Ergebnis als Erklärung vor – nicht als Rohtext. Dasselbe gilt für Aufgaben, die sich wiederholen: Ein Modulupdate auf hundert Systeme benötigt keine hundert Sitzungen mehr, sondern nur noch eine Anweisung.
Bisher: der Weg zur Information
Sie wissen, was Sie sehen wollen, und arbeiten sich durch Anmeldung, Menüs und Filter dorthin. Jede weitere Anlage bedeutet, den Weg noch einmal zu gehen.
Jetzt: die Frage zur Information
Sie formulieren, was Sie wissen wollen. Den Weg dorthin sucht der Agent – über eine Anlage genauso wie über fünfzig.
Einrichten
Der MCP-Server ist ab Werk ausgeschaltet, und alle Werkzeuge bis auf eines sind gesperrt. Erreichbar ist ausschließlich, was Sie ausdrücklich freischalten. Fünf Schritte führen von dort zu einem arbeitsfähigen Agenten.
Der MCP-Server verlangt eine gültige Modullizenz und prüft sie bei jeder Anfrage. Ohne Lizenz weist der Endpunkt jede Anfrage ab – auch dann, wenn der Server aktiviert ist.
1. API-Token anlegen
Der Token ist der Ausweis des Agenten. Sie legen ihn im Tab in der Card Sicherheit unter an; aus der Card MCP-Server führt die Schaltfläche direkt dorthin.
Vergeben Sie je Agent bzw. je Arbeitsplatz einen eigenen Token mit sprechendem Namen. Das kostet nichts und zahlt sich zweifach aus: Im Protokoll steht später, welcher Token eine Aktion ausgelöst hat, und ein kompromittierter Token lässt sich einzeln zurückziehen, ohne alle anderen Anbindungen zu unterbrechen.
Der Token wird ausschließlich beim Anlegen angezeigt. Danach zeigt ihn keine Oberfläche mehr – auch die Card MCP-Server nicht. Notieren Sie ihn sofort an einem sicheren Ort; verloren heißt neu anlegen.
2. Server aktivieren
In der Card MCP-Server schalten Sie ein. Darunter erscheint die Endpunkt-Adresse Ihrer Anlage in der Form:
https://<ihre-anlage>/fp/7ce0d8df/mcp/
7ce0d8df ist die feste Kennung von Admin Power Pack und auf jeder Anlage identisch. Der abschließende
Schrägstrich gehört dazu.
3. Zugriff eingrenzen
Zwei Felder entscheiden, wer den Endpunkt überhaupt erreicht:
| Feld | Bedeutung |
|---|---|
| Erlaubte IP-Adressen und Subnetze | Einzeladressen (192.168.10.5) oder CIDR-Bereiche (192.168.10.0/24). Anfragen von anderen Adressen werden abgewiesen, bevor der Token überhaupt geprüft wird. |
| Proxy-Header auswerten | Nur einschalten, wenn ein Reverse Proxy vor der Anlage steht – und dann die Adressen dieser Proxys unter Vertrauenswürdige Proxys eintragen. |
Bleibt die Liste leer, nimmt der Endpunkt Anfragen aus jedem Netz entgegen und ist allein durch den Token geschützt. Die Oberfläche weist darauf hin. Tragen Sie mindestens das Netz ein, aus dem Ihre Agenten kommen.
Steht ein Reverse Proxy vor der Anlage, sieht sie bei jeder Anfrage die Adresse des Proxys – nicht die des Agenten. Ein IP-Filter würde dann entweder alles durchlassen oder alles sperren. Erst wenn Sie die eigenen Proxys benennen, wertet die Anlage deren Herkunftsangabe aus. Wer diese Angabe ungeprüft glauben würde, hätte den Filter mit einem gefälschten Kopfzeilenwert umgangen – deshalb ist der Schalter kein Komfort, sondern die Bedingung dafür, dass der Filter hinter einem Proxy überhaupt etwas wert ist.
4. Werkzeuge freigeben
Im Abschnitt Werkzeuge geben Sie Thema für Thema frei, was ein Agent darf. Mehr dazu im nächsten Abschnitt. Zum Schluss .
5. Client verbinden
Die Card hält für die drei gängigen Fälle fertige Konfigurationsausschnitte bereit – jeweils
mit Ihrer eigenen Endpunktadresse. Ersetzen Sie <token> durch den Wert aus Schritt 1.
- Claude Code
- Konfigurationsdatei (.mcp.json)
- Claude Desktop / Cowork
claude mcp add --transport http starface https://<ihre-anlage>/fp/7ce0d8df/mcp/ \
--header "X-Fp-Token: <token>"
{
"mcpServers": {
"starface": {
"type": "http",
"url": "https://<ihre-anlage>/fp/7ce0d8df/mcp/",
"headers": {
"X-Fp-Token": "<token>"
}
}
}
}
Clients ohne eigene HTTP-Unterstützung erreichen den Endpunkt über eine lokale Brücke:
{
"mcpServers": {
"starface": {
"command": "npx",
"args": [
"-y",
"mcp-remote",
"https://<ihre-anlage>/fp/7ce0d8df/mcp/",
"--header",
"X-Fp-Token:${FP_TOKEN}"
],
"env": {
"FP_TOKEN": "<token>"
}
}
}
}
Enthält Ihre Konfigurationsdatei bereits MCP-Server, kopieren Sie mit der kleinen Schaltfläche
im Snippet nur den hervorgehobenen Eintrag und fügen ihn in Ihr vorhandenes mcpServers
ein. Die ganze Datei zu ersetzen würde alle übrigen Server entfernen. Für mehrere Anlagen
benennen Sie den Eintrag statt starface besser nach dem Kunden.
Authorization: Bearer verwendenDer Token gehört in den Header X-Fp-Token. Die STARFACE beantwortet Anfragen mit
Authorization: Bearer selbst, bevor ein Modul sie zu sehen bekommt – der Aufruf schlägt dann
mit einer Fehlermeldung fehl, die nichts mit dem MCP-Server zu tun hat.
Ein abgelehnter Token wird bewusst mit 403 beantwortet und nicht mit 401. Der Grund: MCP-Clients
verstehen ein 401 als Aufforderung, einen OAuth-Anmeldelauf zu starten, den dieser Server
nicht anbietet – sie melden dann eine Fehlkonfiguration des Anmeldeverfahrens statt des
eigentlichen Problems. Bleibt die Verbindung aus, prüfen Sie in dieser Reihenfolge: Ist der
Server aktiv? Liegt die Adresse des Agenten im IP-Filter? Stimmt der Token? Ist die Modullizenz
gültig? Die JSON-Antwort des Endpunkts nennt jeweils die tatsächliche Ursache.
Werkzeuge und Freigaben
Die Werkzeugtabelle ist das Herzstück der Konfiguration. Jede Zeile ist ein Thema der Anlage – Benutzer, Rufliste, Zertifikate, Protokolldateien – und je Thema entscheiden Sie getrennt, wie weit ein Agent gehen darf.
Die vier Spalten
| Spalte | Was der Agent damit darf | Rückfrage beim Aufruf |
|---|---|---|
| Lesen | ausschließlich abfragen und durchsuchen | Nein nie |
| Ändern | Werte setzen, die sich genauso wieder zurücksetzen lassen | teils – bei gewichtigen Änderungen |
| Löschen | Daten entfernen, die nichts wiederherstellt | Ja immer |
| Ausführen | Aktionen auslösen – auflegen, neu registrieren, installieren, senden | Ja immer |
Ein Häkchen in der Kopfzeile setzt die ganze Spalte. Rechte, die ein Thema gar nicht anbietet, haben dort kein Kästchen, sondern nur einen Strich – die Anlage kennt zu Rufnummern schlicht keine Änderung über diesen Weg.
Ändern und Löschen sind zwei Stufen desselben Rechts, nicht zwei getrennte Rechte. Ein Klick auf Ändern nimmt deshalb ein zuvor erteiltes Löschrecht wieder zurück. Bei Themen, deren Änderung ausschließlich im Löschen besteht – Rufliste, Systemmeldungen – gibt es folgerichtig nur die Spalte Löschen.
Die Trennung ist kein Ordnungssinn, sondern der Grund, warum die Rückfrage bei heiklen Aktionen ihre Wirkung behält. Wären Abfrage und Löschung dasselbe Werkzeug, müsste der Agent schon beim bloßen Auflisten von Benutzern nachfragen – und wer hundert Rückfragen pro Sitzung wegklickt, liest die hundertunderste nicht mehr. So fragt nichts, was nur liest, und eine Rückfrage bedeutet wieder etwas.
Was ein nicht freigegebenes Werkzeug bewirkt
Es existiert für den Agenten nicht. Es taucht in seiner Werkzeugliste gar nicht erst auf, statt dort zu stehen und beim Aufruf abgewiesen zu werden. Ein Agent kann also nicht auf die Idee kommen, es zu versuchen.
Geben Sie zunächst nur die Spalte Lesen frei und arbeiten Sie eine Weile so. Eine Anlage, die Auskunft gibt, deckt einen überraschend großen Teil des Alltags ab – Statusfragen, Log-Analysen, Rufauswertungen, „warum klingelt das nicht?". Ändernde Rechte kommen dann gezielt dort dazu, wo Sie sie wirklich brauchen.
Die drei Gruppen
Die Tabelle ist nach Herkunft gegliedert:
| Gruppe | Inhalt |
|---|---|
| STARFACE | Themen der Anlage selbst: Benutzer, Gruppen, Rufnummern, Berechtigungen, Zertifikate, Datum/Uhrzeit, Laufende Gespräche, IP-Blacklist und IP-Whitelist |
| Admin Power Pack | Themen, die erst dieses Modul erschließt – u. a. Anlagenzustand, Protokolldateien, Rufliste, Leitungen, Rufverteilung, SIP-Konten, Rufumleitungen, Adressbücher, Endgerätekonfiguration, Benutzervorlagen, Zeitgesteuerte Aktivitäten, Netzwerkeinstellungen, Module und Speicherplatz freigeben |
| je Modul eine eigene Gruppe | Themen, die ein anderes Fluxpunkt-Modul beisteuert – etwa Transkripte, überschrieben mit Call Recording |
Werkzeuge aus einer Modulgruppe schalten Sie genauso einzeln frei wie alle anderen. Sie werden aufgeführt, auch wenn das zugehörige Modul fehlt – der Agent erfährt dann beim Aufruf, dass es installiert, aktiviert oder lizenziert werden müsste, statt die Fähigkeit nie kennenzulernen.
Fähigkeiten der Anlage
Ein Werkzeug hat eine Sonderrolle: Fähigkeiten der Anlage. Es beantwortet dem Agenten die Frage, ob die Anlage eine bestimmte Aufgabe überhaupt abdeckt – und wenn nicht, was fehlt.
Der Nutzen zeigt sich an einer Bitte wie „Richte eine Ansage ein: 1 für den Vertrieb, 2 für den Support." Ohne diesen Katalog rät ein Agent und baut aus Gruppen und Umleitungen etwas zusammen, das wie ein Sprachmenü aussieht und keines ist. Mit ihm antwortet er stattdessen sinngemäß: Dafür gibt es Pro IVR, das ist auf dieser Anlage nicht installiert – soll ich es zur Demo installieren? Der Katalog kennt rund dreißig solcher Aufgabengebiete und nennt zu jedem auch den Weg, den die STARFACE ohne Zusatzmodul anbietet, sofern es einen gibt.
Genau deshalb lässt sich dieses eine Werkzeug nicht abschalten: Es liest nichts außer dem eigenen Katalog und dem Schaltzustand der übrigen Werkzeuge. Wer keinen Agenten auf der Anlage möchte, schaltet den Server aus – das ist der ehrliche Schalter.
Was gar nicht angeboten wird
Einige Fähigkeiten stehen über den MCP-Server grundsätzlich nicht zur Verfügung, unabhängig von jeder Freigabe:
- die Anlage auf Werkszustand zurücksetzen
- das Root-Kennwort setzen
- SIP-Zugangsdaten im Klartext ausgeben
- Test-Verbindungsdaten in die Produktivtabellen schreiben
- ein EasySetup-Projekt anwenden
- eine
.sfm-Datei hochladen - die API-Tokens selbst verwalten
Module werden deshalb über ihre Kennung aus dem Fluxpunkt-Katalog installiert, nicht durch Hochladen einer Datei. Der Agent kann damit nur signierte Module aus einer bekannten Quelle installieren – Beliebiges hochzuladen wäre die Ausführung fremden Codes auf Ihrer Anlage.
Über Berechtigungen lässt sich das Administrationsrecht vergeben und entziehen. Über Zeitgesteuerte Aktivitäten erreicht ein Agent die Systemaktionen der STARFACE – darunter Neustart und Anlagenupdate, bei denen jedes laufende Gespräch verloren geht, und den anlagenweiten Werksreset der Telefone. Nicht jede einzelne Operation dieser beiden Themen verlangt eine Rückfrage; das Vergeben des Administrationsrechts und das Scharfschalten einer Aktivität tun es. Geben Sie beide Themen nur frei, wenn Sie das bewusst wollen.
Rückfragen bei riskanten Aufrufen
Der Schutz greift an zwei voneinander unabhängigen Stellen:
- Im Client. Sobald ein Werkzeug irgendetwas verändern kann – also bei jeder Freigabe außer Lesen – fragt der Agent vor dem Aufruf beim Menschen nach. Diese Rückfrage erscheint auch dann, wenn der Client sonst alle Aufrufe automatisch erlaubt.
- Auf der Anlage. Gewichtige Operationen führen ohne ausdrückliche Bestätigung nichts aus, sondern beschreiben nur, was geschehen würde. Der Agent bekommt dabei keinen abstrakten Protokollfehler, sondern einen lesbaren Hinweis, den er Ihnen vorlegen kann. Das betrifft jede Löschung und jede ausführende Aktion – und zusätzlich einzelne Änderungen, deren Wirkung außer Verhältnis zu ihrem Aufwand steht: das Vergeben des Administrationsrechts, das Setzen eines Kennworts, das Verstellen der Systemzeit.
Wie fein das geschnitten ist, zeigen die Telefone. Ein holt nur die Konfiguration neu; das ist eine eigene Operation. Neustart und Werksreset der Geräte liegen in einer zweiten Operation mit fester Auswahlliste – jeder ihrer Werte ist störend, keiner lässt sich versehentlich mit einem harmlosen verwechseln. Eine frei getippte Zeichenkette, aus der versehentlich ein anlagenweiter Werksreset wird, gibt es an dieser Stelle nicht.
Nachvollziehbarkeit
Jeder Werkzeugaufruf erzeugt auf der Anlage ein Ereignis McpToolCalledEvent. Es enthält:
| Angabe | Inhalt |
|---|---|
| Zeitpunkt | wann der Aufruf einging |
| Token-Bezeichnung | welcher Token – nie der Token selbst |
| Herkunftsadresse | von welcher IP-Adresse |
| Werkzeug und Operation | was gemacht wurde |
| Betroffenes Objekt | eine Kurzangabe wie „17 groups" oder „created user Anna Meier" |
| Modus, Bestätigung, Dauer, Ergebnisgröße | wie es lief |
| Ergebnis | erfolgreich oder abgewiesen, bei Fehlern mit Grund |
Auch abgewiesene Anfragen erzeugen dieses Ereignis – mit der Angabe, woran es lag: gesperrte IP-Adresse, ungültiger Token, fehlende Lizenz, nicht freigegebenes Werkzeug, fehlende Bestätigung oder ein Löschversuch ohne Löschrecht. Das sind die Einträge, die in einem Syslog wirklich zählen.
Mit dem Modul EventBridge leiten Sie diese Ereignisse an einen Syslog-Server, einen Webhook oder in eine Datei weiter. Admin Power Pack braucht dafür keine eigene Protokollansicht und legt keine zusätzliche Tabelle an.
Die Argumente eines Aufrufs stehen bewusst nicht im Ereignis – sie können Klartextdaten enthalten, etwa einen Suchbegriff mit einem Personennamen. Was der Eintrag festhält, ist die Handlung: dass und was aufgerufen wurde und welches Objekt es betraf. Bei schreibenden Aufrufen nennt das betroffene Objekt naturgemäß auch dessen Namen – prüfen Sie das, wenn Sie die Ereignisse in ein System außerhalb Ihrer Kontrolle weiterleiten.
Grenzen
Damit keine falsche Erwartung entsteht:
- Kein Zugriff aus der Cloud von claude.ai. Die gehosteten Claude-Oberflächen verbinden sich aus dem Rechenzentrum des Anbieters heraus – Ihre Anlage müsste dafür öffentlich aus dem Internet erreichbar sein. Das ist weder die Realität unserer Installationen noch etwas, das wir empfehlen. Unterstützt sind Clients, die vom Rechner oder Netz des Kunden aus wählen: Claude Code, Claude Desktop, Cowork, VS Code, Cursor, n8n und eigene Agenten.
- Änderungen an den Freigaben erreichen laufende Clients nicht sofort. Ein Client liest die Werkzeugliste beim Verbinden. Nachdem Sie ein Werkzeug freigeschaltet oder gesperrt haben, muss er die Verbindung neu aufbauen, um es zu bemerken.
- Der Token ist ein Generalschlüssel im Rahmen der Freigaben. Er ist nicht an eine Person gebunden und kennt keine benutzerbezogenen Einschränkungen. Behandeln Sie ihn wie ein Administrationskennwort – eigener Token je Anbindung, IP-Filter davor, und bei Verdacht löschen und neu anlegen.
- Ein schreibender Agent auf einer Telefonanlage bleibt ein betrieblicher Eingriff. Die Rückfragen und die Spaltenfreigaben sind dafür da, den Rahmen eng zu halten. Nutzen Sie sie.
Anwendungsbeispiele
Störungsanalyse ohne Umweg
Situation: Ein Kunde meldet, dass ausgehende Gespräche sporadisch scheitern.
Anweisung: „Sind alle unsere Provider-Leitungen online?"
Ergebnis: Der Agent liest den Zustand aller Leitungen aus, stellt sie als Tabelle gegenüber und weist von sich aus auf die Auffälligkeit hin – im Beispiel rechts zwei Leitungen mit rund 1010 ms Antwortzeit, was verdächtig genau dem Zeitlimit der Erreichbarkeitsprüfung entspricht. Aus einer Messreihe wird damit sofort eine Vermutung, der man nachgehen kann.
Freigabe: Leitungen – Lesen.
Der Rufablauf um 09:30 Uhr
Situation: Ein Anrufer sagt, er sei gestern Vormittag in der Warteschleife gelandet, obwohl jemand da war.
Anweisung: „Was ist am 21.08. um 09:30 Uhr im Rufablauf passiert? Zeig mir die relevanten Logzeilen und erklär sie."
Ergebnis: Der Agent wählt die passende Logdatei, grenzt auf den Zeitraum ein und legt Ihnen die Kette aus Anrufeingang, Gruppenzustellung und Umleitung als Erklärung vor.
Freigabe: Protokolldateien – Lesen; Rufliste – Lesen.
Zwanzig neue Mitarbeiter
Situation: Zum Monatsersten kommen zwanzig Kollegen dazu, alle mit derselben Ausstattung.
Anweisung: „Lege die Benutzer aus dieser Liste an und wende auf alle die Vorlage ‚Innendienst' an."
Ergebnis: Der Agent legt die Konten an und wendet die Benutzervorlage an.
Freigabe: Benutzer – Lesen und Ändern; Benutzervorlagen – Lesen und Ausführen.
Weil alles, was verändert, im Client eine Rückfrage auslöst, fragt der Agent hier nicht einmal, sondern bei jedem Anlegen. Clients bieten dafür eine Antwort im Sinne von „für diese Aufgabe erlauben" an – das ist die Stelle, an der Sie sie sinnvoll einsetzen.
Anweisungen funktionieren am besten, wenn sie das Ergebnis beschreiben und nicht die Bedienung. Statt „Öffne die Rufliste und filtere auf gestern" lieber „Wie viele Anrufe hat die Zentrale gestern verpasst?" – die zweite Formulierung lässt dem Agenten die Wahl des Weges und liefert in aller Regel die bessere Antwort.
Kurz zusammengefasst
| Schritt | Wo |
|---|---|
| API-Token anlegen | Tab STARFACE Verwaltung → Card Sicherheit → API-Tokens |
| Server aktivieren | Tab Integrationen → Card MCP-Server → MCP-Server aktiv |
| IP-Filter setzen | dieselbe Card, Erlaubte IP-Adressen und Subnetze |
| Werkzeuge freigeben | dieselbe Card, Abschnitt Werkzeuge |
| Client verbinden | Snippet aus der Card in die Konfiguration des Agenten |
| Protokollierung einrichten | Modul EventBridge, Ereignis McpToolCalledEvent |
Die technische Referenz für Integratoren – Protokollversionen, Fehlercodes, vollständige Werkzeug- und Operationsliste – finden Sie unter API → MCP-Server. Die Grundlagen aller Fluxpunkt-Schnittstellen beschreibt der Artikel Schnittstellen & APIs.