Antigravity 2.0 でチャット側に MCP が出てこないときに確認したこと

夜間の自動更新を回す前に、チャット型エージェントのアプリを開いて、いつも使っている MCP サーバー越しにひとつ確認を投げようとしました。ところがツールの一覧に、そのサーバーがありません。IDE 側では同じ MCP をずっと使えていたので、一瞬、設定が消えたのかと手が止まりました。

結論から書きますと、消えていたわけではありませんでした。Antigravity 2.0 で IDE とチャット型エージェントが別々のアプリに分かれた結果、設定を読む場所も別々になっていた、というだけの話です。同じ症状で立ち止まる方がいそうなので、確認した順番のまま残しておきます。

症状 — 「IDE では動くのにチャットでは出ない」

私の環境で起きていたことは、次のような形でした。

IDE 側では MCP サーバーのツールが問題なく呼べる
チャット型エージェントのアプリでは、同じサーバーがツール一覧に出てこない
エラーは出ず、ただ「無いもの」として扱われる
片方のアプリで MCP を追加しても、もう片方には反映されない

エラーが出ないところが、かえって厄介でした。接続に失敗しているなら赤い表示を探せばよいのですが、静かに存在しないので、こちらの設定ミスを疑って同じ画面を何度も見返してしまいます。

なぜ分かれたのか — 2.0 のモジュラー構成

Antigravity 2.0 は、VS Code 系の IDE と、チャット型のエージェント・インターフェースという二つのアプリに分割されました。動的なサブエージェントで複数のタスクを並行させる設計に向けて、役割ごとにアプリを分けた構成です。

このとき見落としやすいのが、アプリが分かれれば設定の置き場所も分かれる、という当たり前の帰結です。ユーザー単位の設定（MCP サーバーの登録、既定モデル、各種フラグ）は、アプリごとに別のディレクトリを読みます。片方で登録した MCP は、もう片方の設定ファイルには書かれていないので、当然そちらの一覧には現れません。

つまり不具合ではなく、スコープの問題です。ここを取り違えると、再インストールや再ログインといった重い操作に走りがちですが、いずれも見当違いになります。

まず確認する — どちらのスコープに書かれているか

最初にやることは、「その MCP がユーザー単位で登録されているのか、ワークスペース単位で登録されているのか」を切り分けることです。

各アプリの設定画面から MCP の一覧を開き、それぞれのサーバーがどのスコープに属しているかを見ます。多くの場合、IDE 側でユーザー設定として登録したものが、チャット側のユーザー設定には存在しない、という形になっています。

コマンドラインからも確かめられます。両アプリの設定ディレクトリにある MCP 定義を並べて差分を取ると、どちらに何が書かれているかが一目で分かります。

# 各アプリの MCP 設定ファイルを見つける（名前はお使いのバージョンに合わせて確認してください）
find "$HOME/Library/Application Support" -maxdepth 3 -iname 'mcp*.json' 2>/dev/null
 
# 2つの定義を比較する（パスは上のfindで見つかった実ファイルに置き換えます）
diff <(jq -S '.mcpServers | keys' ide-app/mcp.json) \
     <(jq -S '.mcpServers | keys' chat-app/mcp.json)

差分に出たサーバーが、片方にしか無いものです。私の場合は、IDE 側にだけ 3 つ登録があり、チャット側は空でした。原因が「同期漏れ」だと分かるだけで、対処の方針が決まります。

対処 — ワークスペース単位に真実源を一本化する

手っ取り早いのは、足りない定義を片方からもう片方へコピーすることです。ただ、これは対症療法にすぎません。次にどちらかで設定を足したとき、また同じずれが生まれます。

私は、MCP の定義をユーザー単位で二重に持つのをやめて、ワークスペース単位の設定ファイルに寄せる形にしました。リポジトリの中に設定を置き、両アプリともそれを読ませます。こうすると、真実源がリポジトリの中の 1 ファイルになり、アプリが増えても増減がぶれません。

// <リポジトリ>/.antigravity/mcp.json （ワークスペース単位・バージョン管理下に置く）
{
  "mcpServers": {
    "my-content-tools": {
      "command": "npx",
      "args": ["-y", "@example/content-mcp"],
      "env": { "API_KEY": "${env:CONTENT_MCP_KEY}" }
    }
  }
}

鍵になるのは、秘密情報をこのファイルに直接書かないことです。${env:...} のように環境変数を参照させておき、実際のキーはアプリ側の環境やシークレット管理に置きます。ワークスペース設定はリポジトリに入れて共有したいので、鍵が混ざると事故になります。

設定を寄せたら、両アプリを一度再読み込みして、それぞれのツール一覧に同じサーバーが並ぶことを確かめます。私は個人開発で Dolice Labs という複数のサイトを運用しているので、リポジトリごとに .antigravity/mcp.json を持たせておくと、どのプロジェクトを開いてもツールの構成が揃っていて、確認の手間が減りました。

CLI も同じ経路で揃える

Antigravity には CLI もあり、私は夜間の自動処理でそちらを使っています。ここでも同じ落とし穴があります。CLI が読む MCP 設定が、IDE やチャットアプリのユーザー設定と別だと、手元では動くのにスケジュール実行では MCP が見つからない、という形で表面化します。

対処は同じで、ワークスペース単位の定義を CLI にも読ませます。プロジェクトのディレクトリを起点に CLI を起動し、リポジトリ内の .antigravity/mcp.json を参照させておけば、対話・チャット・自動処理の三経路で同じ構成になります。放置して回す自動処理ほど、こうした「見つからないのに静かに進む」ずれが後で効いてくるので、経路をまたいで真実源を一つにしておく価値があります。私自身、最初はこのずれに気づかず、手元では通るのにスケジュール実行だけが無言で MCP を欠いたまま進んでいたことがありました。ログには失敗も出ないため、結果を見比べて初めておかしいと分かる種類のずれです。

再発を防ぐ小さな点検

一度揃えても、あとから片方のアプリの画面でうっかり MCP を足すと、またユーザー単位のずれが戻ってきます。私は簡単な点検を習慣にしています。

# ワークスペース定義に載っているサーバー名の一覧を確認する
jq -r '.mcpServers | keys[]' .antigravity/mcp.json
 
# ユーザー単位の設定に、ワークスペースと重複する登録が紛れていないかを見る
# （重複があれば、どちらが優先されるか分からなくなる前に片方へ寄せる）

やっていることは単純です。ワークスペースの 1 ファイルを正とし、ユーザー単位には同じサーバーを重ねて置かない。この一点を守るだけで、「IDE では動くのにチャットでは出ない」という最初の症状には戻らなくなりました。

次に同じ状況になったら、まず「壊れた」ではなく「どのスコープに書かれているか」を先に疑ってみてください。設定ディレクトリの差分を一度取れば、たいてい 1 分で切り分けられます。お読みいただきありがとうございました。