Sisense Meta-Management MCP Server

⚠️ 実験的プロジェクトに関するお知らせ

Sisenseフィールドエンジニアリングによるコミュニティ貢献ツール

このプロジェクトは、Sisenseフィールドエンジニアリングが、お客様のSisense機能の学習と探索を支援するために開発した実験的なツールです。これはSisense製品のコアリリースライフサイクルの一部ではなく、一般提供（GA）されているSisense機能と同じ検証、サポート、認証プロセスは受けていません。**「現状のまま」**提供されます — サポートと貢献を参照してください。

標準準拠のMCPサーバーで、Sisense環境の操作をAI対応ツールとして公開します。PySisense SDKを基盤とし、ガバナンス、アセットおよびユーザー/グループ管理、ライフサイクルタスク、健全性チェックを提供します — チャート作成や分析Q&Aは対象外です。

あらゆるSisenseユーザーに対応します。すべてのツール呼び出しは、呼び出し元ユーザー自身のSisense資格情報で実行されるため、結果と権限は、そのユーザーがSisense内で実際に表示・実行できる内容と正確に一致し、SisenseのAPIによってネイティブに強制されます。

ツールのみ、エージェントは含みません。 Claude Desktop、Claude Code、claude.ai、Cursor — どのMCPクライアントも独自のエージェントを持ちます。このプロジェクトは、約100の厳選されたツール（ダッシュボード、データモデル、ユーザー/グループ、フォルダー、プラグイン、ヘルスチェックなど）を公開し実行します。

アーキテクチャ

MCP仕様の最新の形態として、2つの連携サービスとして提供され、2つのDockerイメージ（fes-auth、fes-mcp — 共有レイヤーを持つ単一のマルチステージDockerfileから構築）として出荷されます：

• fes-auth — 認可サーバー（AS）。誰が呼び出しているかに関するすべてを管理します：MCPクライアント向けOAuth 2.1（PKCE、動的クライアント登録、ディスカバリー）、ブラウザーサインインページ、発行された各MCPトークンをユーザーのSisenseトークンにマッピングする資格情報ボールト。すべてのツール呼び出しを、Sisense資格情報を注入してリソースサーバーにプロキシします。

• fes-mcp — リソースサーバー（RS）。ステートレスで、OAuthを認識しません。各リクエストから注入された資格情報を読み取り、Sisenseに対して検証（キャッシュ付き）し、そのユーザーとしてそのSisenseインスタンスに対してツールを実行します。

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)]

2つのサービス間の接続は、これら2つのヘッダーと401契約のみです。そのため、各半分は相手に気づかれることなく進化または置き換えが可能です。2つの間に共有シークレットは意図的に存在しません — 信頼は内部ネットワークです（RSのポートは公開されません）。

サインインフロー（ユーザーが体験する流れ）

各ユーザーは、MCPクライアントでコネクターを一度追加し、URLに自分のSisenseインスタンスを指定します：

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

クライアントがSisense資格情報を見ることはなく、サーバーはパスワードを保存しません（ユーザーのトークンを発行するために一度だけ使用され、その後破棄されます）。SSO/MFAインスタンスのユーザーは、個人のSisense APIトークンを貼り付けてサインインします。

ツール呼び出し（定常状態）

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)

資格情報のライフサイクルと自己修復

• リソースサーバーは、FES_MCP_VERIFY_TTL秒（デフォルト300）後に、各（インスタンス、トークン）ペアをSisenseに対して再検証します。Sisenseで失効したトークンは、そのウィンドウ内でHTTP 401になります。

• fes-authはRSの401を資格情報の失効として扱います：ボールトエントリを削除し、MCPクライアントに再チャレンジします。クライアントは次のステップでサインインフローを再実行します。したがって、サーバー側の失効は手動操作なしで伝播します。

• セッションは設計上インメモリです（データベースなし）：fes-authを再起動すると全員がサインアウトします — 各ユーザーの次の呼び出しでブラウザーログインが再度表示されます（?target=が設定されている場合は、ユーザー名/パスワードのみ）。fes-mcpの再起動は不可視です：状態を保持しません。

デプロイ（docker compose）

docker compose up --build

