プロジェクト直下の mcp_config.json が読まれているのに MCP が立ち上がらない — プローブ 1 本で確かめる

プロジェクトごとに別の MCP サーバーを持たせたくて、リポジトリの直下に設定ファイルを置く。ごく自然な手順です。

起動すると、ログには「このプロジェクトのファイルを使う」という趣旨の行が出ています。ところがツール一覧には、ホーム側に入れてある MCP のものしか並びません。置いたファイルは読まれているはずなのに、サーバーは一つも増えていないのです。

この状態で設定の綴りを何度も見直して、夜が更けていく。報告を読むかぎり、疑う順番を一つ間違えているのだと思います。先に疑うべきなのは自分の目ではなく、ログの文言のほうです。

最初にお伝えしたいこと

この症状は、Antigravity CLI の公式 Issue（google-antigravity/antigravity-cli の #60）で報告されています。報告者が v1.0.0 で確かめた内容は次のとおりです。

• プロジェクト直下の .antigravitycli/mcp_config.json は起動時に見つかり、そのことがログにも出ています
• しかし mcpServers は無視され、サーバーは起動しませんでした
• ホーム側の ~/.gemini/antigravity-cli/mcp_config.json に書いたサーバーだけが起動しました

個人開発で壁紙アプリの運用と Web サイトの保守を並行しているため、私は CLI のバージョンごとの挙動をすべて自分で追えているわけではありません。以降は「Issue に書かれていること」と「手元で確かめられること」を分けて書きます。

ログの一行が約束していないこと

Issue に引用されているログは、おおよそ次の形でした。

project: discovered project ... via /tmp/agy-test-995/.antigravitycli
project: using project ... at /private/tmp/agy-test-995/.antigravitycli/mcp_config.json

「using project」とあるので、この設定で MCP が動くと読みたくなります。ただ、Issue のコメントでは別の見立てが示されています。.antigravitycli/ はプロジェクトの識別子を保管するためのディレクトリで、MCP の設定を探す場所（コメントの言葉では customization root）ではないのではないか、という仮説です。

つまり、あの行が伝えているのは「プロジェクトを見つけた」ことまでで、「この中の mcpServers を使う」ことまでは約束していない可能性があります。これは仮説であって、公式が確認した仕様ではありません。

自分の環境で起動の有無を確かめるプローブ

設定の書き方が悪いのか、そもそも読まれていないのかを切り分けるには、起動したことが外から分かるサーバーを置くのがいちばん早いです。次の Python は、起動された瞬間にログへ一行を書き、tools/list に目印付きのツールを一つだけ返します。

何を解決するか: 「設定は正しいのに起動されない」のか「起動はされたがツールが見えない」のかを分ける。

#!/usr/bin/env python3
"""最小の MCP stdio プローブ。起動時にログへ 1 行残し、tools/list に 1 個だけ返す。"""
import json, os, sys, time
 
MARKER = os.environ.get("PROBE_MARKER", "unnamed")
LOG = os.environ.get("PROBE_LOG", os.path.expanduser("~/probe_mcp.log"))
 
def log(msg):
    with open(LOG, "a", encoding="utf-8") as f:
        f.write(f"{time.strftime('%H:%M:%S')} pid={os.getpid()} cwd={os.getcwd()} marker={MARKER} {msg}\n")
 
log("spawned")  # 起動された証拠。これが無ければ設定は読まれていない
for line in sys.stdin:
    line = line.strip()
    if not line:
        continue
    req = json.loads(line)
    method, rid = req.get("method"), req.get("id")
    log(f"recv {method}")
    if method == "initialize":
        result = {"protocolVersion": "2024-11-05", "capabilities": {"tools": {}},
                  "serverInfo": {"name": f"probe-{MARKER}", "version": "0.1.0"}}
    elif method == "tools/list":
        result = {"tools": [{"name": f"whoami_{MARKER}", "description": "どの設定から起動したかを返す",
                             "inputSchema": {"type": "object", "properties": {}}}]}
    elif rid is None:
        continue  # 通知には返事をしない
    else:
        result = {}
    sys.stdout.write(json.dumps({"jsonrpc": "2.0", "id": rid, "result": result}) + "\n")
    sys.stdout.flush()

