はじめに
GoogleのGemini CLIは、MCP (Model Context Protocol) を通じて外部のAIエージェントやツールと連携できる強力な機能を備えています。
今回は、人気のノーコードAIアプリ開発プラットフォームであるDifyをMCPサーバーとしてGemini CLIに接続しようとした際に直面した、問題とその解決に至るまでの道のりをまとめます。
問題：ドキュメント通りなのにMCPサーバーが「認識しない」
最初に、Difyの公式ドキュメントに従い、発行されたMCPサーバーのURLをGemini CLIの設定ファイル .gemini/settings.json に記述しました。
当初の設定 (.gemini/settings.json)
{
"mcpServers": {
"dify_mcp": {
"url": "https://api.dify.ai/mcp/server/{あなたのMCP固有のパス}/mcp"
}
}
}
しかし、この設定ではGemini CLIが `dify_mcp` をサーバーとして認識せず、接続することができませんでした。（この赤い丸ほんと見たくない）
原因の特定：2種類のURLキー
curlでの疎通確認やバージョンチェックなど、様々な調査を行いましたが、解決には至りませんでした。
最終的な答えは、ユーザーコミュニティの情報とGemini CLIの公式ドキュメントにありました。
Gemini CLIには、MCPサーバーを指定するためのURLキーが2種類存在したのです...
-
url: SSE (Server-Sent Events) 方式で通信するサーバーを指定するためのキー -
httpUrl: 一般的なHTTPストリーミング方式で通信するサーバーを指定するためのキー
DifyのMCPサーバーは後者の「HTTPストリーミング」方式で動作していたため、正しいキーは `httpUrl` でした。
最初に url を使って失敗したのは、Gemini CLIがDifyサーバーとSSE方式で通信しようとして、うまくいかなかったためです。
解決策
キーを "url" から "httpUrl" に変更したところ、無事にGemini CLIがDifyのMCPサーバーを認識しました。
最終的に動作した設定 (.gemini/settings.json)
{
"mcpServers": {
"dify_mcp": {
// DifyはHTTPストリーミング方式のため、キーは "httpUrl" が正しい
"httpUrl": "https://api.dify.ai/mcp/server/XXXXXXXXXXXXXXXX/mcp"
}
}
}
通信方式を見分けるには
1. サービスの公式ドキュメントを確認する（最も確実）
最も確実ですが、今回のようにドキュメントに記載がないケースがあります。
2. curl でレスポンスヘッダーを確認する
サービスごとに方式がどちらであるかを見分ける方法としてはcurlコマンドを打ってみるとわかることがあります。
// 例でcontext7のMCPサーバーに接続（SSE方式）
curl GET https://mcp.context7.com/mcp
Content-Type: text/event-streamという行が含まれていれば、そのサーバーはSSE方式である可能性が非常に高いです。
そうでなければ、一般的な「HTTPストリーミング」方式の可能性を考えます。
まとめ：MCPサーバー連携の勘所
今回の経験から、Gemini CLIと外部MCPサーバーを連携させる際の重要なポイントが2つ明らかになりました。
1. 通信方式に合った正しいURLキーを使う
MCPサーバーがどちらの方式で通信するかを確認し、url (SSE) と httpUrl (HTTPストリーミング) を正しく使い分ける必要があります。
2. 認証方式もサーバーによる
更に、MCPサーバー（AIエージェント）の実装によって、認証情報の渡し方も異なります。
* URLに認証情報を含むタイプ (Difyなど): "httpUrl" のみでOK。
* HTTPヘッダーで認証を要求するタイプ (公式ドキュメントのOpenAPIの例など): "httpUrl" と "headers" の両方が必要。
同じ問題に直面した開発者の一助となれば幸いです。