dashAI (unofficial)

dashai-mcp

University of Chile（FCFM）が主導し、DCC UChile と UTFSM の学生が CENIA および IMFD とともに開発した、オープンソースの機械学習ワークベンチである dashAI 用の MCP サーバーです。

非公式かつ独立したプロジェクトです。 これはサードパーティ製のプロジェクトです。dashAI プロジェクトや、開発機関とは提携しておらず、承認も受けておらず、保守も行っていません。

エージェントから、GUI を通じて人が dashAI で利用できるのと同じ操作を行えます。データセットの確認、利用可能なモデルの確認、トレーニング、キューに入った作業の追跡、メトリクスの確認が可能です。

"Train a random forest on dataset 3 predicting 'species' and tell me the F1"

ステータス

v0.2.2 — 稼働中の dashAI 0.9.7.post1 で検証済みです。 決定的なテスト（predict の 2 段階パスを含む）に加え、ライブ実行で dashai_train_model → dashai_job_status → dashai_get_run とメトリクス、および dashai_predict → dashai_job_status の完了を確認しました。

ライブの表形式データ実行（シード students）

公開 dashAI シードのみを使用しています。ターゲットは placement_status（多数派が約83％）です。
exam_score はラベル漏洩になるため、入力から除外しました。分割比率は70/15/15です。目標メトリクスは BalancedAccuracy です — Accuracy と多数派クラスでの F1 は落とし穴になります。

モデル	テスト BalancedAccuracy	テスト MCC	テスト F1	テスト Accuracy
DummyClassifier(most_frequent)	0.500	0.000	0.906	0.827
RandomForestClassifier（class_weight=balanced、深さ8、100本の木）	0.851	0.591	0.900	0.845
LogisticRegression（class_weight=balanced、L2）	0.873	0.624	0.905	0.853

ダミーは常に多数派クラスを回答することで、F1 では勝ちます。線形モデルは、クラスの分離を実際に測るメトリクスでフォレストを上回ります。各行はそれぞれ独立した70/15/15の分割です（同じテスト行ではありません） — それでも、フォレストをデフォルトとして扱うのをやめるには十分です。クライアントがここで F1 だけを報告するなら、それは嘘をついています。

完了したフォレスト実行での dashai_predict は prediction_id を返し、ジョブは完了しました。これはモデルのトレーニングに使った同じシードデータセットをスコアリングしたものであり、ホールドアウトファイルではありません — 汎化性能の検証として解釈しないでください。dashai_get_prediction が返すのは {n, n_classes, class_counts} のみです。

ライブの画像実行（シード cifar10-subset）

公開シード：200枚の画像、カエル対トラック（各100枚）。LeNet5ImageClassifier、CPU、32×32。分割比率70/15/15 → テスト n=30。チャンスレベルは0.5です。

実行	shuffle/stratify	トレーニング BalAcc	検証 BalAcc	検証 MCC	テスト BalAcc	テスト MCC
10エポック（汚染あり）	オフ	0.879*	0.467*	0.000	0.633*	0.000
40エポック（汚染あり）	オフ	0.950*	0.733*	0.000	0.867*	0.000
40エポック（cifar10-lenet5-40ep-stratified）	オン	1.000	0.767	0.544	0.900	0.816

*BalancedAccuracy ではなく Accuracy です — 検証／テストデータが単一クラスの場合、両者は同じ値になります。このシードでのチャンスレベルは 0.5 です。ダミーの表形式データモデルは該当しません（画像タスク）。

画像のパスは機能します。0.867 は結果ではありません。dashAI のデフォルトでは shuffle=False だったため、検証／テストデータはトラック30枚で、カエルは0枚でした。MCC が0なのは、単一クラスの分割に対する sklearn の結果です。このサーバーが shuffle=true と stratify=true を送信した後は、検証／テストデータに両クラスが含まれ、MCC は0ではなくなりました。トレーニングは1.0に達しています（140枚の画像を記憶）。検証の0.767が比較的誠実な数値です。テストの0.900は30行の抽選結果です。リーダーボードの数値として公開しないでください。

