MCP oder GUI: Die passende Oberfläche für einen Unternehmensvorgang

Ein Gespräch mit einem Agenten hilft, ein Ticket nach seiner Bedeutung zu finden und eine Änderung vorzubereiten. Vor dem Schreiben ist ein Formular, das alten und neuen Wert zeigt, oft besser. MCP verbindet eine Anwendung mit Werkzeugen; wer ein Ticket ändern darf, entscheidet weiterhin Ihr System.

Dieses Lehrszenario für einen internen Service Desk beschreibt keine fertige Integration eines bestimmten Produkts. Ein Mitarbeiter liest ein Ticket, schlägt einen neuen Bearbeiter vor und gibt die Änderung zur Bestätigung weiter. Tool- und Feldnamen sind nur Entwurfsbeispiele; sie müssen im gewählten System umgesetzt und geprüft werden.

Lesen, Vorschlag und Schreiben trennen

In der MCP-Architektur arbeitet eine Host-Anwendung über Clients mit Servern; Server stellen Tools und weitere Fähigkeiten bereit. Ein passend benanntes Tool verleiht einem Benutzer noch keine fachliche Berechtigung.

Aktion	Sinnvolle Startoberfläche	Zugangsbedingung
Ein zugängliches Ticket finden	MCP und Gespräch	Der Server begrenzt Ergebnisse durch Benutzerrechte
Neuen Bearbeiter vorschlagen	MCP für den Entwurf; Formular zum Vergleich	Der Vorschlag ändert den Datensatz nicht
Änderung bestätigen	GUI oder getestetes MCP-Apps-Formular	Exakte Felder sichtbar; Server prüft Rechte und Aktualität erneut

Das ist eine Entwurfsempfehlung für diesen Fall. Auch eine gewöhnliche GUI kann wesentliche Werte verbergen oder ein schlecht geschütztes Backend aufrufen. Bewerten Sie den wirklichen Schreibpfad und den Nachweis, dass er funktioniert.

Nehmen wir an, das Übungsticket REQ-204 hat team-a als Bearbeiter, der Nutzer möchte team-b. Das Gespräch findet das Objekt; vor dem Speichern müssen jedoch ID, alter Wert, neuer Wert und Folgen angezeigt werden: Benachrichtigung, Zugriffswechsel oder externe Aktion. Gleiche Titel reichen zur Objektauswahl nicht aus.

Die Bestätigung muss genau diese Änderung betreffen

Ein internes Bestätigungsobjekt kann so aussehen:

{
  "ticket_id": "REQ-204",
  "expected_revision": "r17",
  "changes": {
    "assignee": {"from": "team-a", "to": "team-b"}
  },
  "mode": "proposal"
}

Dies ist ein Anwendungsschema, kein MCP-Standard. Beim Speichern muss der Server revision und Berechtigungen vergleichen. Hat sich das Ticket verändert, ist der Vorschlag erneut zu zeigen. Eine Bestätigungsschaltfläche darf nicht unbemerkt einen anderen diff anwenden.

Der Abschnitt Tools der MCP-Spezifikation beschreibt sichtbare Aufrufe, die Möglichkeit, dass ein Mensch eine Aktion ablehnt, sowie serverseitige Prüfung von Eingabe und Zugriff. Das Protokoll schreibt keine Bestätigungsoberfläche vor. Zugang zu einem MCP-Server ist daher keine Erlaubnis für jeden Unternehmensvorgang.

Legen Sie das Backend-Verhalten nach einem timeout vorher fest. Geht die Antwort verloren, fragen Sie zuerst das Operationsergebnis über die aufbewahrte Kennung ab. Blindes Wiederholen kann eine Benachrichtigung oder externe Wirkung doppelt auslösen. Den alten Bearbeiter zurückzusetzen macht nicht jede Folge rückgängig.

Wann MCP Apps passt

MCP Apps erlaubt einem Server-Tool, in einem unterstützenden Client eine interaktive UI bereitzustellen. Der Host rendert sie in einem sandboxed iframe. Das eignet sich für den Feldvergleich im Gespräch, wenn die gewählten Client- und Serverversionen die Erweiterung unterstützen.

Das Formular kann Ticket, vorgeschlagenen diff und die klaren Schaltflächen Anwenden und Abbrechen zeigen. Serverautorisierung, revision-Prüfung und Ergebnisprotokoll bleiben erforderlich. Ein sandboxed iframe ersetzt weder Service-Desk-Rechte noch macht er einen beliebigen Server vertrauenswürdig.

