はじめに
対象読者は、MCP（Model Context Protocol）対応のCLIクライアントを試してみたいエンジニアです。2026年7月22日にPyPIへ公開された mcp-cli（GitHub: chrishayuk/mcp-cli）は「Ollama＋gpt-ossをデフォルトにして、APIキーなしでも動く」ことを売りにしたMCPクライアントです。手元の環境にはGeminiとOpenAIのAPIキーがすでに設定されていたため、「APIキーが要らないツールを、あえてAPIキーありで動かしたらどうなるか」を実際に試しました。
結論から言うと、インストール自体は問題なく通ったものの、ツール呼び出しの手前で2社とも別々の形で転びました。GeminiはMCPサーバーの時刻取得ツールを一度も呼ばずに2024年の日付を答え、OpenAIは create() got multiple values for keyword argument 'model' という例外で即クラッシュしました。どちらも3回連続で同じ結果が再現しています。
TL;DR: mcp-cli 0.20.1をvenvにインストールし、公開デモMCPサーバー（
time.chukai.io）に接続してツール呼び出しを試した。①--config-fileはグローバルオプション位置では無視されサブコマンド後でしか効かない、②デフォルト設定は19サーバー中4つが認証必須（OAuth/APIキー）で401リトライが即発生する、③Geminiはツールカタログの取得に成功してもツールを一度も呼ばず日付を捏造して回答する、④OpenAIはmodelキーワード引数の衝突で例外クラッシュする、の4点を確認した。
mcp-cliとは何か
mcp-cliは、MCPサーバーと対話するためのコマンドラインクライアントです。チャットモード・インタラクティブシェル・スクリプト向けのコマンドモードを備え、mcp-cli providers コマンドを実行すると、Anthropic・OpenAI・Gemini・Groq・Mistral・watsonxなど15のLLMプロバイダーが一覧表示されます。PyPIの説明文には「Ollamaと gpt-oss 推論モデルをデフォルトにすることで、APIキーなしのローカル・プライバシー重視な動作を実現する」と明記されています。
インストール時点でのつまずき
まず手元のシステムPython環境で pip install mcp-cli を実行したところ、依存パッケージの1つである ibm-cos-sdk-s3transfer のビルドで失敗しました。エラーは setuptools の install_layout 属性エラーで、distutils 系のレガシービルドが今どきの setuptools と噛み合っていないことが原因です。venv（python3 -m venv で新規作成した仮想環境）で同じコマンドを実行すると、今度は問題なく完走しました。
インストールが完了すると、依存パッケージは 90個 にのぼります。内訳を見ると、Anthropic・OpenAI・Google Gen AI・Mistral AI・Groq・IBM watsonxの公式SDKがすべて同梱されていました。「APIキー不要」を掲げるツールが、主要LLMベンダーのSDKを一通り抱え込んでいるのは意外でした。
python3 -m venv mcp-cli-venv
mcp-cli-venv/bin/pip install mcp-cli
# => Successfully installed ... mcp-cli-0.20.1（依存90パッケージ）
つまずきポイント1: --config-file はサブコマンドの後でないと効かない
mcp-cli --help を見ると、--config-file は mcp-cli [OPTIONS] COMMAND の OPTIONS 側、つまりサブコマンドより前に置くグローバルオプションとして案内されています。実際に案内どおりの順番で実行すると、指定した設定ファイル（time サーバー1つだけを書いた最小構成）を渡していても処理がハングしました。
# ヘルプの表記どおり(グローバルオプション位置)だとハングする
mcp-cli --config-file minimal_config.json tools
--verbose を付けてログを見ると、原因はハングではなく無限リトライでした。指定していないはずの brave_search サーバー（バンドルされているデフォルト設定に含まれる、Brave Search API用のMCPサーバー）へAPIキー（Bearerトークン）なしで接続を試み、HTTP 401: Missing or invalid access token を受けて内部タスクが破棄・再生成を繰り返していたのです。
# サブコマンドの後に置くと正しく反映される
mcp-cli tools --config-file minimal_config.json
# => time サーバーの7ツールが正しく一覧表示される
--config-file をサブコマンドの後ろに移動すると、指定した time サーバーだけが読み込まれ、get_time_utc など7つのツールが正常に取得できました。ヘルプの表示順どおりに書くと動かない、というギャップです。
つまずきポイント2: デフォルト設定の19サーバー中4つが認証必須
原因を追ってパッケージ内の server_config.json を確認すると、デフォルトでは以下の19個のMCPサーバーが登録されていました。
| 種別 | サーバー例 |
|---|---|
ローカル起動（uvx/npx） |
sqlite, echo, playwright |
認証不要の公開デモ（chukai.io） |
weather, math, time, celestial, physics, geocoder など9個 |
| 認証必須（OAuth/APIキー） | notion, monday, linkedin（OAuth）／ brave_search（APIキー・Bearerトークン） |
--server でサーバー名を絞り込んでも、内部的には設定ファイル全体を読み込んでから接続を試みる挙動のため、認証情報を渡していない認証必須サーバーの401エラーが必ずログに出ます。デフォルト設定のまま何も指定せずに使い始めると、目的のサーバーにたどり着く前にエラーログの奔流を見ることになります。
つまずきポイント3: ツールを渡しても呼ばれない・落ちる
設定ファイルの問題を解消したうえで、time サーバーの get_time_utc ツールを実際に使わせてみました。
Geminiプロバイダーの場合、mcp-cli cmd --provider gemini --prompt "Use the available tool to get the current UTC time and report it back exactly." --single-turn --verbose を実行すると、tools/list でツールカタログの取得には成功する（ログに7ツール分の定義が正しく載る）にもかかわらず、tools/call のログが一度も出ないまま「The current UTC time is 2024-05-16 19:27:06 UTC.」という回答を返しました。3回実行しましたが、いずれもツール呼び出しログはゼロで、返ってくる日付は毎回微妙に異なる2024年のどこか（もう1回は19:40:02）でした。実際の実行日は2026年7月なので、これは学習データに基づくもっともらしい捏造回答です。ツールを明示的に指示しても使われないケースがある、という点は実運用で見落としやすい挙動だと感じました。
OpenAIプロバイダーの場合 は、そもそもツール呼び出し以前の段階で失敗しました。
Error: openai.resources.chat.completions.completions.AsyncCompletions.create() got multiple values for keyword argument 'model'
--model gpt-4o-mini を明示指定しても同じ例外が3回とも再現しました。mcp-cliの内部実装（chuk-llm 0.20.1）がOpenAI SDKの create() を呼び出す際に、model 引数を2箇所から渡してしまっている実装上の不具合と見られます。このバージョンの組み合わせでは、OpenAIプロバイダー経由のツール呼び出しは検証以前に成立しませんでした。
著者視点の発見ポイント
今回いちばん印象に残ったのは、「ツールが呼ばれないこと」自体はエラーにならず、静かに不正解を返すだけだった点です。OpenAI側の例外クラッシュは目に見える形で失敗するため気づきやすいのですが、Gemini側は FinishReason.UNEXPECTED_TOOL_CALL という不穏なログが一瞬出た回もあった一方で、--single-turn 実行では最終的に「もっともらしい嘘」をエラーなく返してきました。MCP対応クライアントを評価するときは、「ツールカタログを取得できるか」だけでなく「実際にモデルがツールを呼び出したか」をログで確認する工程が欠かせないと実感しました。--verbose でツール呼び出しの有無を毎回チェックする習慣がないと、この種の静かな失敗は気づかないまま見過ごしてしまいます。
まとめ
mcp-cli 0.20.1を実際にインストールし、公開デモMCPサーバーへの接続とツール呼び出しを検証したところ、次の4点が確認できました。
- システムPythonでは依存ビルドに失敗するが、venvでは問題なくインストールできる（依存90パッケージ、主要LLMベンダーSDKを全部同梱）
-
--config-fileはヘルプ上の表記（サブコマンド前）では反映されず、サブコマンド後に置く必要がある - デフォルト設定の19サーバー中4つが認証必須（OAuth/APIキー）で、未設定のまま使うと401リトライがログに流れ続ける
- ツール呼び出しはプロバイダーによって壊れ方が違う（Geminiは静かに無視して捏造回答、OpenAIは例外でクラッシュ）
「APIキー不要」という謳い文句の裏側で、実際にAPIキーを設定したプロバイダー経由の検証まで手が回っていないように見受けられました。MCPクライアントを選定する際は、対応プロバイダーの一覧だけでなく、実際にツールが呼ばれるところまで手元で確認することをおすすめします。