なぜこう書くか: 先頭の log("spawned") を for の前に置いているのが要点です。プロトコルのやり取りが失敗しても、プロセスが生まれたことだけは残ります。ログが空なら「設定が読まれていない」、ログがあってツールが見えないなら「起動後のやり取りの問題」と、原因の層が一つ絞れます。

まず CLI を介さずに、プローブ単体が動くことを確かめておきます。

printf '%s\n' \
  '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{}}' \
  '{"jsonrpc":"2.0","method":"notifications/initialized"}' \
  '{"jsonrpc":"2.0","id":2,"method":"tools/list"}' \
  | PROBE_MARKER=local PROBE_LOG=./t.log python3 probe_mcp.py
cat t.log   # spawned / recv initialize / recv notifications/initialized / recv tools/list の 4 行

置き場所を変えて、ログの有無だけを見る

プローブを二つの設定に別の目印で登録します。マーカーが違えば、どちらから起動したかがログで分かります。

{
  "mcpServers": {
    "probe_project": {
      "command": "python3",
      "args": ["/path/to/probe_mcp.py"],
      "env": { "PROBE_MARKER": "project", "PROBE_LOG": "/path/to/probe.log" }
    }
  }
}

この内容を、プロジェクト直下の .antigravitycli/mcp_config.json に置いた場合と、ホーム側の設定（Issue が示すパスは ~/.gemini/antigravity-cli/mcp_config.json、Antigravity 2.0 側は ~/.gemini/config/mcp_config.json）に置いた場合で、マーカーだけ変えて試します。

Issue の報告どおりなら、一行目と二行目の組み合わせになります。ただ、私はこの挙動を自分の環境で再現して確かめたわけではありません。皆さまの環境で一度だけ回していただければ、どの行に当たるかは数分で分かります。

回避策として報告されていたものと、その後

Issue のコメントには、.antigravitycli/ ではなくワークスペース直下の .agents/mcp_config.json に置けば読まれた、という報告がありました（v1.0.3・macOS）。

その後の別のコメントでは、v1.1.3 で同じ手順を試したところ、読まれなかったという報告が続いています。ホーム側の設定を空にしても、ワークスペース側の設定からはサーバーが一つも起動せず、ログにもワークスペースの設定を探した形跡がなかったそうです。

回避策は版によって効いたり効かなかったりしたことになります。プローブを置いて自分の版で確かめるのが、この話でいちばん確実な手順になります。

プロジェクトごとに分けたいときの現実的な線引き

Issue の議論では、プロジェクトごと、あるいは起動ごとに別の MCP を持たせたい人が複数いました。起動オプションで設定ファイルを渡す形が欲しい、という要望も出ています。私自身の作業では、現時点で次の運用に落ち着いています。

• サーバーはホーム側に置き、名前にプロジェクトを示す接頭辞を付けています（shop_db、blog_cms のように）
• 使わないプロジェクトのサーバーは、agy mcp サブコマンドで disable にしておきます（手順は設定ファイルを開かずに MCP サーバーを足すに書きました）
• 設定ファイルを手で編集してスキーマ違反になったときは、先に原因を切り分ける記事の順番で見ます

地味ですが、ホーム側のサーバーが増えて見通しが悪くなったときに、接頭辞でそろえた名前が棚卸しの手がかりになります。

ログの文言ではなく、起動の事実で判断します。 この線引きを、設定まわりで迷ったときの戻る場所にしたいと思っています。

次にやること

プローブを一つ作り、プロジェクト直下とホーム側のそれぞれに別のマーカーで登録して、spawned が出る側を確かめてみてください。結果が分かれば、設定の書き方を疑う時間をまるごと手放せます。