Skip to content

Architecture

Model Context Protocol（MCP）は、各 host が複数の client instance を実行できる client-host-server architecture を採用しています。この architecture により、明確な security boundary を維持し、関心事を分離しながら、ユーザーはアプリケーション間で AI capabilities を統合できます。JSON-RPC 上に構築された MCP は、client と server の間での context exchange と sampling coordination に重点を置いた、stateful session protocol を提供します。

Core Components

graph LR subgraph "Application Host Process" H[Host] C1[Client 1] C2[Client 2] C3[Client 3] H --> C1 H --> C2 H --> C3 end subgraph "Local machine" S1[Server 1<br>Files & Git] S2[Server 2<br>Database] R1[("Local<br>Resource A")] R2[("Local<br>Resource B")] C1 --> S1 C2 --> S2 S1 <--> R1 S2 <--> R2 end subgraph "Internet" S3[Server 3<br>External APIs] R3[("Remote<br>Resource C")] C3 --> S3 S3 <--> R3 end

Host

host process は、コンテナおよびコーディネーターとして機能します。

  • 複数の client instance を作成し、管理する
  • client connection の permission と lifecycle を制御する
  • security policy と consent requirement を強制する
  • ユーザーの authorization 判断を処理する
  • AI/LLM integration と sampling を調整する
  • client 間の context aggregation を管理する

Clients

各 client は host によって作成され、分離された server connection を維持します。

  • server ごとに 1 つの stateful session を確立する
  • protocol negotiation と capability exchange を処理する
  • protocol message を双方向にルーティングする
  • subscription と notification を管理する
  • server 間の security boundary を維持する

host application は複数の client を作成・管理し、各 client は特定の server と 1:1 の関係を持ちます。

Servers

server は、特化した context と capability を提供します。

  • MCP primitive を通じて resources、tools、prompts を公開する
  • 焦点の絞られた責務を持って独立して動作する
  • client interface を通じて sampling を要求する
  • security constraint を尊重しなければならない
  • local process にも remote service にもなれる

Design Principles

MCP は、その architecture と implementation を方向づける、いくつかの重要な design principle に基づいています。

  1. Servers should be extremely easy to build

    • host application が複雑な orchestration responsibility を担う
    • server は、具体的で明確に定義された capability に集中する
    • 単純な interface により implementation overhead を最小化する
    • 明確な分離により保守しやすい code を実現する

  2. Servers should be highly composable

    • 各 server は、分離された状態で焦点の絞られた機能を提供する
    • 複数の server をシームレスに組み合わせられる
    • 共有された protocol が interoperability を可能にする
    • modular design が extensibility を支える

  3. Servers should not be able to read the whole conversation, nor "see into" other servers

    • server は必要な contextual information のみを受け取る
    • 完全な conversation history は host に保持される
    • 各 server connection は分離を維持する
    • server 間の相互作用は host によって制御される
    • host process が security boundary を強制する

  4. Features can be added to servers and clients progressively

    • core protocol は最小限必要な機能を提供する
    • 追加 capability は必要に応じて negotiation できる
    • server と client は独立して進化できる
    • protocol は将来的な extensibility を考慮して設計されている
    • backwards compatibility は維持される

Capability Negotiation

Model Context Protocol は、capability に基づく negotiation system を使用します。この system では、client と server が初期化時にサポートする feature を明示的に宣言します。capability は、session 中に利用可能な protocol feature と primitive を決定します。

  • server は、resource subscription、tool support、prompt template などの capability を宣言する
  • client は、sampling support や notification handling などの capability を宣言する
  • 両者は session 全体を通して、宣言した capability を尊重しなければならない
  • 追加 capability は、protocol の extension を通じて negotiation できる
sequenceDiagram participant Host participant Client participant Server Host->>+Client: Initialize client Client->>+Server: Initialize session with capabilities Server-->>Client: Respond with supported capabilities Note over Host,Server: Active Session with Negotiated Features loop Client Requests Host->>Client: User- or model-initiated action Client->>Server: Request (tools/resources) Server-->>Client: Response Client-->>Host: Update UI or respond to model end loop Server Requests Server->>Client: Request (sampling) Client->>Host: Forward to AI Host-->>Client: AI response Client-->>Server: Response end loop Notifications Server--)Client: Resource updates Client--)Server: Status changes end Host->>Client: Terminate Client->>-Server: End session deactivate Server

各 capability は、session 中に使用する特定の protocol feature を有効にします。たとえば、次のようになります。

  • 実装された server features は、server の capabilities 内で広告されなければならない
  • resource subscription notification を送出するには、server が subscription support を宣言する必要がある
  • tool invocation には、server が tool capability を宣言する必要がある
  • Sampling には、client が capabilities 内で support を宣言する必要がある

この capability negotiation により、protocol の extensibility を維持しながら、client と server はサポートされる機能について明確に理解できます。