Nimbus BCI

nimbus-mcp

AI エージェント（Claude Code、Cursor、Claude Desktop）が Nimbus BCI パイプラインの構築、検証、実行、分析を行える MCP サーバーです。独自の EEG データをアップロードし、パイプラインをスタジオプロジェクトに保存し、複数の設定による実験キャンペーンを実行し、EEG のライブセッションを監視できます。また、明示的な確認を経てライブストリーミングを開始できます。ローカルの Nimbus バックエンド、またはホスト型デプロイメントを、nimbus-mcp login 1 回で利用できます。

nimbus-mcp を選ぶ理由（2026 年 10 月時点）

BCI-MCP 分野では、2026 年に 4 つのサーバーが新たに登場しました。いずれも誠実で、対象を絞ったツールですが、それぞれが nimbus-mcp のエンドツーエンドの機能の一部をカバーしています。

機能	nimbus-mcp	bci-mcp	eeg-mcp	mne-mcp	ephys-mcp
BCI パイプラインの構築＋検証＋実行	✅ 63 個のツール	—	—	—	—
実データでのトレーニング（MOABB パック、アップロード）	✅	—	—	ファイル I/O のみ	NWB/DANDI
独自のモデルコードの使用（python_model）	✅ ローカル＋クラウドサンドボックス	—	—	—	—
ベンチマークのリーダーボード＋サーバー側 LOSO スコアリング	✅	—	—	—	—
エージェントから参照できる図（PNG コンテンツブロック）	✅ plots.*	—	—	✅	✅
人間を対象とするライブハードウェアセッション	✅ 確認必須	✅	✅	—	—
モデル不要のライブバンドパワー（集中／リラックス）	✅ stream.telemetry	✅	✅	—	—
ガイド付き被験者キャリブレーション	✅ calibration.*	—	—	—	—
ニューロフィードバックのプロトコルセッション	✅ protocol.*	—	—	—	—
BIDS エクスポート（sha256 マニフェスト）	✅ bids.*	—	—	—	—
クラスターを考慮したグループ統計	✅ stats.grouped	—	—	—	一部対応
トランスポート	stdio＋ホスト型 HTTP ゲートウェイ	stdio＋HTTP	stdio	stdio	stdio
検証エビデンス	arXiv:2610.13894 — 3 つのデータセット／6 つのパイプライン／2 つのプロトコルによる同等性調査	バンド比ヒューリスティック	—	—	—

対象範囲について（意図的な非目標）：刺激出力には対応しません（eeg-mcp の三重インターロック付き send_stim_event は本当に独自性の高い機能ですが、刺激装置は制御しません）。スパイク／電気生理データには対応しません（ephys-mcp は皮質内記録を扱い、データプレーンが異なります）。ソースローカリゼーション／MNE との完全な同等性には対応しません（mne-mcp はオフライン MNE を深くラップするツールです。plots.* は、エージェントが Nimbus データで必要とする図をカバーします）。

インストール

pip install nimbus-mcp   # or: uvx nimbus-mcp

（リポジトリからもインストールできます：pip install -e nimbus-studio/mcp。）

ハードウェア不要のデモ：examples/demo.md — 公開 MOABB データを使い、デバイスなしで一連の処理（探索 → 確認 → 図の作成 → トレーニング → 混同行列の図 → リーダーボード → 統計）を実行する、コピーして貼り付けるだけのエージェントプロンプトです。

認証

起動時に次の順序で確認される、サーバーに認証情報を渡す3つの方法です。

1. nimbus-mcp login（推奨 — ホステッド API を利用し、トークンを貼り付ける必要はありません）。 デバイスコードによるログインです。このコマンドを実行すると URL と8文字のコードが表示され、ブラウザーが開きます。Nimbus Studio で承認すると、発行されたトークンが ~/.nimbus/credentials.json（0600）に保存され、以降の起動時に自動的に読み込まれます。

   nimbus-mcp login     # options: --api-url URL, --ttl-days 7..90, --name NAME
   nimbus-mcp status    # doctor: credential source, plan, quota, days-to-expiry, live probe
   nimbus-mcp logout    # remove the stored credential
   

ログイン後は、MCP クライアントの設定にシークレットは一切必要ありません。

{
  "mcpServers": {
    "nimbus": {
      "command": "uvx",
      "args": ["nimbus-mcp"],
      "env": { "NIMBUS_API_URL": "https://nimbus-studio.fly.dev" }
    }
  }
}