Behalten Sie eine getrennte GUI, wenn der aktuelle Client den diff nicht zuverlässig zeigen, die Unternehmensbestätigung nicht durchführen oder die nötige Barrierefreiheit nicht bieten kann. Ist das Modell nicht verfügbar, muss eine Person das Ticket per ID öffnen und seinen tatsächlichen Zustand prüfen können. Ein Modellausfall darf keine Unklarheit darüber lassen, ob die Änderung gespeichert wurde.

Pilot: Modell über BetterToken, Tickets über MCP

Nutzen Sie Claude Desktop als Client und verbinden Sie ein Claude-Modell über BetterToken mit dem API-Einrichtungsleitfaden. Verwenden Sie Ihren eigenen API Key mit Zugang zum Claude-Provider und Gateway Base URL https://bettertoken.ai; prüfen Sie genaue Felder und Bedingungen für Ihre Version im Leitfaden. Lassen Sie zuerst eine normale kurze Nachricht beantworten, um die Modellverbindung getrennt zu testen.

Verbinden Sie danach mit dem gewählten Client einen Test-MCP-Server des Service Desk und prüfen Sie Zugriff auf ein nicht geheimes Ticket. BetterToken stellt die Modell-API-Schicht bereit; Service-Desk-Zugangsdaten, Benutzerrechte und Schreibbestätigung werden getrennt eingerichtet. Eine Modellverbindung beweist MCP-Apps-Unterstützung in einem Clientmodus nicht; prüfen Sie sie vor der Wahl eines eingebetteten Formulars. Fehlt sie, bleibt die Bestätigung in der GUI.

Verbinden Sie das Modell über BetterToken für das Testszenario und führen Sie dann die folgenden Prüfungen durch. Verwenden Sie fiktive Daten: MCP-Antwortinhalt, der an das Modell geht, kann in eine API-Anfrage gelangen. Die Erlaubnis für echte Unternehmensdaten muss den Regeln Ihrer Organisation entsprechen.

Entscheidung bei Ausfällen prüfen

Führen Sie die Übung in einer Testumgebung mit zwei Rollen und nicht geheimen Tickets aus. Eine Rolle darf Bearbeiter ändern, die andere nur zugelassene Datensätze lesen. Bewahren Sie das tatsächliche Ergebnis jeder Prüfung auf; die Tabelle enthält erwartete Kriterien, keinen Testbericht.

Prüfung	Erwartetes Ergebnis
Nutzer fordert fremdes, unzugängliches Ticket an	Server lehnt ohne Inhaltsfreigabe ab
Lesende Rolle bestätigt Bearbeiterwechsel	Server weist das Schreiben zurück
Nutzer bricht vorgeschlagenen diff ab	Ticket bleibt unverändert
revision ändert sich nach dem Lesen	Speichern stoppt; neues Lesen ist nötig
Antwort nach Speichern geht verloren	Status vor Wiederholung feststellen
Modell ist nicht verfügbar	GUI zeigt den tatsächlichen Zustand
Tastatur und Screen Reader werden genutzt	Änderung ist verständlich, bestätigbar oder abbrechbar

Scheitert eine Prüfung, bleibt diese Art von Schreiben in der bestehenden getesteten Oberfläche, bis die Ursache behoben ist. Lesen über MCP kann separat beurteilt werden und braucht ebenfalls Rechte und Ergebnisgrenzen.

Audit-Spur hinterlassen

Protokollieren Sie Benutzer, Ticket-ID, akzeptierten diff, Ausgangsrevision, Zeit, Operations-ID und Backend-Ergebnis. Speichern Sie tokens oder vollständige Inhalte beschränkter Tickets nicht ohne Bedarf. Aufbewahrung und Zugriff auf das Protokoll müssen den Organisationsregeln entsprechen.

Dokumentieren Sie nach dem Pilot für jede Aktion die Entscheidung: Lesen im Gespräch, Vorbereitung als Entwurf, Schreiben im gewählten getesteten Formular. Fügen Sie Ergebnisse der Ausfalltests und einen Verantwortlichen für offene Probleme bei. Erweitern Sie MCP nur für Vorgänge, deren Rechte, Bestätigung und Wiederherstellung nach Fehlern verstanden sind.