6月30日、Evil Martiansが「Most MCP servers don't need to exist. Your case might be an exception.」と題した記事を公開した。MCPサーバーを本当に構築すべきかを判断するための実践的フレームワークについて詳しく紹介されている。
MCP（Model Context Protocol）はAnthropicが2024年末に導入したオープン標準で、Claude、ChatGPT、Cursor、VS CodeといったAIクライアントがツールを発見・呼び出し、製品側の認可・権限チェックと連携するための統一プロトコルだ。ここ数カ月でMCPサーバーの実装が急増しているが、Bloomberryが1,412のMCPサーバーを分析した調査によれば、MCPサーバーを公開している企業の約半数は、そもそも公開APIを持っていない。
Evil Martiansはこの状況を「最初のハイプウェーブが生んだ半端な実装の量産」と指摘する。
まず覚えるべき一行
APIはソフトウェアコントラクト。CLIは実行コントラクト。MCPはエージェントアクセスコントラクト。Skillsはそれらをうまく使うための訓練だ。
MCPサーバーは製品への第三のインターフェースである。第一（API）と第二（CLI）が整っていなければ、第三に土台はない。
MCPを作る前に、CLIとAPIを直せ
よくある問い「CLIを出すべきか？」は間違った問いだ。コーディングエージェントはすでにCLIを持っている。正しい問いは「既存のCLIはエージェントが操作できる品質か？」だ。
ここでいう「品質」とは、安定した非インタラクティブなコマンド、構造化された出力、プログレスバーのようなhuman-onlyパターンがstdoutに混在していないこと。Playwrightはこのトレードオフを明確に示している——CLIはトークン効率重視（コミュニティベンチマークでは約4倍のトークン削減）、Playwright MCPは永続ブラウザ状態が必要な専門ループ向け、と使い分けを明確にしている。
「APIがあるからエージェントに繋げばいい」も間違った問いだ。既存の内部APIはデータの「保存形態」に最適化されており、「何をしたいか」という意図レベルには設計されていない。IDや改ページカーソル、ネストしたオブジェクトの連鎖はデータベースのために存在する。それをそのままエージェントに渡しても、モデルは限られたコンテキストウィンドウをデータモデルの解読に浪費する。
「あなたがやっているのは、能力の公開ではなく、データベースをましなブランディングで包んだ公開だ。」
MCPに切り替えてもこの問題は解決しない。ツールがデータベースの行の形をしていれば、MCPは同じ問題を新しいプロトコルで包むだけだ。
MCPより先にSkillを試せ
Skillとは、エージェントがAPIやCLIを正しく使うための手順書・サンプル・テンプレート・スクリプトをまとめたものだ。サーバーを立てずに「使い方の規律」を与える手段と考えるとよい。Anthropicは公式のSkillsディレクトリを公開しており、NotionやCanvaのパートナー製Skillが並んでいる。
以下の状況ではMCPよりSkillが先に来る：
- 能力はあるが規律がない——エージェントはAPIやCLIを持っているが使い方が悪い（呼び出し順の間違い、エッジケースの見落とし）場合、Skillがプレイブックをコード化する。
- 需要を安く検証したい——利用実績が出れば、MCPを作る根拠が固まる。
SentryはMCPとClaude Code用プラグインを組み合わせ、共有Skillをセットで提供している。
MCPを正当化する唯一の大きなシグナル
MCPサーバーを構築すべき最大の判断基準は「自分がコントロールしていないAIクライアントが同じオペレーションを消費するか」だ。
ユーザーがClaude、Cursor、ChatGPT、GitHub Copilot、独自エージェント上で製品を利用したい——この状況が成立するとき、一つの統制されたコントラクトのコストが、N個のクライアント固有統合が徐々に乖離していくコストを下回る。
Linear、Sentry、Resend、Cloudflare、StripeがMCPを公式リリースしたのはこの理由だ。LinearはAPIを持ちつつ、ユーザーがClaude・Cursor・ChatGPT上で作業するためMCPを追加した。
MCPサーバーに入れていいもの・危ないもの
「サーバーに何が入るか言語化できないなら、まだ作る準備ができていない。ルールは短い：オペレーションをカプセル化する。ワークフローではなく。」
| 区分 | 内容 |
|---|---|
| 許可 | 決定論的な組み合わせ、バリデーション、データのプロジェクション、権限チェック、プレビュー |
| 危険 | 自律的なゴール選択、不可逆なビジネス判断、検査可能なプレビューなしの多段計画 |
| グレーゾーン | 要約、ランキング、Issue作成（明示的な制約・決定論的な入力・モデルがコミット前に提示するプレビューがある場合のみ有効） |
成功例：SentryのAPIはIssue、イベント、リリース、パフォーマンス、アラート、課金、組織管理にまたがるが、MCPは約12ツールに絞り、コーディングエージェントが本番Issueをデバッグするワークフロー一本に集中した。管理・チーム管理・課金はAPIに残す。月間5,000万リクエストを超えた。
例外：Cloudflareは約2,500エンドポイントを持ち、1ツール/1エンドポイントでは初回メッセージ前に100万トークン超のスキーマを消費してしまう。代わりにsearchとexecuteの2ツールのみを公開し、エージェントにコードを書かせる「コードモードパターン」（スキーマはサーフェスサイズに関わらず約1,000トークン）を採用した。
見落とされがちなコスト
コンテキストバジェット：Anthropicの報告では、5サーバー・58ツールの構成で初回メッセージ前に約55,000トークンを消費、最悪ケースでは134,000トークンに達した。ツールカタログはプロンプトの一部であり、インターフェース設計の悪さが直接レイテンシとコストに化ける。
セキュリティ負債：Astrixによる5,205リポジトリの監査では、88%が認証情報を要求し、53%が静的APIキーまたはPATに依存、OAuthを実装しているのは**わずか8.5%**だった。MCPはAPIセキュリティにエージェント固有のリスク（共有レジストリでのツールポイズニング、ツール出力経由のプロンプトインジェクション等）が加わる。
クライアント断片化：MCPの仕様にはtools・resources・promptsが含まれるが、クライアントごとにサポート範囲が異なる。GitHub Copilotのクラウドエージェントは現状toolsのみでresources・promptsは非対応、OAuth未対応。CursorはほぼフルサポートでElicitation（エージェントがユーザーに確認を求めるプロトコル機能）にも対応。Gemini CLIはpromptsをスラッシュコマンドとして扱う。最も弱いターゲットクライアントに合わせて設計しなければ、本番でユーザーの半分が使えなくなる。
8つの判断チェックリスト
元記事末尾には、MCPサーバーを構築すべきかを判断するための8問のフローが用意されている。全問を以下に紹介する：
- 使うのは自分がコントロールする1つの社内エージェントだけか？ → 直接APIツールを使え。MCPは不要。
- 作業はシェルパイプラインで完結するか？ → まずCLIをエージェント操作可能にせよ。
- 欠けているのは能力か、使い方の規律か？ → 規律ならSkillを出せ。
- 自分がコントロールしないAIクライアントが操作を消費するか？ → ここがYesになって初めてMCPが視野に入る。
- ツールに入れるオペレーションを一文で言語化できるか？ → できなければ設計が固まっていない。先にスコープを絞れ。
- 不可逆な操作やビジネス判断をツールに含めようとしていないか？ → 含めるなら、プレビューと明示的な確認ステップを必ず設けよ。
- 対象クライアントはtools以外（resources・prompts・OAuth）をサポートするか？ → 最も機能が限定されたクライアントに合わせて設計せよ。
- MCPサーバーのコンテキストコストを試算したか？ → ツール数とスキーマサイズを見積もり、トークン消費が許容範囲内か確認してから実装に入れ。
詳細はMost MCP servers don't need to exist. Your case might be an exception.を参照していただきたい。