これにより2つのイメージがビルドされ（docker build --target fes-auth|fes-mcp）、fes-authのみが:8200で公開されます。fes-mcpは内部に留まります。前面でTLSを終了させ（ALB / nginx / Caddy — MCPクライアントはOAuthにHTTPSを要求）、FES_MCP_PUBLIC_URLをその公開URLに設定します：

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

ユーザーはhttps://your-host.example.com/mcp?target=https://their-instance.sisense.comをカスタムコネクターとして追加します。?target=部分はオプションです — 省略すると、ログインページでSisense URLを3番目のフィールドとして尋ねられます。

fes-authのエンドポイント：/mcp（プロキシされたMCP）、/login、/.well-known/* + /authorize + /token + /register（OAuth 2.1）、/（ステータス）、/healthz。強化対策：IPごとのログインレート制限、CSRF保護されたログインフォーム、リクエストID付きアクセスログ。

クイックスタート（ローカル開発）

Python 3.11以上とuvが必要です。ローカル開発ではASを完全にスキップします：stdioトランスポートはデフォルトでenv認証を使用 — .envからの1つの資格情報で、すべてがあなたとして実行されます。

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

MCPクライアント設定（例：claude_desktop_config.json）：

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

Dockerなしで完全な分割をローカルで実行する場合：

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

レイアウト

• src/fes_mcp/ — settings（環境設定） · registry（ロード/フィルター） · dispatcher（資格情報ごとのSDKディスパッチ） · upstream（RS資格情報検証） · auth（OAuthプロバイダー + ログインページ） · authserver（fes-authサービス + プロキシ） · middleware（アクセスログ） · server（FastMCPアセンブリ）

• config/tools.registry.with_examples.json — 自動生成されたツールレジストリ。手書きは禁止。PySisenseが更新されたら./refresh_registry.shで再生成します。

• config/allowlist.txt — 厳選されたツールサーフェス。1行に1ツール。行を削除/コメントアウトするとツールが削除されます。リストにないツールは公開されないため、レジストリの更新によってサーフェスが静かに拡大することはありません。（移行ツールは意図的にリストに含まれていません — このサーバーがモデル化しないデュアルインスタンス接続が必要です。）

• 変更を伴うツールはFES_MCP_ALLOW_MUTATIONS=trueの背後にゲートされています — 完全な変更保護策についてはセキュリティを参照してください。

技術的およびセキュリティ上の考慮事項

資格情報の取り扱い

MCPクライアントがSisense資格情報を見ることはなく、サーバーはパスワードを保存しません — パスワードはSisenseのログインAPIに対して一度だけ使用され、ユーザー自身のトークンを発行した後、破棄されます。Sisenseトークンはfes-authのインメモリボールトに保存され、MCPアクセストークンにキー付けされ、リフレッシュローテーションを生き延びます。開発モードでは、単一の環境資格情報（SISENSE_DOMAIN/SISENSE_TOKEN）がマシン上に残ります。ディスクには何も永続化されません：fes-authを再起動するとボールトが消去されます（全員が再サインイン）— データベースと保存時の暗号化サーフェスを持たないという意図的なトレードオフです。

ホスト型サーフェスでの強化：IPごとのログインレート制限、CSRF保護されたログインフォーム、リクエストID付きアクセスログ、および呼び出しごとのツールログ（ツール / ユーザードメイン / 結果 / 所要時間）。

認可

カスタムはありません：認可はSisenseの仕事です。すべてのツール呼び出しは、呼び出し元ユーザー自身のSisenseトークンで実行されるため、SisenseはすべてのAPI呼び出しで実際の権限を強制し、権限エラーはそのままクライアントに表示されます。これが、サーバーが管理者専用ではない理由でもあります — どのSisenseユーザーも自分のスコープだけを取得します。

2つのサービス間の信頼

fes-auth ↔ fes-mcp間の信頼はネットワークレベルです：共有シークレットはありません。RSのポートは内部ネットワークの外部から到達可能であってはなりません（composeはfes-authのみを公開）。多層防御：FES_MCP_ALLOWED_SISENSE_ORIGINSは、RSがX-Sisense-Urlで受け入れるSisenseオリジンを固定します。

変更操作

変更を伴うツールは、FES_MCP_ALLOW_MUTATIONS=trueの場合にのみ公開され、常にdestructiveHintを保持し、無効時にはサーバー側で第2レイヤーとしてブロックされ、変更監査ログに書き込まれます。

さらに、変更を伴うツールは実行前に人間の承認を求めます — MCPエリシテーション（elicitation）を介して、その機能を宣言するクライアント（Claude Code、Cursor、VS Code）で。呼び出しの途中で、正確な引数を開示する続行/中止ダイアログが開きます。中止または拒否しても何も変更されません。エリシテーションのないクライアント（Claude Desktop、claude.ai）では、呼び出しは通常どおり進行し、クライアント自身のツール承認フローとdestructiveHintアノテーションが、他のMCPサーバーと同様に保護手段となります。

ダイアログなしで進めることは意図的な決定（フェイルオープン）であり、見落としではありません：エリシテーションはオプションのクライアント機能であり、不正なクライアントによって自動回答される可能性があるため、厳密にUXとして扱われます — 認可境界は常にユーザー自身のSisense権限です。

LLMプロバイダーへのデータフロー

このサーバーには要約やデータ編集レイヤーはありません：すべてのツール結果 — 完全な行、{ok, count}メタデータではなく — がMCPクライアントに返され、モデルのコンテキストに入ります。これは設計によるものであり、マルチステップのツールチェーンを機能させるものです：モデルは、実際にデータを見なければ、あるツールの出力を推論、フィルタリング、次の呼び出しに渡すことはできません。

結果として、このサーバーをMCPクライアントに接続する人は誰でも、Sisenseデータ（ダッシュボードの内容、クエリ結果、ユーザーリストなど）がそのクライアントのLLMプロバイダー（例：Claudeの場合はAnthropic）にそのプロバイダーとの独自の条件で流れることを受け入れることになります。サーバーはこれを強制またはスコープすることはできません。これはデプロイメントごとに意識的に行う受け入れです。

推奨使用ガイドライン

• 読み取り専用から始める：非本番環境で自信がつくまでFES_MCP_ALLOW_MUTATIONS=false（デフォルト）を維持します。

• config/allowlist.txtを、デプロイメントで実際に必要なツールだけに絞り込みます — ツールが少ないほどデータ露出が減り、承認のストーリーが明確になります。

• 探索中は非本番のSisenseインスタンスを優先します。ツールはサインインしたユーザーの権限と同じだけ安全です。

• 破壊的操作は、エリシテーションをサポートするMCPクライアント（Claude Code、Cursor）でテストし、確認ダイアログを確認します。

設定

テスト

uv run python -m pytest

（python -mが重要です：リポジトリルートをsys.pathに置き、テストモジュールのfrom tests.conftest import …インポートがそれに依存します。）

49件のテスト、ネットワーク不要・認証情報不要（SisenseとSDKはモック化）： レジストリ選択、ディスパッチャの検証／エラー、MCPラウンドトリップ、 ミューテーション確認（承認／中止／拒否／機能なし）、上流の 認証情報検証（インジェクションされたヘッダー、401契約、オリジン許可リスト、 TTL失効）、そして完全なAS+RS分割 — ?target= あり／なしのOAuthダンス、 ディスカバリメタデータ、プロキシされたツール呼び出し、リフレッシュローテーション、 Sisense側の失効時の自己修復、さらに悪用パス（偽造CSRF、 ブルートフォースレート制限、期限切れセッション）。

レジストリの再生成

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

新しいSDKメソッドはレジストリに追加されるが、config/allowlist.txt に 明示的に追加されるまで 非表示 のままとなる。

サポートと貢献

これはSisense Field Engineeringが保守する実験的・コミュニティ貢献プロジェクトであり、 「現状のまま（as-is）」 で提供される。

• GSSチケットを開かないでください — これはGA版のSisense機能ではありません。

• 使用方法の質問や導入支援については、カスタマーサクセスマネージャー（CSM）に 連絡してください。CSMがフィードバックをField Engineeringチームに転送します。

• 問題報告や貢献は、リポジトリを通じて歓迎します。

ライセンス

MIT