Sisense Meta-Management MCP Server

⚠️ Hinweis zum experimentellen Projekt

Von Sisense Field Engineering beigetragenes Community-Tool

Dieses Projekt ist ein experimentelles Tool, das von Sisense Field Engineering entwickelt wurde, um Kunden das Lernen und die Erkundung der Sisense-Funktionen zu erleichtern. Es ist nicht Teil des Kernproduktlebenszyklus von Sisense und durchläuft nicht dieselben Validierungs-, Support- oder Zertifizierungsprozesse wie allgemein verfügbare (GA) Sisense-Funktionen. Es wird "wie besehen" bereitgestellt – siehe Support und Mitwirkung.

Ein standardkonformer MCP-Server, der Sisense-Umgebungsoperationen als KI-fähige Tools bereitstellt, unterstützt durch das PySisense-SDK: Governance, Asset- und Benutzer-/Gruppenverwaltung, Lebenszyklusaufgaben und Health-Checks – nicht Diagrammerstellung oder Analytics-Fragen.

Er funktioniert für jeden Sisense-Benutzer: Jeder Tool-Aufruf läuft mit den eigenen Sisense-Anmeldeinformationen des aufrufenden Benutzers, sodass Ergebnisse und Berechtigungen genau das sind, was dieser Benutzer in Sisense selbst sehen und tun kann, nativ von den Sisense-APIs durchgesetzt.

Nur Tools, kein Agent. Claude Desktop, Claude Code, claude.ai, Cursor – jeder MCP-Client bringt seinen eigenen Agenten mit; dieses Projekt bewirbt und führt ~100 kuratierte Tools aus (Dashboards, Datenmodelle, Benutzer/Gruppen, Ordner, Plugins, Health-Checks, …).

Architektur

Die moderne Form der MCP-Spezifikation, als zwei zusammenarbeitende Dienste, die als zwei Docker-Images (fes-auth, fes-mcp – aus einem mehrstufigen Dockerfile mit gemeinsamen Layern) ausgeliefert werden:

• fes-auth – der Autorisierungsserver (AS). Verwaltet alles darüber, wer aufruft: OAuth 2.1 für MCP-Clients (PKCE, dynamische Client-Registrierung, Discovery), die Browser-Anmeldeseite und den Anmeldeinformations-Tresor, der jedes ausgestellte MCP-Token dem Sisense-Token des Benutzers zuordnet. Er leitet jeden Tool-Aufruf an den Ressourcenserver weiter, wobei die Sisense-Anmeldeinformationen eingefügt werden.

• fes-mcp – der Ressourcenserver (RS). Zustandslos, OAuth-unbewusst. Liest die injizierten Anmeldeinformationen aus jeder Anfrage, verifiziert sie gegen Sisense (zwischengespeichert) und führt das Tool als dieser Benutzer gegen diese Sisense-Instanz aus.

flowchart LR
    subgraph clients [MCP clients]
        C1[Claude Desktop]
        C2[Claude Code]
        C3[claude.ai / Cursor]
    end

    subgraph box [one host - docker compose]
        subgraph AS [fes-auth : authorization server]
            O[OAuth 2.1\nPKCE + DCR + discovery]
            L[/login page/]
            V[(vault\nMCP token → Sisense credential)]
            P[/mcp proxy\ninjects credential headers/]
        end
        subgraph RS [fes-mcp : resource server]
            T[Tool layer\nregistry-driven, ~100 tools]
            D[Dispatcher\nper-credential PySisense client]
        end
    end

    R[(tool registry JSON\nauto-generated from SDK)] -.defines.-> T

    C1 & C2 & C3 -- "MCP over HTTPS\nBearer <MCP token>" --> P
    C1 & C2 & C3 -. "browser: sign in once" .-> L
    P -- "Authorization: Bearer <Sisense token>\nX-Sisense-Url: <instance>\n(internal network only)" --> T
    T --> D
    D -- "REST, as the signed-in user" --> F[(Sisense Fusion Deployment)]

Die Naht zwischen den beiden Diensten sind nur diese beiden Header plus der 401-Vertrag, sodass sich jede Hälfte weiterentwickeln – oder ersetzt werden – kann, ohne dass die andere es bemerkt. Es gibt bewusst kein gemeinsames Geheimnis zwischen den beiden – Vertrauen ist das interne Netzwerk (der Port des RS wird nie veröffentlicht).

Anmeldeablauf (was ein Benutzer erlebt)

Jeder Benutzer fügt den Connector einmal in seinem MCP-Client hinzu und benennt seine eigene Sisense-Instanz in der URL:

