先月、あるチームが天気データを取得するための MCP サーバーを構築するのに9日間費やすのを目撃した。9日間だ。エージェントは1つの curl と1行のツール定義で API を叩けばよかったはずだ。しかし MCP が輝いていたから、MCP になった。
静かな部分を大声で言おう：何でもかんでも MCP サーバーを作るのをやめるべきだ。Model Context Protocol は本当に優れている。しかし「標準」と聞いて「必須」と思い込んだ人たちによって、野放図に使われすぎている。
MCP が本当に何のためにあるか
MCP は本物の問題を解決する。多くのエージェントに、多くのクライアントにわたって、一貫したインターフェースで公開したい機能がある場合だ。組織全体がクエリする데ータベース。デザインシステム。12種類の異なるツールが叩く必要のある内部検索インデックス。サーバーを一度構築すれば、Claude Desktop、Cursor、独自のハーネスがすべて同じ方法でそれと話す。それが利点だ。クライアントをまたいだ再利用。
それだけだ。それが全体の売り込みだ。複数のクライアントや複数のエージェントにわたる再利用を得られていないなら、何の意味もなくプロトコルの税金を払っている。
誰も言及しない税金
すべての MCP サーバーはプロセスだ。ライフサイクルがある。ハングしたり、切断されたり、静かに応答を停止したりする可能性のあるトランスポート（stdio または SSE）がある。呼び出すかどうかに関わらず、ツール定義をコンテキストウィンドウにロードする。おしゃべりな MCP サーバー1つが、モデルが実際のタスクの最初の言葉を読む前に4,000トークンのコンテキストを食い尽くすのを見たことがある。
そして管理しなければならない。バージョン管理。その中での認証処理。エージェントが「ツールが応答していない」と言ったときのデバッグ。サーバーなのか、トランスポートなのか、それともモデルがツール名を幻覚しているのか分からない。
エージェントが直接呼び出す普通の関数や、Bash を通して実行する CLI コマンドと比べてみよう。Claude Code エージェントが GitHub API を叩く必要があるとき、gh を実行する。サーバーなし。プロトコルなし。ライフサイクルなし。ツールはすでにマシンに存在し、モデルはすでにその使い方を知っている。
正直な意思決定ルール
サーバーコードを1行書く前に実際に使うテストはこれだ：
- 2つ以上のクライアントまたはエージェントがこれを使うか？そうでないなら、MCP をスキップ。
- すでにそれをやる CLI があるか？あるなら、エージェントに CLI を実行させる。
- 1つのプロジェクト向けの一度限りの統合か？サーバーではなくローカルツールを書く。
- このリポジトリを超えて存続し、共有される必要があるか？今こそ MCP が意味をなす。
答えが「MCP をスキップ」になることがどれだけ多いかに注目してほしい。1つのプロダクトをリリースするソロビルダーにとって、ほぼ常にスキップだ。多くのクライアントはいない。1つだ。所有していないフリートのためのインフラを構築している。
ラッパーの罠
最も一般的な悪い MCP サーバーは API ラッパーだ。誰かが、すでに十分に文書化されていて、すでに OpenAPI 仕様があり、すでにベアラートークンで動く REST API を取って、MCP でラップする。なぜ？エージェントは仕様を読めた。リクエストを作れた。モデルがすでに得意だったものとの間に翻訳レイヤーを追加してしまった。
さらに悪いことに、実際の API のサーフェスを手作りのツール定義の裏に隠してしまった。API には40のエンドポイントがある。サーバーは6つを公開している。なぜなら火曜日に必要だったのがそれだったから。今、新しいサーバーバージョンをリリースしない限り、エージェントは文字通り他の34のことができない。
根底にあるものが HTTP API なら、まずこれを試してほしい：
# エージェントにそのまま呼び出させる
curl -s https://api.example.com/v1/items \
-H "Authorization: Bearer $TOKEN" | jq '.items'
モデルにベース URL、認証パターン、ドキュメントを渡す。動くのを見る。「MCP サーバーが必要」という要件が消えることの多さに驚くだろう。
MCP を使う場面
私は反 MCP ではない。4つの別々のエージェントがクエリするベクターストア向けに1つ作った。4回再実装したくなかった共有エンベディングロジックがあった。それがスイートスポットだ：本物の共有状態、本物のマルチコンシューマー、ロジックを複製することへの本物のコスト。プロトコルはその場所を獲得した。
ステートレス CLI では適切に管理できない方法でステートフルである必要がある機能のときも使う。長命のコネクションプール、キャッシュされたインデックス、再確立がコストのかかる認証セッション。サーバーが状態を保持し、エージェントがそれを借りる。良いフィット。
しかしそれらは特定のケースだ。「すべての統合」ではない。デフォルトは：直接ツール、または CLI、または普通の関数であるべきだ。MCP は出発点ではなく、エスカレーションだ。
履歴書主導開発の問題
なぜこうなるのか正直に言おう。MCP は新しくて話題で、「MCP サーバーを構築した」はスタンドアップで「12行のツール定義を書いた」より聞こえが良い。分かる。印象的に聞こえるものを作るインセンティブがある。
しかしユーザーはアーキテクチャを気にしない。エージェントがフィーチャーをリリースするかどうかを気にしている。シングルコンシューマーの統合のためにプロトコルの配管を構築するのに費やす時間は、プロダクトに費やさなかった時間だ。最もシニアなアクションはしばしば退屈なものだ：サーバーをスキップし、API を呼び出し、前進する。
多くの口を養うものがあるときに MCP サーバーを構築せよ。それまでは、エージェントにはシェルがある。使わせよう。