SEP-2260: Require Server requests to be associated with a Client request.

​

Abstract

​

Motivation

​

Current Specification

• “The server MAY send JSON-RPC requests and notifications before sending the JSON-RPC response. These messages SHOULD relate to the originating client request.”

• “The server MAY send JSON-RPC requests and notifications on the stream.”
• “These messages SHOULD be unrelated to any concurrently-running JSON-RPC request from the client.”

​

Design Intent

• Sampling enables servers to request LLM assistance while processing a tool call, resource request, or prompt
• Elicitation enables servers to gather additional user input needed to complete an operation
• List Roots enables servers to identify shared storage locations

“Sampling in MCP allows servers to implement agentic behaviors, by enabling LLM calls to occur nested inside other MCP server features.”

​

Simplification Benefits

1. Simplifies transport implementations - Transports don’t need to support arbitrary server-initiated request/response flows, which require a persistent connection from Server to Client; they only need request-scoped bidirectional communication
2. Clarifies user experience - Users understand that sampling/elicitation happens because they initiated an action, not spontaneously
3. Reduces security surface - Ensures client has context for what scope the additional requested information will be used for. This allows clients to make better informed decisions on whether to provide the requested info.
4. Aligns with practice - Based on a scan of GitHub all existing implementations already follow this pattern, except one repo owned by the SEP author with a contrived scenario.

​

Specification Changes

​

1. Add Warning Blocks to Feature Documentation

<Warning>

**Request Association Requirement**

Servers **MUST** send `sampling/createMessage` requests only in association with an originating client request (e.g., during `tools/call`, `resources/read`, or `prompts/get` processing).

Standalone server-initiated sampling on independent communication streams (unrelated to any client request) is not supported and **MUST NOT** be implemented. Future transport implementations are not required to support this pattern.

</Warning>

<Warning>

**Request Association Requirement**

Servers **MUST** send server-to-client requests (such as `roots/list`,
`sampling/createMessage`, or `elicitation/create`) only in association with an
originating client request (e.g., during `tools/call`, `resources/read`, or
`prompts/get` processing).

Standalone server-initiated requests of these types on independent
communication streams (unrelated to any client request) are not supported and
**MUST NOT** be implemented. Future transport implementations are not required
to support this pattern.

</Warning>

<Warning>

Servers **MUST** send server-to-client requests (such as `roots/list`,
`sampling/createMessage`, or `elicitation/create`) only in association with an
originating client request (e.g., during `tools/call`, `resources/read`, or
`prompts/get` processing).

Standalone server-initiated requests of these types on independent
communication streams (unrelated to any client request) are not supported and
**MUST NOT** be implemented. Future transport implementations are not required
to support this pattern.

</Warning>

<Warning>

`ping` is an MCP-level liveness check and **MAY** be sent by either party at
any time on an established session/connection.

In Streamable HTTP, implementations **SHOULD** prefer transport-level SSE
keepalive mechanisms for idle-connection maintenance; `ping` remains available
for protocol-level responsiveness checks.

Request-association requirements for `roots/list`, `sampling/createMessage`,
and `elicitation/create` do not apply to `ping`.

</Warning>

​

2. Clarify Transport Layer Constraints

- The server **MAY** send JSON-RPC _requests_ and _notifications_ before sending the
- JSON-RPC _response_. These messages **SHOULD** relate to the originating client
- _request_.
+ The server **MAY** send JSON-RPC _requests_ and _notifications_ before sending the
+ JSON-RPC _response_. These messages **MUST** relate to the originating client
+ _request_.

- The server **MAY** send JSON-RPC _requests_ and _notifications_ on the stream.
- These messages **SHOULD** be unrelated to any concurrently-running JSON-RPC
- _request_ from the client.
+ The server **MAY** send JSON-RPC _notifications_ and _pings_ on the stream.
+ These messages **SHOULD** be unrelated to any concurrently-running JSON-RPC
+ _request_ from the client, **except** that `roots/list`,
+ `sampling/createMessage`, and `elicitation/create` requests **MUST NOT** be
+ sent on standalone streams.

​

Backward Compatibility

​

Impact Assessment

1. Common usage patterns are preserved - Sampling/elicitation within tool execution, resource reading, and prompt handling remain fully supported
2. No known implementations affected - Research conducted on GitHub has shown only one implementation of this pattern. This singular implementation is owned by the SEP author.

​

What’s Disallowed

# ❌ PROHIBITED: Standalone server push
async def background_task():
    while True:
        await asyncio.sleep(60)
        # Try to initiate sampling without any client request context
        await session.create_message(...)  # NOT ALLOWED

​

What Remains Supported

# ✅ SUPPORTED: Sampling during tool execution
@mcp.tool()
async def analyze_data(data: str, ctx: Context) -> str:
    # Request LLM analysis while processing the tool call
    result = await ctx.session.create_message(
        messages=[SamplingMessage(role="user", content=...)]
    )
    return result.content.text

​

Implementation Guidance

​

For Server Implementers

• Only uses server-to-client requests within tool handlers
• Only uses server-to-client requests within resource/prompt handlers
• Uses server-to-client requests synchronously as part of processing a client request

• Attempts to initiate server-to-client requests on standalone HTTP GET streams
• Attempts to send server-to-client requests requests independent of client operations
• Has background tasks that try to invoke server-to-client requests

​

Timeout Considerations

1. Transport timeouts (e.g. HTTP Request Timeout) are sufficient to accommodate “Human-in-the-loop” delays, which may be unbounded.
2. Short timeouts enforced by infrastructure (e.g. Load Balancers) may result in connection termination before the user responds. For Streamable HTTP, transport-level SSE keepalive mechanisms SHOULD be used to keep connections alive and reset timers; ping requests MAY additionally be used for protocol-level responsiveness checks.

​

For Client Implementers

​

For Transport Implementers

• Sampling/elicitation requests only occur within the scope of a client-initiated request
• Transports don’t need to support arbitrary server-initiated request/response flows on standalone channels
• Request correlation and lifecycle management is simplified

​

Timeline

​

Alternatives Considered

​

1. Soft Deprecation

​

2. Keep Current Ambiguity

​

3. Create a Capability Flag

​

References

• Current sampling documentation: /specification/draft/client/sampling.mdx
• Current elicitation documentation: /specification/draft/client/elicitation.mdx
• Transport specification: /specification/draft/basic/transports.mdx
• User interaction model discussion in client concepts documentation