2. デスクトップアプリ — 設定不要です。 Nimbus Studio のデスクトップアプリを起動しておくだけでかまいません。ローカルのキーファイルが自動検出され（macOS ~/Library/Application Support/Nimbus Studio/mcp-key.json、Linux ~/.config/Nimbus Studio/…、 Windows %APPDATA%\Nimbus Studio\…）、サーバーは http://127.0.0.1:8080 のローカルバックエンドと通信します。貼り付けたり設定したりするものはありません。

3. 環境変数（上級者向け／CI）。 NIMBUS_TOKEN（Nimbus Studio → Account → API tokens で発行したホステッド API トークン nimb_…）、NIMBUS_TOKEN_FILE（0600 の JSON ファイル {"token": "…"} — シークレットをプロセス環境変数や MCP 設定に含めずに済みます）、またはローカルの組み合わせである NIMBUS_MCP_KEY／NIMBUS_MCP_KEY_FILE（ローカルバックエンドの MCP_LOCAL_KEY と一致する必要があります — 下記を参照）を指定できます。明示的に指定された環境変数は、常にディスク上のファイルより優先されます。NIMBUS_API_URL を設定せずに NIMBUS_TOKEN／NIMBUS_TOKEN_FILE のトークンを使用すると、ホステッド API（https://nimbus-studio.fly.dev）と通信します。別の接続先を指定するには、NIMBUS_API_URL を設定してください。

認証情報がどこにもありませんか？ その場合は Local Free tier で動作します。サーバーはローカルバックエンド（デスクトップアプリ、または http://127.0.0.1:8080 の開発用バックエンド）に対して匿名で起動します。テンプレート、自分のデータ、ローカルでの実行／プロット／統計、BIDS エクスポート、ローカル専用ストレージは、Nimbus Studio へのログインなしで利用できます。ログインが求められるのは、最初にクラウド機能を利用するときだけです。ID を必要とするツール（リーダーボードへの投稿、検証済み／マシンをまたいだ実験履歴、ホステッドコンピューティング、クラウド同期、共同作業）は、一律に制限するのではなく、具体的な理由を示す {ok: false, loginRequired: true, trigger, reason, howToAuthenticate} を返します。ホステッド Pro 機能（検証済みのリーダーボード投稿、foundation.compare、大規模キャンペーン、チーム機能）は、無料アカウントでは {ok: false, tierGate: true, requiredTier: "pro"} を返します。エクスポート（BIDS など）は、どのティアでも制限されません。ローカルバックエンド／ID が存在しないためローカル呼び出しに失敗した場合は、ローカルモード用の {ok: false, setupRequired: true, message, options} が返されます（デスクトップアプリを起動する／開発用キーを設定する — ログインは引き続き不要です）。セッション中にホステッドトークンが拒否された場合（期限切れまたは失効）は、何日前に期限切れになったかを含む従来の設定案内が返されます。

自分のアカウント情報を確認する

account.whoami() → {userId, email, plan: {isPro, pioneerAccess},
            freeRuns: {monthlyLimit, remaining},
            token: {name, kind, scopes, fullAccess, expiresAt, daysLeft}
                   | {masked, kind, scopes, fullAccess, expiresAt, daysLeft}  # gateway header token
                   | null,
            source}                                      # store | env | token_file | header | …

エージェントから account.whoami() を呼び出すと、アカウント、プラン、今月の無料実行枠、および（トークンモードの場合）トークンの有効期限までの日数を確認できます。nimbus-mcp status は、バックエンドにリアルタイムで接続確認を行うターミナル版のコマンドです。

ホステッドトークンが意味すること

• トークンはあなた自身です。 リクエストはあなたのアカウントで実行されます。実行結果は Studio の履歴に表示され、あなたのプランの利用枠と制限が適用されます — エージェント用の別枠はありません。月間無料利用枠を使い切ると、実行エラーにアップグレード用リンク https://studio.nimbusbci.com/pricing?reason=mcp-quota が含まれます。
• v0.4 では CPU のみです。 トークン認証による実行では、クラウド GPU は割り当てられません。
• ローテーション。 トークンの有効期間は最長90日です（デフォルトは30日）。プランの変更はトークン発行時点でスナップショットされます。アップグレード後に新しいプランを適用するには、再ログインするか、トークンを失効させて再作成してください。期限切れのトークンには、有効期限までの日数を含む設定案内が表示されるため、先に進めなくなることはありません。

ヘッドレスエージェントと CI（API キー）

CI パイプラインや無人エージェントで使用するには、Nimbus Studio の Account → API tokens からCI キーを発行します。タイプに CI / headless、 有効期間に 90、180、365 日のいずれかを選択し、スコープを選びます。CI キーは Pro 機能です（Pro プランまたは Pioneer アクセスが必要です）。Free アカウントでも 個人用トークンは引き続き使用できます。