稼働中のインスタンスで検証したところ、dashAI のドキュメントと実際の挙動の食い違いが明らかになりました。それぞれに回帰テストがあります。6つ目の問題 — shuffle=False での順次分割 — は、動く Accuracy と並んで MCC が0になったことで、ライブ実行時に初めて判明しました。 dashai_predict が run_id を PredictJob に送信する問題も、予測テストがなかったため、ライブ実行時に初めて判明しました（KeyError: 'prediction_id'）。

インストール

pip install dashai-mcp
# or: uv pip install dashai-mcp

MCP クライアントの設定で：

{
  "mcpServers": {
    "dashai": {
      "command": "dashai-mcp"
    }
  }
}

dashAI は別途起動しておく必要があります（dashai またはデスクトップアプリ）。デフォルトでは http://localhost:8000 を参照します。

ツール

ツール	内容
dashai_server_info	dashAI は稼働していますか？データセットと実行はいくつありますか？
dashai_list_datasets	読み込まれたデータセットを一覧表示します
dashai_describe_dataset	列、型、サンプルを1回の呼び出しで取得します
dashai_list_components	利用可能なモデル、メトリクス、タスク、オプティマイザーを一覧表示します
dashai_train_model	**学習を実行します。**ジョブをキューに登録し、job_id と run_id を返します
dashai_job_status	ジョブの進捗状況：not_started / started / finished / error
dashai_list_runs	モデルの比較に使う、記録済みの実行を一覧表示します
dashai_get_run	実行の設定とメトリクスを取得します
dashai_predict	完了した実行のモデルを使って予測します
dashai_get_prediction	完了した予測のクラス数を取得します — 行データは決して返しません

dashAI のドキュメント（またはデフォルト設定）にある6つの誤り

実際のインスタンスで実行して見つけました。この API 用のクライアントを作成する場合、次の点に注意してください。

ドキュメントの説明	実際の動作
?select_types=["Model","Metric"]	パラメーターを繰り返す必要があります：?select_types=Model&select_types=Metric。JSON 配列を指定すると 422 が返されます。
JSON ボディを指定して POST /job/	フォームデータを使い、kwargs は JSON 文字列としてシリアライズします。このエンドポイントは request を手動で解析するため、独自の openapi.json でもこのルートに requestBody は宣言されていません。
オブジェクトとしての splits	JSON 文字列として渡されます。Pydantic スキーマでは str と宣言されています。
optimize(model_class, search_space, X, y, n_trials)	実際のシグネチャは optimize(model, input_dataset, output_dataset, parameters, metric) であり、model はクラスではなくインスタンスです。
ジョブで run_id を指定して予測	PredictJob.run には kwargs["prediction_id"] が必要です。GUI はまず POST /predict/（{run_id, dataset_id}）を呼び出してから、ジョブをキューに登録します。ジョブに run_id を渡すと KeyError: 'prediction_id' が発生します。
分割時の shuffle / stratify	prepare_for_model_session では、どちらもデフォルトで False です。クラス順に並べられたシード（cifar10-subset はカエル100件の後にトラック100件）では、70/15/15 に分割すると、検証用とテスト用が単一クラスになります。Accuracy は変動しますが、sklearn の MCC は 0 として定義されます。このサーバーでは shuffle=true を指定し、分類タスクでは stratify=true も指定します。

コンポーネントレジストリには、ドキュメントが示唆する4種類ではなく、13種類あります：Task、GenerativeTask、Model、GenerativeModel、DataLoader、DatasetSource、Metric、Optimizer、Job、LocalExplainer、GlobalExplainer、Explorer、Converter。

また、GET /run/{id} はインデックスの全リストを含む split_indexes を返します。10,000行のデータセットでは、これだけで**59 KB、レスポンスの99％**を占めます。このサーバーでは各分割の件数に置き換え、レスポンスを約1 KBに抑えています。

3つの設計上の判断

1. 142個ではなく、10個のツール

dashAI は142個の REST エンドポイントを公開しています。エンドポイントごとにツールを1つ生成するのは機械的で、適切ではありません。140個のツールを持つモデルは、カタログを読むだけでコンテキストを消費し、選択の精度も下がります。この10個で、実際の作業に必要な流れをカバーできます。

2. dashai_train_model は3つの呼び出しをまとめます

生の API では、学習は次のように連続した処理です。

POST /model-session/   → creates the experiment
POST /run/             → creates the run
POST /job/             → enqueues the ModelJob

