MCP（Model Context Protocol）の世界へようこそ！入門ガイド

MCP（Model Context Protocol）の概要や基本概念を解説するページです。AIと外部システムを繋ぐ新しい標準規格について、まずはここからチェックしましょう。

仕様側でこれを緩和する機能があればよかったのに

彼らの解決策はいいと思うよ。リモートのMCPサーバーがHTTPベースで構築されていることを考えると、まさに仕様通りの使い方をしてるって感じだね。要求されたらHTMLを返すっていう。

ちょっと強引な方法をとったんだけど、GET /mcpへのリクエストでAcceptヘッダーにtext/htmlが含まれていて、かつapplication/jsonやtext/event-streamが含まれていない場合にHTMLページを返すようにした

これってリクエストヘッダーの本来の使い方じゃないの？

最高だね。こういう小さな工夫こそ、もっと一般的になるべきだと思う。

知識のないユーザーがリンクをそのままエージェントに投げ込んじゃった時にも役立つはず。エージェントがユーザーにメッセージを中継してくれるようになるからね。

MCPのルールが大嫌いすぎて、OAuthのフローを真似して強引にデータを流し込むことでCookieベースの認証を無理やり動かしたよ。

そもそもクリックしてほしくないなら、なんでMCPサーバーのURLをクリック可能なリンクとして表示するのさ？等幅フォントの枠に入れて「クリップボードにコピー」ボタンを添えればいいじゃん。クリック可能なリンクを表示しておいて、クリックしたユーザーに「先読みしなかった」と責任を押し付けるのは筋違いだよ。

代わりにちょっとしたハックをしたんだ。GET /mcpへのリクエストでAcceptヘッダーがtext/htmlで、application/jsonやtext/event-streamじゃない場合、これはMCPサーバーへのアクセスだからクライアントに追加してね、と説明するHTMLページを返すようにした。

それってハックというより、HTTPヘッダー本来の目的をちゃんと活かしてるだけじゃないかな。クライアントがHTML形式でリソースを求めてきた時に、どう表示するかを理にかなった形で判断してるわけだし。「ここはHTMLで表示する場所じゃないよ。代わりにこれをしてね」っていうHTMLレスポンスを返すのは、完璧にアリなやり方だと思うよ。

今週、エンタープライズ顧客向けにMCPのワークショップをやるんだけど、text/event-streamなしで/mcpにGETした時に返される406エラーについて説明するのは、まさに必ず盛り込まないといけないトピックの一つだね。

仕様に関してはまだまだ改善の余地が多いよ。特に認証周りはね。MCPでの認証には「ダメな方法」が山ほどあって、「良い方法」はほんの少ししかない。それに、IdPベンダー各社に過度な負担をかけているし、OAuth 2.0/2.1のあまり使われていない機能（DCRやトークン交換など）に依存しすぎている。当初はノートPCでMCPサーバーを動かすか、SaaSが多数のユーザーに提供するような環境を想定していたんだろうけど……最初の仕様にDCRを盛り込んだのは（ネタバレ：失敗だったけど）いいアイデアだと思われていたみたいで、幸い最新の改訂でそこはある程度改善された。XAA/ID-JAGやCIMDなどが、エンタープライズ向けのクライアント管理や認証ソリューションを補完していってくれることを期待してるよ。

ゲートウェイも仕様で扱うべき課題だね。仕様書に正式な定義がないのに、「ゲートウェイ」を名乗るものは世の中にたくさんある。ゲートウェイとは何で、何をすべきなのか。それは誰に聞くかによって答えが変わるオープンな問いのままだよ。例えば、トークン交換を担うのはMCPサーバーか、それともMCPゲートウェイか？現時点では、実装や個人の意見によってどちらも正解になり得る状況だ。

今年はさらに仕様のアップデートが期待できるはず。個人的にはMCP全体に対してかなり楽観的だよ。エージェント間のツール呼び出しを標準化する良い方法だし、リソースやプロンプトといった機能はエージェントの動作をより決定論的にするために本当に役立つからね。インタセプターやスキルも今後が楽しみだよ。

仕様の進化に協力したいなら、MCP ContributorsのDiscordが活発だから覗いてみて。フィードバックを求めるIG（Interest Group）やWG（Working Group）がたくさんあるし、ミーティングに参加して意見を届けることもできるよ。

正直、なぜ/mcpエンドポイントが必要なのかよく分からないな。

Swaggerドキュメントを使ったREST APIをそのまま使い続けて、AIにそのドキュメントを読ませれば済む話じゃないかな。同じことだよ。REST APIの仕様全体の方が、/mcpが使っているJSON RPCフォーマットよりもはるかに柔軟だしね。

「（面倒な）解決策は、サーバーをコネクターやプラグインとしてパッケージ化して、あらゆるLLMクライアント向けにリリースすることだ」

それって、MCPの存在意義を完全に否定してないか？