スコープ	許可される操作
read	GET／一覧表示／詳細表示、および計算のみの POST（検証、プロット、統計、エクスポート）
run	実行と実験の開始／キャンセル（クォータを消費します）
write	プロジェクト、パイプライン、アップロード、設定の作成／更新／削除
leaderboard:submit	リーダーボードへの送信

CI キーのデフォルトは read + run です。フルアクセスの CI キーは明示的に 選択する必要があります（Full access チェックボックス、または POST /api/me/api-tokens の "fullAccess": true）。個人用トークンのデフォルトは 従来どおりです。スコープを選択しない場合はフルアクセスとなり、スコープ導入前に 発行されたすべてのトークンも変更なく引き続き機能します。バックエンドはすべての リクエストでスコープを適用します。必要なスコープがない場合は 403 nimbus.auth.token_scope_insufficient が返されます。account.whoami と nimbus-mcp status では、キーの種類、スコープ、残り日数を確認できます。

キーを CI シークレットとして保存し、NIMBUS_TOKEN として渡します（ NIMBUS_API_URL は不要です。トークンの接続先はデフォルトでホスト版 Nimbus です）。GitHub Actions の例：

- name: Nimbus smoke run
  env:
    NIMBUS_TOKEN: ${{ secrets.NIMBUS_CI_KEY }}
  run: |
    pipx install nimbus-mcp
    nimbus-mcp status          # fails fast if the key is expired or revoked

または、ヘッダー Authorization: Bearer $NIMBUS_TOKEN を付けて、ホスト型 ゲートウェイ https://nimbus-mcp.fly.dev/mcp を呼び出します。有効期限の前に ローテーションしてください（Account ページでは、有効期限まで14日以内のキーが 通知されます）。キーが漏えいした場合はすぐに失効させてください。失効は次の リクエストから有効になります。

API キーのプランと制限：

• プランは常に最新の状態で再確認されます。API キーを使ったリクエストのたびに、 現在の Clerk Billing プランが照会されます（約1分間キャッシュされます）。そのため、 Pro を解約すると、新しいキーだけでなく、既存のキーからも Pro 機能が削除されます。
• CI キーの所有者が Pro でなくなると、すべてのリクエストで 403 nimbus.auth.ci_key_requires_pro が返されます。再登録すれば、キーを再発行 しなくても再び使えるようになります。それ以外の場合はキーを失効させ、個人用 トークンに切り替えてください。
• 有効な（失効しておらず、有効期限内の）API トークンは最大20個までです。 さらに発行しようとすると 409 nimbus.me.api_token_limit_reached が返されます。 MCP OAuth サインインで作成されたトークンは、この上限に含まれません。

プライバシーとテレメトリー

ローカル Free モードではアカウントは不要で、デフォルトでは外部にデータを送信 しません。匿名でコンテンツを含まない利用状況テレメトリー（ツール名、成功／失敗、 エラーコード、所要時間の区分。データ、ファイルパス、コードは送信されません）は オプトインです。新規インストール後、最初のツール応答で一度だけ確認されます。 nimbus-mcp telemetry on|off|status（または NIMBUS_MCP_TELEMETRY=on|off）で いつでも設定できます。テレメトリーをオフにすると、テレメトリー関連のネットワーク 呼び出しは一切行われず、ローカルの機能はすべて引き続き動作します。全文は PRIVACY.md をご覧ください。起動時に PyPI のバージョンを静かに確認し （24時間キャッシュされ、最新またはオフラインの場合は通知されません）、クライアント がホスト型ゲートウェイの対応範囲より古い場合は、ツール応答に一度だけ versionNotice が追加されます。

要件（ローカルモード）

• ローカルで実行中の Nimbus バックエンド：デスクトップアプリ、または開発サーバー （cd nimbus-studio/backend-py && python -m nimbus_backend.server.app、DEBUG=1 を指定）。
• バックエンドの起動時に MCP_LOCAL_KEY=<some-secret> を設定します（Fly では決して 設定しないでください。設定すると拒否されます）。
• デスクトップアプリのユーザー：Settings → MCP & Agents を開きます。キーの手動設定は 不要です（アプリがキーを作成してバックエンドに注入し、そのままコピーできる設定を 提供します）。

デスクトップアプリは不要です。 データ取得はバックエンド内だけで完結します。 ヘッドレスのローカルバックエンドと nimbus-mcp を使えば、Electron を使わずに実機 （BrainFlow ボード、BLE 経由の BrainBit、LSL、PiEEG）や合成ボードを制御できます：