GUI が自動入力する必須フィールドには、ドキュメントに記載されていない plot_history_path、plot_slice_path、plot_contour_path、plot_importance_path があります。さらに、splits はオブジェクトではなく JSON 文字列として渡されます。dashAI のドキュメントではオブジェクトとして示されていますが、バックエンドの Pydantic スキーマでは str と宣言されています。こうした細部が、生の API に対してエージェントが失敗する原因になります。

ここでは1回の呼び出しで済み、ブロックしません。学習には数時間かかる場合があるため、すぐに job_id を返し、進捗は dashai_job_status でポーリングします。

dashai_predict も同様に、GUI の2段階の処理（POST /predict/ の後に prediction_id を指定して POST /job/）をまとめます。

3. ツールが何かを削除することはありません

dashAI の API には認証がありません。エンドポイントを一つずつ確認済みです。ローカルファーストのものとしては一貫していますが、読み違えた文章と取り消せない DELETE /dataset/{id} の間に何の障壁もないことを意味します。削除は、何を削除するかを確認しながら GUI から行います。

同じ理由から、サーバーはローカル以外のホストを指定することを拒否します。

DASHAI_BASE_URL points to 'ml.example.com', which is not local, and dashAI's API
has no authentication: exposing it to the network leaves the backend open to
anyone who can reach it.

対象がほかの方法で保護されている場合は、DASHAI_ALLOW_REMOTE=1 を意図的に設定して、この制限を無効にできます。

設定

変数	デフォルト	用途
DASHAI_BASE_URL	http://localhost:8000	バックエンドの場所
DASHAI_ALLOW_REMOTE	(なし)	ローカル以外のホストを許可します（上記参照）
DASHAI_TIMEOUT	30	リクエストごとの待機秒数

dashai_get_prediction で Arrow ファイルをクラス数に変換するには、MCP プロセスに pyarrow が必要です（pip install 'dashai-mcp[counts]' を実行するか、dashAI と同じ環境に MCP をインストールしてください）。これがなくてもツールはステータスを返しますが、行データの出力は拒否します。

開発

python -m venv .venv && .venv/bin/pip install -e ".[dev]"
.venv/bin/python -m pytest tests/ -q

テストでは respx を使って HTTP レスポンスをスタブ化しています。dashAI のインスタンスも認証情報も不要です。テストでは契約、つまりどの呼び出しがどの順序でどの本文とともに行われるか、また何かが失敗したときにエージェントに何が伝えられるかを確認します。

稼働中のインスタンスに対する検証

スタブに対してしかテストしていないクライアントは、仮説にすぎません。scripts/smoke_live.py は、エージェントが使用するのと同じコードパスを通じて、実際に稼働している dashAI に対してすべてのツールを実行します。

python scripts/smoke_live.py            # read-only tools
python scripts/smoke_live.py --train    # + a real train -> predict loop

--train のループは、対象インスタンス上にモデルセッション、実行、予測を作成します。本番環境ではなく、テスト用のインスタンスを指定してください。実行したすべてのツールが動作した場合にのみ、終了コード 0 を返します。各リリースはこの方法で検証されます。最後に検証を実行したときのバージョンは、dashai_server_info が compatibility.verified_against に報告します。

API 互換性チェック

dashAI にはバージョンエンドポイントがないため、dashai_server_info はインスタンスの openapi.json を読み取り、API の仕様をこのサーバーが実際に呼び出す内容と比較します。エンドポイントが引き続き存在するか、また POST /model-session/ がこのサーバーから送信されないフィールドを要求していないかを確認します。判定結果は compatibility.status として返されます。ok、正確な差異を示す mismatch、またはスキーマを読み取れないためほかの機能は引き続き動作する可能性がある unknown のいずれかです。この機能が存在する理由は実際にあります。dashAI の開発ブランチでは、すでにモデルセッションに evaluation_strategy フィールドが追加されています。

SDK について

MCP Python SDK 2.x が必要です。バージョン 2.0 では mcp.server.fastmcp が削除され、現在は mcp.server.mcpserver.MCPServer になっています。また、アノテーションは辞書ではなく ToolAnnotations オブジェクトになりました。多くのチュートリアルには、依然として 1.x の API が掲載されています。

ライセンス

dashAI と同じ MIT です。関係性については冒頭の注記をご覧ください。