methods & request/response shapes

5 notes, read out of this brain and free to use. Each one was extracted from a source and is re-checked against its exam.

subscriptions/listen method: request shape with notifications filter

The subscriptions/listen request is a JSON-RPC 2.0 request with method "subscriptions/listen" and id. The params object contains: _meta with io.modelcontextprotocol/protocolVersion, io.modelcontextprotocol/clientInfo (name and version), and io.modelcontextprotocol/clientCapabilities; and a notifications object with optional fields toolsListChanged (boolean), promptsListChanged (boolean), resourcesListChanged (boolean), and resourceSubscriptions (string array of resource URIs). All notification filter fields are optional. Omitting a field is equivalent to not subscribing to that notification type.

notifications/subscriptions/acknowledged response shape

The server sends notifications/subscriptions/acknowledged with jsonrpc "2.0", method "notifications/subscriptions/acknowledged", and params containing _meta with io.modelcontextprotocol/subscriptionId (the JSON-RPC id of the subscriptions/listen request), and a notifications object reflecting the subset of notification types the server agreed to honor.

Graceful subscription closure response shape

When the server ends a subscription on its own initiative, it SHOULD respond to the original subscriptions/listen request with a completion result. The response is JSON-RPC 2.0 format with id matching the subscriptions/listen request id, and result object containing resultType "complete" and _meta with io.modelcontextprotocol/subscriptionId matching the JSON-RPC id. The result carries no method-specific data beyond standard result fields and subscription metadata.

roots/list, sampling/createMessage, elicitation/create MUST be associated with client request

roots/list, sampling/createMessage, and elicitation/create requests MUST be associated with an originating client-to-server request (such as during tools/call, resources/read, or prompts/get processing). Standalone server-initiated requests of these types outside notifications MUST NOT be implemented. Although not enforced in the current MCP Data Layer, logically these requests MUST be associated with a valid client-to-server JSON-RPC Request Id.

Proposed request payload structure: CallToolRequestParams example

Request parameters should be defined as standalone named schemas extending RequestParams. For example, CallToolRequestParams extends RequestParams with fields: name (string, required) and arguments (object with string keys and unknown values, optional). The RPC method definition then references this as params: CallToolRequestParams.

Give your agent this brain