git clone <this repo> && cd NimbusStudio/nimbus-studio/backend-py
pip install -e ".[streaming]"            # brainflow + pyneurosdk2 + pylsl extras
export DESKTOP_LOCAL_BACKEND=true MCP_LOCAL_KEY=<secret> MCP_LOCAL_USER_ID=user_…
python -m nimbus_backend.server.app      # loopback backend with device radios
# another shell: nimbus-mcp against http://127.0.0.1:8080 with NIMBUS_MCP_KEY=<secret>

同じ stream.start → stream.telemetry のフローは、トレーニング済みモデルの有無に かかわらず動作します（モデルなしのストリームでは、信号品質と集中／リラックスの 指標がリアルタイムで報告されます）。

バックエンドを設定する

デスクトップ／開発環境（例：backend-py/data/.env または開発用シェル）：

MCP_LOCAL_KEY=choose-a-long-random-string
MCP_LOCAL_USER_ID=user_your_clerk_user_id
DEBUG=1   # dev server only; the desktop app qualifies automatically

MCP_LOCAL_USER_ID は、MCP キーがどのプリンシパルとして認証するかを設定します。ご自身の Clerk ユーザー ID（user_…）を設定すると、エージェントが作成したもの（プロジェクト、保存済みパイプライン、実行など）がすべて、スタジオの UI でご自身のものとして表示されます。オーナーを 1 人決めて、そのまま使い続けてください。途中で ID を切り替えると、エージェントが作成した作業の所有権が 2 つのプリンシパルに分かれ、どちらの ID からも履歴全体を確認できなくなります。

ウォッチドッグのデフォルト設定：MCP 経由で開始したストリーミングセッションは、誰も監視していない状態が 15 分続くと自動停止します（stream.status／stream.telemetry のポーリングごとにタイマーがリセットされます）。セッションでこれを無効にするには、stream.start に idle_timeout_sec=0 を渡してください。

信頼できないネットワークに接続されたマシンで MCP_LOCAL_KEY を有効にする場合は、バックエンドにも HOST=127.0.0.1 を設定してください。0.0.0.0 のデフォルト（settings.host）は、開発サーバーを直接起動する場合（python -m nimbus_backend.server.app）に適用されます。そのため、この設定のままではキーが LAN からも受け入れられてしまいます。backend-py/scripts/run_server.py はすでにデフォルトで 127.0.0.1 を使用しており、デスクトップアプリもループバックに固定されています。

サーバーを実行する

cd nimbus-studio/mcp
python -m venv .venv && source .venv/bin/activate
pip install -e ".[test]"
NIMBUS_MCP_KEY=choose-a-long-random-string python -m nimbus_mcp

環境変数：NIMBUS_API_URL（設定されている場合は常に優先されます。そうでない場合は、ログイン後はストアの api_url、NIMBUS_TOKEN／NIMBUS_TOKEN_FILE トークンの場合は https://nimbus-studio.fly.dev、それ以外は http://127.0.0.1:8080）、NIMBUS_TOKEN／NIMBUS_TOKEN_FILE（ホステッド API トークン。認証を参照）、NIMBUS_MCP_KEY（MCP_LOCAL_KEY と一致する必要があります）、NIMBUS_MCP_KEY_FILE（0600 の JSON ファイル {"key": "…"} へのパス。デスクトップアプリのワンクリック MCP セットアップで書き込まれます。NIMBUS_MCP_KEY が未設定の場合のみ参照されます）、NIMBUS_EXPORT_DIR（デフォルトは ~/nimbus-exports）。トークン／キーの環境変数が設定されていない場合は、ログインストア、続いてデスクトップのキーファイルが自動検出されます。何も見つからない場合、サーバーはセットアップモードで起動します（すべてのツールがオンボーディングの案内を返します）。

ホステッドゲートウェイ（ストリーミング可能な HTTP）

nimbus-mcp serve は、同じ 63 個のツールを stdio の代わりにストリーミング可能な HTTP で実行します。リモート MCP クライアント、レジストリ（Smithery では URL ベースのサーバーが一覧表示されます）、ブラウザー側のクライアント向けです。

nimbus-mcp serve --port 8080   # env: NIMBUS_MCP_HOST/PORT/PATH

ゲートウェイはデフォルトで 127.0.0.1 にバインドされます。外部に公開するには（--host 0.0.0.0）、明示的なオプトインが必要です。その場合は、以下のリクエストごとのトークンも併用してください（ゲートウェイ自体にはアクセス制御用の認証情報がありません）。

