Movatterモバイル変換

[0]ホーム
URL:

Skip to main content
Base Protocol

Lifecycle

Protocol Revision: draft
The Model Context Protocol (MCP) defines a rigorous lifecycle for client-serverconnections that ensures proper capability negotiation and state management.
  1. Initialization: Capability negotiation and protocol version agreement
  2. Operation: Normal protocol communication
  3. Shutdown: Graceful termination of the connection

Lifecycle Phases

Initialization

The initialization phaseMUST be the first interaction between client and server.During this phase, the client and server:
  • Establish protocol version compatibility
  • Exchange and negotiate capabilities
  • Share implementation details
The clientMUST initiate this phase by sending aninitialize request containing:
  • Protocol version supported
  • Client capabilities
  • Client implementation information
{  "jsonrpc":"2.0",  "id":1,  "method":"initialize",  "params": {    "protocolVersion":"2024-11-05",    "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"    }  }}
The serverMUST respond with its own capabilities and information:
{  "jsonrpc":"2.0",  "id":1,  "result": {    "protocolVersion":"2024-11-05",    "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"  }}
After successful initialization, the clientMUST send aninitialized notificationto indicate it is ready to begin normal operations:
{  "jsonrpc":"2.0",  "method":"notifications/initialized"}
  • The clientSHOULD NOT send requests other thanpings before the server has responded to theinitialize request.
  • The serverSHOULD NOT send requests other thanpings andlogging before receiving theinitializednotification.

Version Negotiation

In theinitialize request, the clientMUST send a protocol version it supports.ThisSHOULD be thelatest version supported by the client.If the server supports the requested protocol version, itMUST respond with the sameversion. Otherwise, the serverMUST respond with another protocol version itsupports. ThisSHOULD be thelatest version supported by the server.If the client does not support the version in the server’s response, itSHOULDdisconnect.
If using HTTP, the clientMUST include theMCP-Protocol-Version: <protocol-version> HTTP header on all subsequent requests to the MCPserver.For details, seethe Protocol Version Header section in Transports.

Capability Negotiation

Client and server capabilities establish which optional protocol features will beavailable during the session.Key capabilities include:
CategoryCapabilityDescription
ClientrootsAbility to provide filesystemroots
ClientsamplingSupport for LLMsampling requests
ClientelicitationSupport for serverelicitation requests
ClienttasksSupport fortask-augmented client requests
ClientexperimentalDescribes support for non-standard experimental features
ServerpromptsOffersprompt templates
ServerresourcesProvides readableresources
ServertoolsExposes callabletools
ServerloggingEmits structuredlog messages
ServercompletionsSupports argumentautocompletion
ServertasksSupport fortask-augmented server requests
ServerexperimentalDescribes support for non-standard experimental features
Capability objects can describe sub-capabilities like:
  • listChanged: Support for list change notifications (for prompts, resources, andtools)
  • subscribe: Support for subscribing to individual items’ changes (resources only)

Operation

During the operation phase, the client and server exchange messages according to thenegotiated capabilities.Both partiesMUST:
  • Respect the negotiated protocol version
  • Only use capabilities that were successfully negotiated

Shutdown

During the shutdown phase, one side (usually the client) cleanly terminates the protocolconnection. No specific shutdown messages are defined—instead, the underlying transportmechanism should be used to signal connection termination:

stdio

For the stdiotransport, the clientSHOULD initiateshutdown by:
  1. First, closing the input stream to the child process (the server)
  2. Waiting for the server to exit, or sendingSIGTERM if the server does not exitwithin a reasonable time
  3. SendingSIGKILL if the server does not exit within a reasonable time afterSIGTERM
The serverMAY initiate shutdown by closing its output stream to the client andexiting.

HTTP

For HTTPtransports, shutdown is indicated by closing theassociated HTTP connection(s).

Timeouts

ImplementationsSHOULD establish timeouts for all sent requests, to prevent hungconnections and resource exhaustion. When the request has not received a success or errorresponse within the timeout period, the senderSHOULD issue acancellationnotification for that request and stop waiting fora response.SDKs and other middlewareSHOULD allow these timeouts to be configured on aper-request basis.ImplementationsMAY choose to reset the timeout clock when receiving aprogressnotification corresponding to the request, as thisimplies that work is actually happening. However, implementationsSHOULD alwaysenforce a maximum timeout, regardless of progress notifications, to limit the impact of amisbehaving client or server.

Error Handling

ImplementationsSHOULD be prepared to handle these error cases:
  • Protocol version mismatch
  • Failure to negotiate required capabilities
  • Requesttimeouts
Example initialization error:
{  "jsonrpc":"2.0",  "id":1,  "error": {    "code":-32602,    "message":"Unsupported protocol version",    "data": {      "supported": ["2024-11-05"],      "requested":"1.0.0"    }  }}

Was this page helpful?

⌘I
[8]ページ先頭
©2009-2025 Movatter.jp