Hacker Newsで再燃したMCP論争、CLIの簡潔さとリモートMCPが両立する理由

珍しく論点が具体化したMCP論争

2026年3月14日に Hacker News に投稿された "MCP is dead; long live MCP" は、クロール時点で231 points、181 commentsを集めた。目を引いたのは、Model Context Protocol を全面否定する煽りではなく、MCP をどこでどう使うかによって評価が変わるという整理だった。元記事は、いま広がっている「CLI が MCP より優れている」という言説が一部の現実を捉えながらも、その結論を広げすぎていると見る。

主張の出発点は、ローカル stdio MCP は多くのケースで重すぎる、という点だ。小さな CLI や薄い REST wrapper で足りる場面なら、追加の MCP schema はむしろオーバーヘッドになる。特に git、curl、jq、aws のようにモデルの学習データに大量に含まれている CLI は、モデルが使い方を思い出しやすく、別の schema を最初から押し込まなくてもよいという。抽出と変換を鎖状につないで context を減らす手法も、必ずしも MCP を必要としない。

それでもMCPが消えない理由

ただし記事が面白いのは bespoke CLI の話に入ってからだ。モデルが見たことのない custom CLI には、結局 description、example、help text が必要になる。つまり context の問題は消えるのではなく、README、AGENTS.md、あるいは何度もの --help 探索へ移るだけだ、という指摘である。著者のポイントは MCP が常に優れているということではなく、custom CLI の context 節約効果は実際より大きく語られがちだということだ。

そこで重要になるのが、ローカル stdio MCP と streamable HTTP を使うリモート MCP の切り分けである。前者はもっと単純な interface で代替しやすいが、後者は組織運用で別の価値を持つ。中央化された MCP server なら OAuth の背後に secret を置けるし、薄いローカル CLI より豊かな backend capability を提供できる。GitHub のような ephemeral runtime でも同じ tool surface を配れるうえ、standardized telemetry を取りやすい。さらに MCP の prompts と resources は、場当たり的な vibe coding から再現可能な internal agent engineering へ移る際の重要な部品として扱われている。

なぜHNで刺さったのか

この整理があったからこそ、記事は Hacker News で強く反応を集めた。MCP 賛成か反対かという二項対立ではなく、tool がどこで動き、誰が共有し、どの運用保証が必要かで interface の選択は変わるという話だからだ。個人ワークフローでは CLI が最も素直な道であることは多い。一方で、認証、observability、shared agent tooling を必要とする組織では、リモート MCP がいまも有力な標準化レイヤーであり続ける、というのがこの記事の結論である。

原典: Charles Chenのエッセイ。コミュニティ議論: Hacker News.