ゲートウェイ自体は認証情報を保持しません。各リクエストの Nimbus API トークンはヘッダーで渡されるため、共有デプロイメントから、各ユーザーが自身として利用できます。ヘッダーのない呼び出しにはセットアップの案内が返されます（ヘッダーを追加するか、uvx を使ってローカルにインストールしてください）。

{
  "mcpServers": {
    "nimbus": {
      "type": "http",
      "url": "https://nimbus-mcp.fly.dev/mcp",
      "headers": { "X-Nimbus-Token": "nimb_…  (Account → API tokens)" }
    }
  }
}

（環境変数に NIMBUS_TOKEN を設定して起動したゲートウェイは、ヘッダーのない呼び出しでそのトークンをフォールバックとして使用します。シングルテナントのセルフホスト用です。）

OAuth サインイン（オプトイン、NIMBUS_MCP_OAUTH=1）

NIMBUS_MCP_OAUTH=1 を設定すると、ゲートウェイは OAuth 2.1 認可サーバー（MCP 認可仕様）としても動作します。そのため、Claude や Cursor などのクライアントは URL だけで接続でき、トークンを貼り付ける必要はありません。

• /.well-known/oauth-protected-resource/mcp および /.well-known/oauth-authorization-server のメタデータ。
• 動的クライアント登録（/register、バックエンドに保存）。
• /authorize（PKCE S256）はブラウザーを Studio の /mcp/authorize に転送します。そこでユーザーはサインインし、「許可」または「拒否」を選択します。
• /token はコードを通常の nimb_ トークンと交換します（30 日間有効、リフレッシュトークンなし。スコープは read、run、write、leaderboard:submit。すべて、または何も要求されなかった場合はフルアクセス）。同じクライアントを再認可すると、そのクライアントの以前のトークンは失効します。また、すべての OAuth トークンは「アカウント」→「API トークン」に一覧表示され、失効させることもできます。

このフラグがオンの場合、トークンなしのリクエストには仕様に準拠した 401 が返され、WWW-Authenticate: Bearer resource_metadata=… ヘッダーが含まれます（これによりクライアントのサインインが開始されます）。そのため、ヘッダーのない tools/list は公開されなくなります。既存の X-Nimbus-Token / Authorization: Bearer nimb_… ヘッダーも引き続き使用できます。

変数	設定場所	意味
NIMBUS_MCP_OAUTH	ゲートウェイ	1 で OAuth を有効化します（デフォルトはオフ）。
MCP_OAUTH_GATEWAY_SECRET	ゲートウェイ および バックエンド	ゲートウェイ専用のバックエンドルートと同意リクエストの署名に使用する共有シークレット（32 文字以上）。
NIMBUS_MCP_PUBLIC_URL	ゲートウェイ	発行者／公開ベース URL（デフォルトは https://nimbus-mcp.fly.dev。ループバック以外では HTTPS が必要です）。
NIMBUS_STUDIO_URL	ゲートウェイ	/mcp/authorize の配置先（デフォルトは https://studio.nimbusbci.com）。
NIMBUS_API_URL	ゲートウェイ	バックエンドのベース URL。

Fly では、ゲートウェイアプリに対して fly secrets set MCP_OAUTH_GATEWAY_SECRET=… NIMBUS_MCP_OAUTH=1 を実行し、バックエンドにも同じ MCP_OAUTH_GATEWAY_SECRET を設定します。シークレットが未設定の場合、バックエンドは OAuth ルートに対して 503 nimbus.mcp.oauth_not_configured を返します。

Claude Code

# --env flags go BEFORE the -- separator (everything after it is the literal
# server command, so the after-form would feed --env to python/uvx):
claude mcp add nimbus --env NIMBUS_MCP_KEY=choose-a-long-random-string \
  -- <path-to-mcp-venv>/bin/python -m nimbus_mcp

Cursor / Claude Desktop（stdio）

{
  "mcpServers": {
    "nimbus": {
      "command": "<path-to-mcp-venv>/bin/python",
      "args": ["-m", "nimbus_mcp"],
      "env": { "NIMBUS_MCP_KEY": "choose-a-long-random-string" }
    }
  }
}

ツール（63）

認証：account.whoami（アカウント、プラン、クォータ、トークンの有効期限） 検索：catalog.nodes、catalog.node_schema、catalog.templates、catalog.template、catalog.datasets、catalog.leaderboard データ：data.upload、data.delete_upload（confirm=true が必要） 検査：data.inspect_dataset、data.inspect_file（EDA：チャネル、クラスのバランス、帯域パワー、PSD） 構築：pipeline.validate、pipeline.validate_node 実行：execution.run（非ブロッキング）、execution.get、execution.list、execution.results、execution.cancel、execution.delete（confirm=true が必要）

