Lifecycle

Model Context Protocol（MCP）は、適切な capability negotiation と state management を確実に行うために、client-server connection の厳密な lifecycle を定義しています。

Initialization: capability negotiation と protocol version agreement
Operation: 通常の protocol communication
Shutdown: connection の graceful termination

sequenceDiagram participant Client participant Server Note over Client,Server: Initialization Phase activate Client Client->>+Server: initialize request Server-->>Client: initialize response Client--)Server: initialized notification Note over Client,Server: Operation Phase rect rgb(200, 220, 250) note over Client,Server: Normal protocol operations end Note over Client,Server: Shutdown Client--)-Server: Disconnect deactivate Server Note over Client,Server: Connection closed

Lifecycle Phases

Initialization

initialization phase は、client と server の最初のやり取りでなければなりません (MUST)。この phase の間に、client と server は次を行います。

protocol version compatibility を確立する
capability を交換し、negotiation する
implementation detail を共有する

client は、次を含む initialize request を送ることで、この phase を開始しなければなりません (MUST)。

サポートする protocol version
client capability
client implementation information

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "initialize",
  "params": {
    "protocolVersion": "2025-11-25",
    "capabilities": {
      "roots": {
        "listChanged": true
      },
      "sampling": {},
      "elicitation": {
        "form": {},
        "url": {}
      },
      "tasks": {
        "requests": {
          "elicitation": {
            "create": {}
          },
          "sampling": {
            "createMessage": {}
          }
        }
      }
    },
    "clientInfo": {
      "name": "ExampleClient",
      "title": "Example Client Display Name",
      "version": "1.0.0",
      "description": "An example MCP client application",
      "icons": [
        {
          "src": "https://example.com/icon.png",
          "mimeType": "image/png",
          "sizes": ["48x48"]
        }
      ],
      "websiteUrl": "https://example.com"
    }
  }
}

server は、自身の capability と information を返答しなければなりません (MUST)。

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "protocolVersion": "2025-11-25",
    "capabilities": {
      "logging": {},
      "prompts": {
        "listChanged": true
      },
      "resources": {
        "subscribe": true,
        "listChanged": true
      },
      "tools": {
        "listChanged": true
      },
      "tasks": {
        "list": {},
        "cancel": {},
        "requests": {
          "tools": {
            "call": {}
          }
        }
      }
    },
    "serverInfo": {
      "name": "ExampleServer",
      "title": "Example Server Display Name",
      "version": "1.0.0",
      "description": "An example MCP server providing tools and resources",
      "icons": [
        {
          "src": "https://example.com/server-icon.svg",
          "mimeType": "image/svg+xml",
          "sizes": ["any"]
        }
      ],
      "websiteUrl": "https://example.com/server"
    },
    "instructions": "Optional instructions for the client"
  }
}

初期化が成功した後、client は通常の operation を開始する準備ができたことを示すために、initialized notification を送らなければなりません (MUST)。

{
  "jsonrpc": "2.0",
  "method": "notifications/initialized"
}

client は、server が initialize request に応答する前に、ping 以外の request を送るべきではありません (SHOULD NOT)。
server は、initialized notification を受信する前に、ping と logging 以外の request を送るべきではありません (SHOULD NOT)。

Version Negotiation

initialize request において、client は自分がサポートする protocol version を送らなければなりません (MUST)。これは、client がサポートする latest version であるべきです (SHOULD)。

server が request された protocol version をサポートしている場合、同じ version を返さなければなりません (MUST)。そうでない場合、server は自分がサポートする別の protocol version を返さなければなりません (MUST)。これは、server がサポートする latest version であるべきです (SHOULD)。

client が server の response に含まれる version をサポートしていない場合、disconnect するべきです (SHOULD)。

Note: HTTP を使用する場合、client は以後のすべての request に MCP-Protocol-Version: <protocol-version> HTTP header を含めなければなりません (MUST)。詳細は Transports の Protocol Version Header section を参照してください。

Capability Negotiation

client と server の capability は、session 中にどの optional protocol feature が利用可能になるかを定めます。

主な capability は次のとおりです。

Category	Capability	Description
Client	`roots`	filesystem roots を提供する能力
Client	`sampling`	LLM sampling request の support
Client	`elicitation`	server elicitation request の support
Client	`tasks`	task-augmented client request の support
Client	`experimental`	非標準の experimental feature の support を記述
Server	`prompts`	prompt template を提供
Server	`resources`	読み取り可能な resource を提供
Server	`tools`	呼び出し可能な tool を公開
Server	`logging`	structured な log message を出力
Server	`completions`	argument autocompletion をサポート
Server	`tasks`	task-augmented server request の support
Server	`experimental`	非標準の experimental feature の support を記述

capability object は、次のような sub-capability を表現できます。

listChanged: list change notification の support（prompts、resources、tools 向け）
subscribe: 個別 item の change に subscribe する support（resources のみ）

Operation

operation phase では、client と server は negotiation 済みの capability に従って message を交換します。

両者は次を守らなければなりません (MUST)。

negotiation 済みの protocol version を尊重する
正常に negotiation された capability のみを使用する

Shutdown

shutdown phase では、片側（通常は client）が protocol connection を clean に terminate します。特別な shutdown message は定義されていません。代わりに、underlying transport mechanism を使って connection termination を通知します。

stdio

stdio transport では、client は次の手順で shutdown を開始するべきです (SHOULD)。

まず、child process（server）への input stream を閉じる
server が終了するのを待つ。終了しない場合は、妥当な時間内に SIGTERM を送る
SIGTERM 後も妥当な時間内に終了しない場合は、SIGKILL を送る

server は、自身の output stream を client に対して閉じて終了することで shutdown を開始してもよいです (MAY)。

HTTP

HTTP transport では、関連する HTTP connection を閉じることで shutdown が示されます。

Timeouts

implementation は、hung connection と resource exhaustion を防ぐため、送信したすべての request に timeout を設定するべきです (SHOULD)。timeout 期間内に success または error response を受信しなかった場合、送信側はその request に対する cancellation notification を送るべきであり (SHOULD)、その response を待つのをやめるべきです。

SDK やその他の middleware は、これらの timeout を request ごとに設定できるようにするべきです (SHOULD)。

implementation は、対応する request に対する progress notification を受信したとき、timeout clock をリセットしてもよいです (MAY)。これは、実際に作業が進んでいることを示唆するためです。ただし、進捗通知の有無にかかわらず、misbehaving client または server の影響を制限するため、常に maximum timeout を強制するべきです (SHOULD)。

Error Handling

implementation は、次の error case に対処できるよう準備しておくべきです (SHOULD)。

protocol version mismatch
必須 capability の negotiation 失敗
request timeout

初期化 error の例:

{
  "jsonrpc": "2.0",
  "id": 1,
  "error": {
    "code": -32602,
    "message": "Unsupported protocol version",
    "data": {
      "supported": ["2024-11-05"],
      "requested": "1.0.0"
    }
  }
}