金曜の夜、IDE を開いたところ、MCP の設定ファイルに赤い波線が並んでおりました。登録してあるサーバーの数だけ、同じ一文が繰り返されております。Additional properties are not allowed ('$typeName' was unexpected)。
手が止まりました。週末に回すつもりだった処理が、全部そこで止まるのだと思ったのです。
念のためエージェントに小さな用事を一つ頼んでみますと、そのサーバーのツールはふつうに返ってまいりました。赤かったのは設定ファイルの表示だけで、実行の側は何も欠けていなかったのです。
直す前に確かめます。その順番を逆にしていたのだと気づいたのは、三十分ほど溶かしたあとでした。
赤い表示が答えているのは、別の問いです
エディタが出す波線は、同梱されている JSON スキーマに設定ファイルを照らした結果です。一方で、実際に MCP サーバーを起動して接続するのは、そのスキーマを経由しない別の経路です。
スキーマが additionalProperties: false（宣言していないキーを許さない）で書かれている場合、知らないキーがひとつ混ざっているだけで、そのサーバーの定義全体が赤くなります。中身が正しいかどうかは、そこでは問われておりません。
エディタが答えているのは「スキーマに載っている書き方か」であって、「いま動いているか」ではありません。 この区別を置き違えていたのが、私の三十分でした。
/mcp の状態リングが、動いているかどうかを答えます
公式ドキュメントによれば、プロンプトパネルで /mcp と入力して Enter を押すと、MCP Manager のオーバーレイが開きます。ここには接続中・切断・読み込み中を示す状態リングと、リアルタイムの接続ログが出ます。設定ファイルの見た目ではなく、接続そのものを見るための場所です。
私が踏んでいる順番は、ほんの四段です。
/mcpを開きます- 赤い波線が出ていたサーバー名の状態リングを見ます
- 接続中であれば、赤は表示側の問題として保留します
- 切断であれば、その場で接続ログを開きます
ログまで開いてから設定ファイルへ戻ると、直すべき行がだいたい一行か二行に絞れております。反対に、ログを見ないまま設定ファイルを直し始めますと、動いていたものまで触ってしまいます。
なお、ツールが最初から欠けたまま会話が始まってしまった場合の見切り方は、MCP が欠けたまま始まったセッションを、どこで止めるか に別途まとめております。
二つのアプリが、同じ一つのファイルを見ておりました
公式の MCP ドキュメントは、設定の置き場所を二段に分けています。グローバルは ~/.gemini/config/mcp_config.json、ワークスペース単位は作業中のプロジェクト直下の .agents/mcp_config.json です。
問題は、同じマシンに Antigravity 2.0 と Antigravity IDE の両方を入れている場合に、グローバル側を二つのアプリが共有してしまう点にあります。
報告されている例では、2.0 が書き込む $typeName（Protobuf の型識別子）を、IDE に同梱されたスキーマが未知のキーとして弾きます。実際に書き込まれているのは、こういう形です。
{
"mcpServers": {
"github": {
"$typeName": "…",
"serverUrl": "https://api.githubcopilot.com/mcp/",
"headers": {
"Authorization": "Bearer YOUR_API_TOKEN"
}
}
}
}ここで $typeName の行だけを消しますと、その場の赤は消えます。ところが 2.0 の側がこのファイルを書き直したときに同じキーが戻り、赤も戻ります。手作業で消して回ると、消した回数だけ同じ夜を繰り返すことになります。
私は消すのをやめて、いまは 設定ファイルを直す前に、そのファイルを書いているのが誰かを先に確かめる ことにしております。自分が書いた行であれば直します。別のアプリが生成している行であれば、赤のまま置いて /mcp の状態だけを信用します。
この報告は antigravity-cli の Issue #986 で追えます。修正の提案はスキーマ側で $typeName を明示的に許す形になっており、直っていないうちは表示が赤いままです。
黙って通ってしまう書き方のほうが、こわいのです
逆の取り違えもあります。エディタは何も言わないのに、サーバーが動いていない場合です。こちらのほうが気づくのに時間がかかります。
いちばん踏みやすいのは、リモート接続のキー名です。公式ドキュメントは、SSE・Streamable HTTP・WebSocket のいずれで宣言する場合も serverUrl を定義するよう明記しており、url や httpUrl といった旧来の書き方は対応していないとしています。
{
"mcpServers": {
"my-remote-server": {
"url": "https://api.example.com/mcp/"
}
}
}{
"mcpServers": {
"my-remote-server": {
"serverUrl": "https://api.example.com/mcp/",
"headers": {
"Authorization": "Bearer YOUR_API_TOKEN"
}
}
}
}他所の設定例を持ってきたときに、この一語だけが残っていることがあります。JSON として壊れてはおりませんので、エディタは黙っています。エージェントの側は、そのサーバーが無いものとして進みます。
同じ質の見落としとして、disabled: true を付けたまま忘れている場合と、disabledTools で必要なツール名を外したままにしている場合があります。どちらも公式に用意されているキーですので、スキーマ検証は通ります。通るからこそ、目で追う対象から外れてしまうのです。
起動前に設定ファイル側をまとめて点検する書き方は、MCP サーバーが1本も起動しない原因は、起動前の 40 行で特定できます に置いてあります。あわせてご覧いただけましたら幸いです。
赤を見たときに、私がたどる順番
四つの症状で分けております。表にしておきます。
| 目にしているもの | 先に見る場所 | そこで分かること | 次の一手 |
|---|---|---|---|
| 設定ファイルが赤い／ツールは返ってくる | /mcp の状態リング |
接続中であれば表示側の問題です | 触らず保留し、書き込み元を特定します |
| 設定ファイルが赤い／ツールも返らない | /mcp の接続ログ |
起動に失敗した実際の行が出ます | ログに出た一行だけを直します |
| 赤は無い／ツールが一覧に出ない | キー名（serverUrl）と disabled |
スキーマを通る取り違えが見つかります | 公式の設定構造と1項目ずつ突き合わせます |
| 赤は無い／一部のツールだけ出ない | disabledTools と権限の設定 |
意図して外したものか判別できます | 外した理由を思い出せなければ戻します |
表にしてみますと、どの行でも最初の一手が「設定ファイルを開く」ではないことが分かります。私はこの順番を紙に書いて、モニタの端に貼っております。赤い波線を見た瞬間に、指がファイルへ伸びてしまうからです。
Lab のサイトと個人開発のアプリを並行して回しておりますと、こうした「赤いけれど動いている」「静かだけれど動いていない」の取り違えは、どの道具でも起こります。表示は補助で、実際に動いた証跡が本体なのだと、いまも自分に言い聞かせております。
次に赤い波線を見つけたときは、ファイルを閉じて /mcp をひとつ叩くところから始めていただければと思います。私はそれだけで、週末をひとつ取り戻しました。
最後までお読みいただき、ありがとうございました。