実行サマリー（execution.get／execution.list）には、データセットに関するフィールドが2つ含まれています。dataset は人が読みやすい表示ラベル（例：BCIIV2a）、datasetId は他のツールが受け付けるカタログ ID（例：BNCI2014_001。data.inspect_dataset、グラフ内の public_data.dataset で使用）です。title は Studio に表示される実行名です。 キャンペーン：experiment.run（非ブロッキング、間隔を空けた1～25回の実行）、experiment.get、experiment.delete（confirm=true が必要） アーティファクト：execution.artifacts、execution.download_artifact、pipeline.export ライブ：device.list、device.test、stream.start（confirm=true が必要）、 stream.status、stream.telemetry、stream.stop キャリブレーション：calibration.start（confirm=true が必要）、calibration.status、 calibration.pause、calibration.resume、calibration.train ニューロフィードバックプロトコル：protocol.validate／protocol.save（バージョン管理された仕様）、 protocol.start_assignment（確認が必要。シミュレーションソースは無料、ライブハードウェアは Pro）、 protocol.session_status／pause／resume／stop、protocol.export_stats （対応する事前／事後統計＋図＋CSV） プロジェクト：project.create、project.list、project.save、project.load、project.rename、project.delete（confirm=true が必要） Python：python.validate（BYO モデルコードの静的契約チェック。実行はしません） リーダーボード：leaderboard.submit（BYO python_model → サーバー側の LOSO スコアリング、 202 + submissionId。track="pretrained_few_trial" は効率性トラック： 100試行上限の LOSO。torch コードでは PARAMS_TRAINED の宣言が必要）、 leaderboard.status（1件の送信をポーリング。所有者のみ）、 leaderboard.mine（自分の送信。新しい順） BIDS：bids.export_dataset（パック／アップロード／録画 → BIDS レイアウトの zip。 連続データ → BIDS-raw、エポック化データ → BIDS-derivatives）、bids.export_execution （結果バンドル：メトリクス、participants.tsv、プロトコル、パイプラインのスナップショット） プロット：plots.confusion、plots.dataset（psd／topomap／bandpower／ spectrogram）、plots.erp（クラスごとのバタフライプロット）、plots.leaderboard（CI ウィスカーバー、BYO を強調表示。track=pretrained_few_trial では 古典的な LOSO ベースラインを並べて表示）— アシスタントが確認できる PNG 図 統計：stats.grouped（実行全体にわたる被験者ごとのクラスタを考慮した精度： t 区間＋チャンスレベルとの t 検定）

どのパイプラインを構築すればよいかわからない場合は、catalog.leaderboard() でデータセットごとにベンチマーク済みパイプラインを、標準の within_session プロトコルに基づいてランキング表示できます（meanAccuracyPct の降順、95% CI）。エージェントはここでのランキングを参考にテンプレートを選び、catalog.template(pipelineId) で最上位のものを取得できます。

まずデータを確認しましょう（そして結果も確認しましょう）

パイプラインを構築する前に、エージェントはデータを確認できます。チャネル、サンプリングレート、試行／クラスのバランス、チャネルごとの µV 統計、標準的な帯域パワー、PSD の概要などを、公開データセットまたはディスク上のファイルから確認できます。

「パイプラインを選ぶ前に、BNCI2014_001 の被験者 S01 を調べてください。」

data.inspect_dataset(dataset="BNCI2014_001", subject="S01", mode="all")
# → {channels: {count: 22, names: [...], flatlined: []}, samplingRate: 250,
#    trials: {count: 288, classLabels: [...], classCounts: {...}},
#    channelStats: [...], bandPowers: {...}, psd: {...},
#    computedFrom: {nSamples: ..., sampleStrategy: "stratified_sample_seed42_4_of_20"}}

subject は必須です（例："S01"。リストは catalog.datasets で取得できます）。また、"S01,S03" のようにカンマ区切りで指定すると、複数被験者のデータを読み込みます。mode は training | evaluation | all です。

ファイルでも同様に利用できます。data.inspect_file はパスの形式からデータソースを判断します。絶対パスを指定すると、ディスク上のファイルを読み込みます（ローカルバックエンドのみ対応。デスクトップアプリ／MCP ローカルモードではアップロードは不要で、データがマシンの外に出ることはありません）。相対パス（data.upload が返すパス）を指定すると、任意のバックエンド（ホスト型またはローカル）にアップロードしたファイルの情報を取得します。

