modelcontextprotocol/transports-wg
Watch
1
0
Fork
You've already forked transports-wg
 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Writeup of design question for 2322-MRTR (#24)

Browse source 
This is a write up of a design discussion on SEP 2322-MRTR and design decision

Should requests for more information (i.e. the IncompleteResult
response) be supported as a response type on to all ClientRequests, or
should it be limited to a subset of Client Requests?
This commit is contained in:
Caitie McCaffrey 2026-03-19 14:38:23 -07:00 • committed by GitHub
commit 7716a238a6
No known key found for this signature in database
GPG key ID: B5690EEEBB952194
1 changed files with 85 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

85
proposals/MRTR-implementation-question.md Normal file
View file

@ -0,0 +1,85 @@
# 2322-MRTR Design Question Overview
This document provides an design decision that has come up as part of implementing [SEP 2322-MRTR](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2322) that the Transport-WG is split on.
## Question
Should requests for more information (i.e. the `IncompleteResult` response) be supported as a response type on to all ClientRequests, or should it be limited to a subset of Client Requests?
## Background
In the current protocol version `2025-11-25` and inclusive of the draft version with [SEP-2260](https://modelcontextprotocol.io/seps/2260-Require-Server-requests-to-be-associated-with-Client-requests) servers can send a `elicitation/create`, `sampling/createMessage`, or `roots/list` request in response to any `ClientRequest`.
In MRTR this behavior is changing to have Servers send `IncompleteResult` responses to `ClientRequest`s in order to request more information. One point of discussion is should we restrict the use of the `IncompleteResult` response to a subset of `ClientRequest`s or should we support it as a response for all `ClientRequest`s.
## Option 1: Arguments for supporting `IncompleteResult` on all `ClientRequest`s
- Backwards compatibility with the current protocol version is preserved.
- It is simpler to implement in the Schema, one learning from Tasks is many edge cases were introduced by only supporting specific Requests & Responses.
- Does not constraing future MCP Server implementors in how they can use `IncompleteResult` responses to request more information from the Client. We may not be able to come up with a good example today of why you would use it for a certain method but does not mean there is not a valid one.
- The edge case of an MCP Server sending an `IncompleteResult` response to a `ClientRequest` that the host does not expect or want to support has minimal impact. The Client can just choose to ignore the request. This is functionaly equivalent to a user refusing to provide the input ot elicitation request.
- Conforms to [MCP Design Principles](https://modelcontextprotocol.io/community/design-principles) of Composability by providing common building blocks vs the speficicity of only supporting it for a subset of Requests & Responses.
- All new `ClientRequest`s added in the future would need to be evaluated for whether they should support `IncompleteResult` responses, which adds cognitive overhead to future design and implementation.
### Schema Changes Required
Below highlights the ClientRequest schema changes required to support MRTR
```typescript
/**
* Common params for any request.
*
* @category Common Types
*/
export interface RequestParams {
_meta?: RequestMetaObject;
inputResponses?: InputResponses;
/* Request state passed back to the server from the client.
*/
requestState?: string;
}
```
## Option 2: Arguments for supporting `IncompleteResult` on a subset of `ClientRequest`s
- `Tasks` is only supported on a subset of Requests & Responses.
- There are many `ClientRequest`s that don't have clear use cases where a Server would need to request more information from the Client. Examples include:
- `PingRequest`
- `GetTaskRequest`
- `CancelTaskRequest`
- `SubscribeRequest`
- `UnsubscribeRequest`
- Be explicit to client implementors on when they need to support `IncompleteResult` responses, and handle surfacing requests for more information in the UI.
- This is a breaking change, but we are already making a breaking change in MRTR. We do not have data on what MCP Servers due today in this regard, assumed to be low.
- Hosts may not anticipate supporting gathering additional information on all responses, and this could lead to a worse user experience if they do not support it for all Requests & Responses.
### Schema Changes Required
Below highlights the ClientRequest schema changes required to support MRTR. This is the same pattern that Tasks support with `TaskAugmentedRequestParams`
```typescript
export interface RetryAugmentedRequestParams extends RequestParams {
/* New field to carry the responses for the server's requests from the
* IncompleteResult message. For each key in the response's inputRequests
* field, the same key must appear here with the associated response.
*/
inputResponses?: InputResponses;
/* Request state passed back to the server from the client.
*/
requestState?: string;
}
// must then be added to RequestParams for specific ClientRequests like below.
export interface GetPromptRequestParams extends RetryAugmentedRequestParams {
/**
* The name of the prompt or prompt template.
*/
name: string;
/**
* Arguments to use for templating the prompt.
*/
arguments?: { [key: string]: string };
}
```
### Decision
Based on feedback from DSP & the Core Maintainers we will go with Option 2 and only support `IncompleteResult` responses for a subset of `ClientRequest`s. A table of which Requests we will support it for will be added to the SEP-2322.
The main reasons cited were
- Easier to add more broadly later.
- Matches how `Tasks` are currently supported.