MCP ガイド
Model Context Protocol を神格化しない: これは統合レイヤーであって宗教ではない
MCP は対応クライアントがツールを発見し呼び出すための共通プロトコルを提供します。重要な仕組みですが、CLI、API、ライブラリを消すものではありません。
MCP が解決するもの
MCP クライアントはツールを発見し、入力 schema を理解し、構造化された内容を共通の方式で受け取れます。複数のツールと複数のクライアントをつなぐ際、個別統合を減らせます。
- ツールとリソースの発見。
- 入力 schema と構造化された結果。
- 対応クライアントとサーバー間の共通チャネル。
CLI が今も重要な理由
CLI はターミナル、スクリプト、CI、リモート shell で使え、MCP クライアントがない環境でも動きます。コマンド、引数、終了コード、stdout を直接観察できるのも利点です。
qzx diagnoseProject . --json同じ中核を MCP と CLI から使う
処理本体と輸送方式を分離すれば、一つの実装を CLI と MCP の両方から公開できます。QZX Result Contract v1 は、こうした相互運用性を検証できる形で扱うための試みです。
選択基準
- 対応クライアントからの発見が重要なら MCP。
- ターミナル移植性とローカル自動化なら CLI。
- 能力の自然な境界がネットワークサービスなら API。
- 流行しているという理由だけでレイヤーを追加しない。
よくある質問
MCP は CLI を置き換えますか？
いいえ。MCP はツールの発見や構造化された呼び出しに強く、CLI はローカル自動化、スクリプト、CI、ターミナルで依然として有効です。
QZX は MCP サーバーですか？
QZX の中心はクロスプラットフォーム CLI です。Result Contract v1 は、MCP を含む構造化された利用側との相互運用を検証しやすくするためにも設計されています。
MCP を選ぶべきなのはいつですか？
互換クライアントからツールや schema を発見し、共通プロトコルで呼び出したい場合です。単純なローカル処理では CLI の方が直接的なこともあります。