「~/recordings/session-01.edf を確認して、モンタージュに問題がないか教えてください。」

data.inspect_file(path="/Users/you/recordings/session-01.edf")  # absolute → local file
data.inspect_file(path="uploads/<user>/session-01.edf")  # data.upload path → upload
data.inspect_file(path="uploads/<user>/eeg.csv", sampling_rate=250.0)  # CSV/TSV/TXT need a rate

CSV/TSV/TXT にはサンプリングレートが含まれないため、sampling_rate（Hz）が必須です。これを指定しない場合、リクエストが行われる前にツールは nimbus.mcp.sampling_rate_required で即座に失敗します。

ホスト型バックエンドでは絶対パスは拒否されます。その場合、data.inspect_file は行き止まりになるのではなく、案内（ファイルを data.upload して返されたパスを指定するか、サーバーをローカルバックエンドに接続する）を返します。

事前に確認する理由：クラスのバランスは層化分割に影響します（クラスの偏りは精度を歪めます）。また、信号が平坦なチャネルはモンタージュ／基準電極の問題を示しているため、トレーニング前に修正する価値があります。単位にも注意してください。ローダーはボルトを前提としています。µV 単位の CSV を読み込むと値が 1e6 倍大きくなります。必要に応じて、パイプラインの custom_data 設定で unitsScale（例：units: "uV" と 1e-6）を指定してください。

同じデータや結果は、JSON だけでなく、アシスタントが確認できる PNG 画像としても表示できます。plots.dataset（PSD／帯域パワーヒートマップ／頭皮トポマップ／スペクトログラム）、plots.erp（クラスごとの誘発電位バタフライプロット。トレーニング前にクラス構造を確認できます）、plots.confusion（実行後に、どのクラスが実際に混同されているかを表示）、plots.leaderboard（データセットごとの CI 誤差範囲付きバー。BYO の提出結果を強調表示）を利用できます。save=true を指定すると、PNG は NIMBUS_EXPORT_DIR/plots/ にも保存されます。

plots.confusion(execution_id="exec_123")  # → image + per-class accuracy
plots.dataset(kind="psd", source="dataset", dataset="BNCI2014_001", subject="S01")
stats.grouped(execution_ids=["exec_123", "exec_124"])  # cluster-aware t-interval + p

データのアップロード

公開データセットの代わりに、または公開データセットと併せて、ご自身の記録データを使用できます。

「~/recordings/session-01.edf に .edf の記録があります。アップロードして、それをもとにパイプラインを構築してください。」

エージェントは data.upload(file_path=…) を呼び出してファイルをバックエンドに登録し、保存先のパスを取得します。そのパスを custom_data ノードの設定（{"filePath": "<path>", "format": "edf", …}）に指定し、pipeline.validate／execution.run／experiment.run で使用します。メタデータが埋め込まれていない通常の CSV/TSV/TXT では、sampling_rate（Hz）を指定してください。指定がない場合、バックエンドは暗黙的に 250 Hz を使用します。format を指定すると、拡張子に基づく判定が上書きされます。

実験キャンペーン

experiment.run を 1 回呼び出すと、1～25 個のパイプラインを一定のペースで実行するスイープ（同時に実行中となるトレーニングは最大 2 つ）を開始し、メトリクスを集計できます。エージェントが 25 件の execution.run のポーリングを個別に管理する必要はありません。

「BNCI2014_001 の被験者 1～3 で CSP-LDA と EEGNet を比較してください。」

エージェントは 6 つのトレーニンググラフを構築し、experiment.run(runs=[{name: "csp-lda-s1", train_graph: …}, …]) を呼び出します。すぐに experimentId が返されるため、その後 experiment.get(experiment_id) をポーリングし、ステータスが completed になるまで待ちます。結果には各実行のステータスと、完了時に {"kappa": {"mean": 0.61, "std": 0.08, "best": {name, value}}} のような aggregates が含まれます（mean/std/best は完了した実行のみを対象に集計されます）。

プロジェクトでの作業

エージェントが構築し、人間が確認します。エージェントが保存したパイプラインは実際のStudioプロジェクトに保存されるため、キャンバスを開いて何が実行されたかを正確に確認できます。

「このパイプラインを『motor-imagery-baseline』というプロジェクトとして保存してください。Studioで確認します。」

project.create(name)でコンテナーを作成し、project.save(project_id, train_graph, expected_revision=…)でグラフを書き込みます（レイアウトは自動生成されます。同時編集がサイレントに上書きされるのではなく競合するように、project.loadから取得したexpected_revisionを渡してください）。また、project.load(project_id)で編集または再実行するためにグラフを読み込みます。 MCP_LOCAL_USER_IDにユーザーIDを設定すると、自分のStudioプロジェクト一覧にプロジェクトが表示されます。

