なぜ MCP なのか

なぜ自分が MCP を追いかけているのかを雑にだらだらと書いて行こうと思います。 乱文です。

オープンなプロトコル

追いかけている理由は Model Context Protocol がオープンなプロトコルにしたことです。これが ChatGPT Plugins とかのクローズドなプロトコルであれば全く追いかけていなかったと思います。

MCP は Anthoropic 以外でも MCP クライアントを実装しさえしていれば、多くの MCP サーバーと接続する事が出来ます。実際 MCP を公開した Anthropic が提供している Claude Desktop や Claude Code だけでなく Cline や Cursor などが MCP クライアントを実装したことにより、MCP サーバーさえ実装してしまえば、様々な環境で利用できる仕組みになっています。

そして VS Code も MCP クライアントを実装してきたことにより、 MCP が現時点ではLLM アプリケーションが外部と連携するプロトコルとしては、一択になった考えています。ただ、プロトコルも流行廃りはあるというのも知っているので、どうなるかはわかりません。

MCP がプロトコルである以上、MCP クライアントは誰でも実装できます。ただ大きいのは多くのシェアがある VS Code や、一般人が利用する ChatGPT Desktop が対応するということで、という面は MCP の流れは止められなさそうです。

MCP サーバーさえ実装しておけば、多くの MCP クライアントを実装しているアプリから利用してもらえるわけです。

MCP トランスポート

MCP の標準トランスポートに定義されているのは stdio と HTTP Streaming の二つがあり、今は stdio が多いですが、将来的にはサービス公式や社内向けの共通 MCP サーバーとして HTTP Streaming ベースも増えてくると思います。

MCP はトランスポートはカスタマイズ自由なのも良いところです。QUIC や WebRTC 上にも MCP は実装できます。

MCP は JSON-RPC 2.0 を採用

MCP は JSON-RPC 2.0 というシンプルなプロトコルを採用したことも気に入っています。LSP 意識したのかなと勝手に思っています。

JSON-RPC 2.0 の例

{
  "jsonrpc": "2.0",
  "method": "subtract",
  "params": [
    42,
    23
  ],
  "id": 1
}

{
  "jsonrpc": "2.0",
  "result": 19,
  "id": 1
}

めちゃくちゃしょぼくて本当に実装しやすいです。JSON ライブラリだけあればいいわけです。

MCP 認可

MCP に採用されている JSON-RPC 2.0 では認可の仕組みが定義されていない事もあり、トランスポートを HTTP にする際、認可周りだけどうなるか危惧していましたが、認可は MCP 2025-03-26 で OAuth でやっていくことが決まったので、大丈夫そうなのかなと考えてはいます。

企業によるMCP サーバーの提供

VS Code 1.99 で MCP クライアントを実装してきたことにより、開発者が利用するサービスや SDK を提供している企業は MCP サーバーを提供を求められるようになると考えています。

実際 AWS や GitHub 、Shopify などが提供を始めています。自社でも提供するために色々試しています。

ドキュメント検索機能

特に MCP 経由でドキュメントを調べられるようにするというのは企業として凄く重要だと考えています。Google NotebookLM で簡単に利用できるようにシングルページのドキュメントを提供したりもしていますが、VS Code の GitHub Copilot から質問できる方が人を選ばないと思っています。

以下は自社ドキュメントの URL を渡して HTML を JSON 化してから Markdown にして MCP サーバーから返している例です。VS Code で GitHub Copilot の MCP クライアントを利用しています。

本来はドキュメントの URL は検索サーバーを利用して「貴方が知りたい情報はこの URL にあるドキュメントに書いてありますよ」というのを返す機能を作る必要があります。

実際 AWS MCP のドキュメント検索機能は、問い合わせ内容が、どの ドキュメントの URL に書いてあるかどうかを返す検索サーバーを AWS 側が提供しています。

ちなみに、これはドキュメントをまるっと MCP 経由で渡すとコンテキストサイズが爆発するため、それを抑えるためのえ仕組みです。

クローズド環境向けと相性が良い

MCP サーバーは OSS 化しやすい事もあり、クローズド環境でも利用しやすいのも良い点だと思っています。

自作 MCP サーバーのススメ

MCP はただのプロトコルでしかないので、なんでもできます。MCP サーバーを作るのも公式 SDK を利用すればすぐです。とくに難しくありません。なんなら HTTP/1.1 アプリケーションサーバーを実装するのより簡単です。

import uuid

from mcp.server.fastmcp import FastMCP

mcp = FastMCP()


@mcp.tool()
def gen_uuidv4():
    return str(uuid.uuid4())


if __name__ == "__main__":
    mcp.run()

ぜひ、自分たちが使いたい MCP サーバーを作って、使っていきましょう。