Zum Inhalt
Copyright © 2022-2026 basebox GmbH, all rights reserved.
Licensed to be used in conjunction with basebox, only.

// integration

MCP-Client

Gilt für

Produkt: Cloud · Server · Zielgruppe: Entwickler / Integrator · Sicherheitsprüfer

Wie der basebox-Assistent als MCP-Client arbeitet: Werkzeuge entdecken, entscheiden, wann ein Werkzeug aufgerufen wird, Ergebnisse zurückführen – und was Nutzer davon in der Oberfläche sehen. Das Model Context Protocol (MCP) ist der Standard, über den basebox Konnektoren anbindet; jeder Konnektor ist ein MCP-Server, der Anwendungsserver AISRV ist der Client.

Die Rollen

Rolle Wer Aufgabe
MCP-Client AISRV (das MCP-Gateway in basebox) Verbindet sich mit MCP-Servern, holt deren Werkzeugliste, führt Aufrufe aus, wahrt Berechtigungen
MCP-Server Ein Konnektor – Websuche, DokuWiki, YouTrack, Ihr eigener Stellt Werkzeuge bereit und spricht mit dem angebundenen System
Modell Das Sprachmodell Entscheidet anhand der Frage, ob und welches Werkzeug es aufruft

Ablauf eines Werkzeugaufrufs

  1. Anfrage. Ein Nutzer sendet eine Nachricht; AISRV validiert das Token und kennt damit die user_id.
  2. Werkzeuge bestimmen. AISRV lädt zwei Listen und bildet die Schnittmenge: Welche Konnektoren die aktuelle App freigibt, und welche der Nutzer selbst aktiviert (und – wo nötig – mit eigenen Zugangsdaten versehen) hat. Nur diese Werkzeuge existieren für diese Unterhaltung.
  3. Angebot an das Modell. Die erlaubten Werkzeuge werden dem Modell zusammen mit dem Prompt beschrieben. Das Modell entscheidet, ob ein Werkzeug hilft.
  4. Abfangen. Beschließt das Modell einen Aufruf, führt basebox ihn nicht blind aus, sondern setzt zuerst die Zugangsdaten dieses Nutzers in die Verbindungskonfiguration ein – daraus entsteht ein Authorization-Header (Bearer oder Basic).
  5. Aufruf. AISRV sendet POST /mcp an den MCP-Server mit diesem Header. Der Server reicht ihn an das angebundene System weiter; das System wendet seine eigenen Berechtigungen an.
  6. Ergebnis als Daten. Das Werkzeugergebnis kommt zurück und wird als Daten gerahmt – nie als Anweisungen –, bevor es dem Modell für die finale Antwort vorgelegt wird. Das ist die Schutzmaßnahme gegen Prompt-Injection über Werkzeugergebnisse.
  7. Antwort. Die Antwort wird an den Nutzer gestreamt.

Das Sequenzdiagramm mit allen Schritten und die Sicherheitseigenschaften stehen unter MCP-Berechtigungs- und Autorisierungsablauf.

Was der Client garantiert

  • Kein gemeinsames Admin-Token. Jeder Aufruf trägt die Zugangsdaten des anfragenden Nutzers; basebox filtert nie zentral abgerufene Daten je Nutzer.
  • Kein Caching über Nutzer hinweg. Zugangsdaten werden je Anfrage frisch geladen; Ergebnisse werden nicht zwischen Nutzern geteilt.
  • Schreibzugriff standardmäßig aus. Werkzeuge, die erstellen, ändern oder löschen, sind je App deaktiviert, bis ein Administrator sie freigibt.
  • Egress-Allowlist. Ein Konnektor-Container erreicht nur die Hosts seines deklarierten Zielsystems; alles andere blockiert das MCP-Gateway – auch dann, wenn der Konnektor es versuchte.
  • Sofortiger Rechteentzug. Wird ein Token widerrufen oder ein Konto deaktiviert, scheitert der nächste Aufruf; es gibt keine nachwirkende Sitzung.
  • Zugangsdaten nie im Log – außer auf Level DEBUG in gezielten Diagnoseläufen.

Was Nutzer sehen

  • Unter dem „+"-Symbol in der Eingabezeile die Konnektoren, die für sie und die aktuelle App freigegeben sind – dort tragen sie auch persönliche Tokens ein.
  • Während eines Aufrufs einen Fortschrittshinweis: welcher Konnektor, welches Werkzeug, wie lange schon.
  • Bei der Websuche vor der ersten Suche eine Zustimmungsabfrage; der Schalter „Web" setzt sich beim Verlassen des Chats zurück.
  • Links auf Inhalte des angebundenen Systems öffnen sich in einem neuen Tab.
  • Im Audit-Log jeden Werkzeugaufruf als Metadaten (Organisation, Nutzer, Werkzeug, Anbieter, Ergebnis, Zeitstempel) – bei der Websuche ohne den Anfragetext.

Transport und Anforderungen an MCP-Server

basebox spricht MCP-Server über HTTP an: Endpunkt in der Regel /mcp, im Cluster etwa http://mcp-<name>:8000/mcp. Ein MCP-Server, der zu basebox passen soll, muss

  • den vom Chart konfigurierten HTTP-Transport unterstützen,
  • den Authorization-Header unverändert an das Zielsystem weiterreichen (bei Konnektoren mit persönlichen Zugangsdaten),
  • Werkzeuge klar beschreiben (Name, Zweck, Parameter), damit das Modell sie richtig einsetzt,
  • Ergebnisse begrenzt und strukturiert zurückgeben,
  • als Non-Root-Container laufen und Readiness-/Liveness-Probes bedienen.

Wie Sie einen solchen Server bereitstellen: MCP-Server anbinden. Wie Sie ihn entwerfen: Konnektoren entwickeln.

Was der Client nicht tut

  • Er hält keine Kopie der Berechtigungen des angebundenen Systems.
  • Er bildet basebox-Rollen nicht auf Rollen des Zielsystems ab.
  • Er ruft Werkzeuge nicht ohne Entscheidung des Modells auf – und das Modell sieht nur, was App und Nutzer freigegeben haben.
  • Er ist über die OpenAI-kompatible API nicht verfügbar: API-Anfragen laufen im Namen der Organisation, nicht einer Person, und tragen deshalb keine persönlichen Konnektor-Zugangsdaten. Tool Calling über die API meint Funktionen, die Ihre Anwendung definiert und ausführt.

Weiter: MCP-Übersicht · Autorisierungsablauf · Einführung in die Websuche-Sicherheit