ライブセッションの監視

ストリーミングセッションの実行中、エージェントはテレメトリを監視し、確認した内容を伝えられます。

「集中セッションを監視して、信号品質が低下したら教えてください。」

エージェントはstream.telemetry(session_id)をポーリングします。取得できるのは最新の予測、直近のウィンドウ、信号品質（meanChannelQuality、snrDb、artifactProbability）、実行中の統計情報です。品質が低下した場合は警告します。ポーリングのたびにアイドル監視タイマーもリセットされるため、監視中のセッションが自動停止されることはありません。放置されたセッションは15分後に停止します。

被験者のキャリブレーション

ガイド付きキャリブレーションでは、デバイスを装着した人自身をトレーニングデータにできます。キューに従ってセッションを実施してラベル付き試行を記録し、その記録からエージェントが被験者専用の分類器をトレーニングします。

「BrainBitでクラスごとに10試行のMIキャリブレーションを実行し、完了したら自分専用の分類器をトレーニングしてください。」

5つのツールを使うフロー（すべてノンブロッキング）：

# 1. Start (confirm-gated): fetches the paradigm's calibration template
#    (mi / p300 / sart / target_hit), patches in device + trial count, and
#    starts the session. The Studio app shows the cues on its calibration
#    dashboard automatically.
calibration.start(paradigm="mi", trials_per_class=10, confirm=true)
# → {started: true, executionId: "…"}

# 2. Poll: phase (baseline → imagery trials → complete), current trial, cue,
#    progress tally, and an ETA estimate from the timing SSOT.
calibration.status(execution_id="…")
# → {phase: "imagery", currentTrial: {index: 7, total: 20, class: "Left Hand",
#    cue: "← LEFT"}, progress: {trialsDone: 6, …}, estimatedRemainingSec: 105.0, …}

# 3./4. Pacing between trials (cues hold; resume anytime).
calibration.pause(execution_id="…")  # calibration.resume(...) to continue

# 5. When phase == "complete" the snapshot carries the recording:
#    calibration: {uploadId, path, filename, format}. Train from it.
calibration.train(execution_id="…")
# → {trainExecutionId: "…", calibrationUploadId: "…"} → poll execution.get,
#    then execution.results for the metrics (kappa, accuracy, …).

miはデフォルトのmi_headband_csp_ldaテンプレート（CAR → 8-30 Hzバンドパス → CSP → LDA）でトレーニングし、p300はp300_hardware_xdawn_lda（記録したフラッシュのエポックにxDAWN → LDAを適用）でトレーニングします。sartとtarget_hitにはデフォルトのトレーニングテンプレートがありません。明示的なtemplate_id（catalog.templatesから取得）または独自のtrain_graphをcalibration.trainに渡してください。どちらの場合も、最初のデータノードは記録されたアップロードに接続し直され（uploadIdに固定されたcustom_dataソース）、テンプレートのトレーニング設定は維持されます。

calibration.startはconfirm=trueを指定しないと実行できません。stream.startと同様、デバイスは人の頭部に装着して使用するため、まずdevice.testを呼び出してください。

Proプランが必要です。キャリブレーションのワークフローとカスタムデータによるトレーニングはフリーミアム制限の対象です（無料プランのリクエストはノードポリシーにより403になります）。ローカルのX-MCP-Keyプリンシパルは、デスクトップアプリでサインイン済みのProセッションが示されている場合（MCP_LOCAL_IS_PRO）に利用できます。それ以外の場合は、ローカルのプリンシパルにもノードポリシーが適用されます。

キャリブレーションからトレーニングへの引き継ぎは、デスクトップローカルを含むすべてのバックエンドで解決されます。現在のビルドで作成された記録には、デスクトップストア内にアップロードと実行の関連付けが保存されています。それ以前のビルドで作成された記録にはこの関連付けがないため、calibration.startを再実行してください（ツールのステータスヒントにも同じ案内が表示されます）。

安全性

stream.startはconfirm=trueを指定しないと実行できません。EEGデバイスに接続し、人のライブセッションを開始するためです。X-MCP-Keyの経路はマシンローカルでのみ使用でき（Flyデプロイでは受け付けません）、ホストモードではnimbus-mcp loginで取得した個人用のAuthorization: Bearerトークンを使って認証します（上記の認証を参照）。MCP経由で開始したセッションは、15分間操作がないと自動的に停止します（上記のアイドル監視の注記を参照）。