https://your-host/mcp?target=https://acme.sisense.com

sequenceDiagram
    participant U as User (browser)
    participant C as MCP client
    participant A as fes-auth
    participant S as Sisense

    C->>A: POST /mcp?target=<sisense url>  (no token)
    A-->>C: 401 + resource metadata URL (carries target)
    C->>A: discovery + client registration (RFC 7591)
    C->>U: open browser at A's /login
    Note over U,A: target present → instance fixed,<br/>only username/password asked<br/>(no target → domain field shown)
    U->>A: username/password (or API token for SSO)
    A->>S: POST /api/v1/authentication/login
    S-->>A: user's Sisense token (kept server-side, in the vault)
    A-->>C: authorization code → MCP access token (PKCE)
    Note over C,A: from here, silent — token refresh is automatic

Der Client sieht niemals Sisense-Anmeldeinformationen; der Server speichert niemals Passwörter (einmal verwendet, um das Token des Benutzers zu prägen, dann verworfen). Benutzer auf SSO/MFA-Instanzen melden sich an, indem sie stattdessen ihr persönliches Sisense-API-Token einfügen.

Tool-Aufruf (Dauerzustand)

sequenceDiagram
    participant C as MCP client
    participant A as fes-auth (proxy)
    participant R as fes-mcp (tools)
    participant S as Sisense (target)

    C->>A: POST /mcp  (Bearer <MCP token>)
    A->>A: validate token → vault → Sisense credential
    A->>R: same request + Authorization: Bearer <Sisense token><br/>+ X-Sisense-Url: <instance>
    R->>S: verify credential (TTL-cached) · SDK call as that user
    S-->>R: result (user's permissions, user in audit log)
    R-->>A: MCP response (streamed)
    A-->>C: MCP response (streamed)

Lebenszyklus der Anmeldeinformationen und Selbstheilung

• Der Ressourcenserver verifiziert jedes (Instanz, Token)-Paar erneut gegen Sisense nach FES_MCP_VERIFY_TTL Sekunden (Standard 300). Ein in Sisense widerrufenes Token wird innerhalb dieses Fensters zu einem HTTP-401.

• fes-auth behandelt einen RS-401 als Anmeldeinformationen tot: Es löscht den Tresoreintrag und fordert den MCP-Client erneut auf, dessen nächster Schritt die erneute Ausführung des Anmeldeablaufs ist. Die serverseitige Widerrufung verbreitet sich also ohne manuelle Schritte.

• Sitzungen sind bewusst im Speicher (keine Datenbank): Ein Neustart von fes-auth meldet alle ab – der nächste Aufruf jedes Benutzers öffnet die Browser-Anmeldung erneut (mit ?target= gesetzt, ist das nur Benutzername/Passwort). Ein Neustart von fes-mcp ist unsichtbar: Es hält keinen Zustand.

Bereitstellung (docker compose)

docker compose up --build

Dies baut die beiden Images (docker build --target fes-auth|fes-mcp) und veröffentlicht nur fes-auth auf :8200; fes-mcp bleibt intern. Beenden Sie TLS davor (ALB / nginx / Caddy) – MCP-Clients erfordern HTTPS für OAuth – und setzen Sie FES_MCP_PUBLIC_URL auf diese öffentliche URL:

FES_MCP_PUBLIC_URL=https://your-host.example.com docker compose up -d --build

Benutzer fügen dann https://your-host.example.com/mcp?target=https://their-instance.sisense.com als benutzerdefinierten Connector hinzu. Der ?target=-Teil ist optional – ohne ihn fragt die Anmeldeseite nach der Sisense-URL als drittes Feld.

Endpunkte auf fes-auth: /mcp (proxied MCP), /login, /.well-known/* + /authorize + /token + /register (OAuth 2.1), / (Status), /healthz. Härtung enthalten: Login-Ratenbegrenzung pro IP, CSRF-geschütztes Anmeldeformular, Zugriffsprotokolle mit Anforderungs-IDs.

Schnellstart (lokale Entwicklung)

Erfordert Python 3.11+ und uv. Die lokale Entwicklung überspringt den AS vollständig: Der stdio-Transport verwendet standardmäßig env-Authentifizierung – eine Anmeldeinformation aus .env, alles läuft als Sie.

uv sync
cp .env.example .env   # set SISENSE_DOMAIN / SISENSE_TOKEN
uv run fes-mcp         # stdio transport

MCP-Client-Konfiguration (z. B. claude_desktop_config.json):

{
  "mcpServers": {
    "sisense": {
      "command": "uv",
      "args": ["run", "--directory", "/absolute/path/to/fes_mcp", "fes-mcp"]
    }
  }
}

Um die vollständige Aufteilung lokal ohne Docker auszuführen:

FES_MCP_TRANSPORT=http uv run fes-mcp &                 # RS on :8200 (upstream auth)
FES_MCP_PORT=8300 FES_MCP_RS_URL=http://127.0.0.1:8200 uv run fes-auth
# connector: http://127.0.0.1:8300/mcp?target=https://your.sisense.com

Layout

• src/fes_mcp/ – settings (Env-Konfiguration) · registry (Laden/Filter) · dispatcher (Per-Credential-SDK-Dispatch) · upstream (RS-Anmeldeinformationsverifizierung) · auth (OAuth-Anbieter + Anmeldeseite) · authserver (fes-auth-Dienst + Proxy) · middleware (Zugriffsprotokolle) · server (FastMCP-Assembly)

• config/tools.registry.with_examples.json – automatisch generierte Tool-Registry. Niemals von Hand schreiben; mit ./refresh_registry.sh neu generieren, wenn PySisense aktualisiert wird.

• config/allowlist.txt – die kuratierte Tool-Oberfläche, ein Tool pro Zeile. Löschen/Kommentieren Sie eine Zeile, um ein Tool zu entfernen. Nicht aufgeführte Tools werden nie exponiert, sodass Registry-Aktualisierungen die Oberfläche nicht stillschweigend erweitern können. (Migrationstools sind bewusst nicht aufgeführt – sie benötigen eine Dual-Instanz-Verbindung, die dieser Server nicht modelliert.)

• Mutierende Tools sind hinter FES_MCP_ALLOW_MUTATIONS=true geschaltet – siehe Sicherheit für die vollständigen Mutationsschutzmaßnahmen.

Technische und sicherheitsrelevante Überlegungen

Umgang mit Anmeldeinformationen

Der MCP-Client sieht niemals Sisense-Anmeldeinformationen, und der Server speichert niemals Passwörter – ein Passwort wird einmal gegen die Sisense-Login-API verwendet, um das eigene Token des Benutzers zu prägen, dann verworfen. Sisense-Tokens leben im In-Memory-Tresor von fes-auth, verknüpft mit dem MCP-Zugriffstoken, und überleben die Refresh-Rotation. Im Entwicklungsmodus bleibt die einzelne Env-Anmeldeinformation (SISENSE_DOMAIN/SISENSE_TOKEN) auf Ihrem Rechner. Nichts wird auf der Festplatte gespeichert: Ein Neustart von fes-auth löscht den Tresor (alle melden sich erneut an) – der bewusste Kompromiss für keine Datenbank und keine Verschlüsselung-at-Rest-Oberfläche.

Härtung auf der gehosteten Oberfläche: Login-Ratenbegrenzung pro IP, CSRF-geschütztes Anmeldeformular, Zugriffsprotokolle mit Anforderungs-IDs und Tool-Protokolle pro Aufruf (Tool / Benutzerdomäne / Ergebnis / Dauer).

Autorisierung

Nichts Benutzerdefiniertes: Autorisierung ist Sache von Sisense. Jeder Tool-Aufruf läuft mit dem eigenen Sisense-Token des aufrufenden Benutzers, sodass Sisense seine echten Berechtigungen bei jedem API-Aufruf durchsetzt und Berechtigungsfehler dem Client wörtlich angezeigt werden. Deshalb ist der Server auch nicht nur für Administratoren – jeder Sisense-Benutzer erhält genau seinen eigenen Umfang.

Vertrauen zwischen den beiden Diensten

Das Vertrauen zwischen fes-auth ↔ fes-mcp ist auf Netzwerkebene: kein gemeinsames Geheimnis. Der Port des RS darf niemals von außerhalb des internen Netzwerks erreichbar sein (compose veröffentlicht nur fes-auth). Defense in Depth: FES_MCP_ALLOWED_SISENSE_ORIGINS legt fest, welche Sisense-Ursprünge der RS in X-Sisense-Url akzeptiert.

Mutationen

Mutierende Tools werden nur exponiert, wenn FES_MCP_ALLOW_MUTATIONS=true gesetzt ist, tragen immer destructiveHint, werden serverseitig als zweite Ebene blockiert, wenn deaktiviert, und werden in ein Mutations-Audit-Log geschrieben.

Darüber hinaus fragen mutierende Tools den Menschen vor der Ausführung um Genehmigung – über MCP-Elicitation, auf Clients, die die Fähigkeit deklarieren (Claude Code, Cursor, VS Code). Ein Fortfahren/Abbrechen-Dialog öffnet sich mitten im Aufruf und legt die genauen Argumente offen; Abbrechen oder Ablehnen ändert nichts. Auf Clients ohne Elicitation (Claude Desktop, claude.ai) läuft der Aufruf normal weiter, und der eigene Tool-Genehmigungsablauf des Clients plus die destructiveHint-Annotation sind die Absicherung, wie bei jedem MCP-Server.

Das Fortfahren ohne den Dialog ist eine bewusste Entscheidung (Fail-Open), kein Versehen: Elicitation ist eine optionale Client-Fähigkeit und kann von einem fehlverhaltenden Client automatisch beantwortet werden, daher wird sie streng als UX behandelt – die Autorisierungsgrenze ist immer die eigenen Sisense-Berechtigungen des Benutzers.

Datenfluss zum LLM-Anbieter

Dieser Server hat keine Zusammenfassungs- oder Datenredaktionsschicht: Jedes Tool-Ergebnis – vollständige Zeilen, nicht {ok, count}-Metadaten – wird an den MCP-Client zurückgegeben und landet im Kontext des Modells. Das ist beabsichtigt und macht mehrstufige Tool-Verkettung möglich: Das Modell kann nur über die Daten nachdenken, sie filtern und die Ausgabe eines Tools in den nächsten Aufruf einspeisen, wenn es die Daten tatsächlich sieht.

Die Konsequenz: Wer diesen Server mit einem MCP-Client verbindet, akzeptiert, dass Sisense-Daten (Dashboard-Inhalte, Abfrageergebnisse, Benutzerlisten, …) an den LLM-Anbieter dieses Clients fließen – z. B. Anthropic für Claude – unter den eigenen Bedingungen mit diesem Anbieter. Der Server kann dies nicht durchsetzen oder eingrenzen; es ist eine bewusste Akzeptanz pro Bereitstellung.

Empfohlene Nutzungsrichtlinien

• Beginnen Sie schreibgeschützt: Behalten Sie FES_MCP_ALLOW_MUTATIONS=false (Standard), bis Sie Vertrauen in einer Nicht-Produktionsumgebung aufgebaut haben.

• Kuratieren Sie config/allowlist.txt auf die Tools, die Ihre Bereitstellung tatsächlich benötigt – weniger Tools bedeuten weniger Datenexposition und eine klarere Genehmigungsgeschichte.

• Bevorzugen Sie Nicht-Produktions-Sisense-Instanzen beim Erkunden; die Tools sind nur so sicher wie die Berechtigungen des angemeldeten Benutzers.

• Testen Sie destruktive Operationen mit einem MCP-Client, der Elicitation unterstützt (Claude Code, Cursor), damit Sie die Bestätigungsdialoge sehen.

Konfiguration

Tests

uv run python -m pytest

(python -m ist wichtig: Es setzt das Repo-Root auf sys.path, worauf die Importe der Testmodule from tests.conftest import … angewiesen sind.)

49 Tests, ohne Netzwerk und ohne Anmeldedaten (Sisense und das SDK sind gemockt): Registry-Auswahl, Dispatcher-Validierung/Fehler, MCP-Roundtrips, Mutationsbestätigung (approve/abort/decline/no-capability), Upstream- Anmeldedatenprüfung (injizierte Header, 401-Vertrag, Origin-Allowlist, TTL-Widerruf) sowie die vollständige AS+RS-Aufteilung — OAuth-Ablauf mit und ohne ?target=, Discovery-Metadaten, proxierte Tool-Aufrufe, Refresh-Rotation, Self-Healing bei Widerruf auf Sisense-Seite, plus die Missbrauchspfade (gefälschtes CSRF, Brute-Force-Ratenlimit, abgelaufene Sitzungen).

Registry-Regenerierung

./refresh_registry.sh   # rebuild config/ from the installed PySisense SDK

Neue SDK-Methoden landen in der Registry, bleiben aber verborgen, bis sie explizit zu config/allowlist.txt hinzugefügt werden.

Support und Mitwirkung

Dies ist ein experimentelles, von der Community beigetragenes Projekt, das von Sisense Field Engineering gepflegt und "wie besehen" bereitgestellt wird.

• Kein GSS-Ticket eröffnen — dies ist kein GA-Sisense-Feature.

• Bei Nutzungsfragen oder Hilfe für den Einstieg wenden Sie sich an Ihren Customer Success Manager (CSM), der Feedback an das Field-Engineering-Team weiterleitet.

• Issues und Beiträge sind über das Repository willkommen.

Lizenz

MIT