AI エージェントから使う

// GUIDE · AI エージェント

Vivarium MCP サーバを Claude Code / Cursor / Cline から呼ぶ。

Vivarium は MCP(Model Context Protocol)サーバを同梱しており、5 つのツールでカタログ全体をエージェントから機械的に検索・取得・branch-fix 検証できる。docs サイトを HTML スクレイプする必要はない。

// 0 · このガイドが対象にするもの

MCP 経由でカタログにアクセスするエージェント設定。

Vivarium MCP サーバ (@aletheia-works/vivarium-mcp) は Model Context Protocol の stdio トランスポート経由で 5 つのツールを提供します: list_recipesget_recipelookup_verdictmatch_errorverify_branch_fix。 エージェント側からカタログを検索し、特定レシピのメタデータを取得し、 Layer 2 / 3 の verdict スナップショットを読み、候補修正の検証フローを 組み立てられます。

JSR / npm への初回公開は現時点で意図的に保留中です。 Vivarium 全体およびサーバ機能サーフェスがまだ熟していない段階で公開すると、 まだ動かしたいインタフェースを v1 として固定してしまうため。 公開時期は維持者が別途アナウンスします。それまでは ローカルクローン経由で動かすパスが標準です。

// 1 · ローカルでビルドする

clone → bun install → bun run build。

git clone https://github.com/aletheia-works/vivarium.git
cd vivarium/packages/mcp-server
bun install
bun run build
# → dist/index.js が出来る(クライアントが起動するエントリポイント)

dist/index.js絶対パスを控えておきます。 MCP クライアント側の設定で、node 経由でこのファイルを起動する形になります。

// 2 · MCP クライアントに登録する

共通スキーマ: command + args。

MCP サーバの登録は、どのクライアントでも本質的に「command args の組」を JSON で渡す形です:

{
"mcpServers": {
  "vivarium": {
    "command": "node",
    "args": ["/abs/path/to/vivarium/packages/mcp-server/dist/index.js"]
  }
}
}

この snippet を貼る場所がクライアントごとに違うだけです:

01
Claude Code(CLI)。

claude mcp add vivarium node /abs/path/to/...dist/index.js で対話的に登録できます。あるいは ~/.claude.jsonmcpServers キーに上の JSON を直接書いても等価です。

02
Cursor。

~/.cursor/mcp.json(プロジェクト局所なら .cursor/mcp.json)に上の JSON をそのまま置きます。

03
Cline(VS Code 拡張)。

VS Code の Cline サイドバー → MCP ServersConfigure MCP Servers から JSON 編集 UI を開き、上のスキーマで追加します。

04
Continue。

~/.continue/config.yamlmcpServers セクションで command+args を YAML 形式に転記します(YAML 表記は同じ意味)。

MCP クライアント側の正典のドキュメントは modelcontextprotocol.io/clients にあります。各クライアントの設定ファイルパスは更新されることがあるので、 迷ったら本家を参照してください。

// 3 · ツール一覧

5 つすべて MCP の標準 stdio 経由で呼べる。

  • list_recipes(layer?, project?, q?) — カタログをフィルタして列挙。layer は 1/2/3 の整数、 project は上流プロジェクト名("pandas"等)、 q は slug / project / title 横断の部分文字列検索。

  • get_recipe(slug) — 1 つのレシピの全メタデータ (title / project / issue / page URL / verdict snapshot URL / GitHub source URL)。 slug が見つからなければ { found: false, error }

  • lookup_verdict(slug) — Layer 1 は { kind: "live", page_url, note }(verdict はブラウザ実行時に出る)、 Layer 2 / 3 は { kind: "snapshot", snapshot: { verdict, exit_code, image_digest, stdout, stderr_tail, ... } }

  • match_error(text, limit?) — エラー文字列・スタックトレースから 機械的トークンマッチで候補レシピをスコア順で返す。LLM もファジーマッチも使わず、 symptom / tags / project / slug への完全一致で重みづけ。

  • verify_branch_fix(slug, fix_url? | fix_source?) — 候補修正を検証するための足場ヘルパー(実行エンジンではない)。 Layer 1 は Path A — レシピページに ?fix_url= / ?fix= を 事前読み込みした compare_url を返す。Layer 2 / 3 は Path B — gh workflow run branch-fix-verdict.yml コマンドと /repro/compare deep-link を返す。フルウォークスルーは 「ブランチ修正を検証する」

// 4 · サンプルプロンプト

3 つの典型的な使い方。

01
エラー文を貼って候補レシピを探す。

このスタックトレースに合いそうな Vivarium レシピを match_error で 5 件出して: ...貼り付け...」 → エージェントが match_error を呼び、上位を表示。気になったものを get_recipe で詳細取得。

02
今この瞬間に再現するか確認する。

pandas-56679 の現在の verdict を lookup_verdict で見て」→ Layer 1 は kind: "live" なので「ページを開いて確認するURLを返却」、Layer 2 / 3 はスナップショットの数値が直接出る。

03
層・プロジェクトでフィルタして列挙。

list_recipes で Layer 2 のものだけ全部出して」→ { layer: 2 } 引数で呼ばれ、Layer 2 (Docker) レシピだけが返る。

match_error のスコアリングは 「エラーからレシピを探す」 ページとビット同一です。MCP 経由でも UI 経由でも同じ候補順が出ます。

// 5 · 詰まりやすい点

経験上、ここで止まる人が多い。

  • dist/index.js が無い。 bun run build を流していない場合に起きる。 packages/mcp-server 直下で bun install && bun run build を 1 度走らせる必要があります。

  • 絶対パスでないと一部クライアントが見つけられない。 ホームディレクトリ短縮表記や相対パスは展開されないことがあります。 $HOME/code/vivarium/... ではなく /Users/<you>/code/vivarium/.../dist/index.js のようにフルパスで書きます。

  • レシピが古い気がする。 サーバは https://aletheia-works.github.io/vivarium/api/recipes.json を 5 分 TTL でキャッシュ、ネット切断時は build-time の snapshot にフォールバック。 最新を強制したいときは MCP サーバを再起動するのが早いです。

  • Layer 1 の verdict が「snapshot じゃない」と言われる。 Layer 1 はブラウザでの実行が確定の場で、サーバ側にスナップショットを置かない設計 (Contract v1)。 エージェントには kind: "live" の page_url を提示して、 ブラウザで開いて確認させるのが正規ルートです。

// 6 · この先

MCP 経由で次にできること。

01
自分のリポジトリの CI と組み合わせる。

自分のリポジトリに統合する でCI 側の verdict 監視が立ち、エージェント側からは MCP でカタログを検索する、という両方向の組み合わせができます。

02
ブランチ修正を verdict で検証する。

修正候補が本当に reproduced → unreproduced を起こしたかをエージェントから一発で確認するフローは verify_branch_fix(Phase 7 B3 で出荷)に集約されました。フル手順は 「ブランチ修正を検証する」を参照。

手順のどこかで詰まったら、それは use-from-ai-agent のバグです。 クライアント名・OS・詰まったステップ番号を Issue に残してください。

// NEXT

自分のリポジトリに統合する

MCP からカタログが見える状態になったら、自分の CI 側でも verdict を監視するともう片側が閉じます。

VIVARIUM は ALETHEIA-WORKS の一部 · GitHub でソースを見る →