MCPメモ

MCP が話題だけど（何ができそうかではなく）何を実現しようとしてどんな制約があってどうやって実現するのかがよく分からないので自分の視点で気になることを調べてみた。

分かりやすい言い換えをしてくれてる資料はあるけど、あれは原理が分かるようにならないので今回は取り上げない。

Protocol がどれくらい安定しているのかもよく分からないけど、IETF の RFC ほどには厳格に管理されてなくて、日付の revision が剥き出しで使われているところを見るとまだまだ元気に変わっていきそうではある。

こんな感じかなぁ

公式サイトを見ながら自分なりに書いたりしてみる。

全体構造

Architecture – Model Context Protocol Specification

Base Protocol – Model Context Protocol Specification

  • Hosts
    • アプリケーション全体で見るとこいつが要。認可もこいつが担うし、LLM との統合も担う
  • Clients
    • server ごとに stateful で routing を行う
    • 他の server のことは知らないし、預かり知らない server の情報が漏れてもいけない
  • Servers
    • resource, tool, prompt を公開する（prompt ?）
    • セキュリティは尊重しないとダメ

specification/schema/2025-03-26/schema.ts at main · modelcontextprotocol/specification

Requests

{
  jsonrpc: "2.0";
  id: string | number;
  method: string;
  params?: {
    [key: string]: unknown;
  };
}

Responses

{
  jsonrpc: "2.0";
  id: string | number;
  result?: {
    [key: string]: unknown;
  }
  error?: {
    code: number;
    message: string;
    data?: unknown;
  }
}
  • stateful で id を持っている （ Notification の場合は id は含めたらダメ )

Model Context Protocol specification – Model Context Protocol Specification

Server Features

Server Features – Model Context Protocol Specification

これがいちばん謎だったけど、

Servers provide the fundamental building blocks for adding context to language models via MCP. These primitives enable rich interactions between clients, servers, and language models:

  • Prompts: Pre-defined templates or instructions that guide language model interactions
  • Resources: Structured data or content that provides additional context to the model
  • Tools: Executable functions that allow models to perform actions or retrieve information

からの

Prompts – Model Context Protocol Specification

で

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "prompts": [
      {
        "name": "code_review",
        "description": "Asks the LLM to analyze code quality and suggest improvements",
        "arguments": [
          {
            "name": "code",
            "description": "The code to review",
            "required": true
          }
        ]
      }
    ],
    "nextCursor": "next-page-cursor"
  }
}

てことは MCP server の response を LLM でどのように料理すればよいかを教えてあげるためのものなのかな。

Tools

Tools - Model Context Protocol

Overview

Tools in MCP allow servers to expose executable functions that can be invoked by clients and used by LLMs to perform actions. Key aspects of tools include:

  • Discovery: Clients can list available tools through the tools/list endpoint
  • Invocation: Tools are called using the tools/call endpoint, where servers perform the requested operation and return results
  • Flexibility: Tools can range from simple calculations to complex API interactions

Like resources, tools are identified by unique names and can include descriptions to guide their usage. However, unlike resources, tools represent dynamic operations that can modify state or interact with external systems.

discovery はこの辺で実現してるのか。実装方法は知らないけど annotation を持ってる言語はそれで、Ruby なら DSL で書いて、書いたら自然と情報が集まるような格好かな。

{
  name: string;          // Unique identifier for the tool
  description?: string;  // Human-readable description
  inputSchema: {         // JSON Schema for the tool's parameters
    type: "object",
    properties: { ... }  // Tool-specific parameters
  }
}

これが OpenAPI みたいに tool のリストに含まれるのか。

役割

  • LLM の理解しやすい情報として外部の環境を与える
  • Web サービスにおける OpenAPI のような役割もあると思う（tool discovery）

メリット

  • アプリ独自に API クライアントを作らなくてよい。図では便宜的に Web API のような感じに見える描き方にしてあるが、OS 内のコマンドでもなんでもよい。これらの違いをすべて MCP が隠蔽してくれる
  • つまり実装言語もなんでもよい
  • LLM を利用するアプリケーション本体と認証など秘密情報の扱いを分離できる
  • アプリ（MCP Host）実装者は MCP Client-Server のセットの揃っているツールを利用できるなら楽できそう

生成 AI 関係の話を漁るとだいたい LangChain の話に行き着くのが「なんでやねん」とずっと思っていたんだけど、これで「そういうことじゃないんだよな」という状況になりそう。LangChain が中心にならなくても MCP を経由して Tool を使えるようになるので、別に Python や JavaScript に縛られる必要がない。これはよい。

注意

  • セキュリティについては LLM アプリケーションそのものではなく MCP クライアント - サーバおよび利用者に移譲される
  • ユーザーは MCP Hosts が承認を求めてきた操作について理解して許諾する必要がある
  • 信頼できない MCP サーバをほいほい利用してはならない

More