Sep mrtr by CaitieM20 · Pull Request #1 · CaitieM20/modelcontextprotocol

CaitieM20 · 2026-02-26T21:26:22Z

Creating a Pull Request here to allow collaborators to comment before we create the PR on the MCP repo.

…emove garbage file

…uestParams — now available on any client-initiated request, not just tool calls 2. Added typed InputResponse = ElicitResult | CreateMessageResult — InputResponses values are now properly typed instead of { result: { [key: string]: unknown } } 3. Updated examples — removed the extra result wrapper from TaskInputResponseRequest and TaskInputResponseRequestParams examples to match the new typed schema All checks pass: ✅ TypeScript compiles, ✅ JSON schema up to date, ✅ 140/140 examples valid. Caitie Note: Need to take a look at task-input-response-params.json looks wrong on cursory inspection.

…ngInputRequest → SamplingCreateRequest.

…itRequets these should only be sent as part of IncompleteResponse Objects now

…a JSONRPCIncompleteResultResponse and add examples

…pper in the SEP because InputRequests maps keys directly to the requests so the InputResponses now follows that pattern and there is no benefit to the added wrapper. The only argument for the wrapper would be if we wanted to carry error's alongside results but we do not in these cases. If there is an error the client would retry until the necessary information was retrieved and then send back to the server.

…ut content ordering changes

schema/draft/schema.ts

schema/draft/examples/IncompleteResult/incomplete-result-with-request-state-only.json

gjz22 · 2026-02-27T02:09:56Z

schema/draft/examples/IncompleteResult/incomplete-result-with-elicitation-and-sampling.json

@@ -0,0 +1,35 @@
+{


What about calling this result InputRequiredResult to match the semantics of the internals?

seps/XXXX-MRTR.md

schema/draft/examples/ElicitRequest/elicitation-request.json

schema/draft/examples/ElicitResultResponse/elicitation-result-response.json

markdroth

Just replying to a few comments that are about the original draft of this SEP, before Catie's changes.

schema/draft/schema.ts

seps/XXXX-MRTR.md

Distill `search-mcp-github` skill

MRTR schema changes

… due to inheritance bug

CaitieM20 · 2026-02-28T05:17:53Z

@markdroth I merged in your schema changes which added RetryAugmentedRequestParams vs just adding the optional fields to the RequestParams object, which matches what's in the SEP of having this available on ever request.

Now there are some inheritance issues in the schema we still need to work out with your change:

PaginatedRequestParams does NOT extend RetryAugmentedRequestParams — The SEP says MRTR applies to "any
client-initiated request," and the schema adds | IncompleteResult to list result responses. But
ListResourcesRequest, ListToolsRequest, ListPromptsRequest, etc. use PaginatedRequestParams which extends plain
RequestParams — not RetryAugmentedRequestParams. So while servers can return IncompleteResult on list responses,
clients have no way to send back inputResponses/requestState on retry for list requests since those params aren't in
the schema for paginated requests.
[Fixed] CreateMessageRequestParams and ElicitRequestFormParams/ElicitRequestURLParams extend TaskAugmentedRequestParams which inherits RetryAugmentedRequestParams because of this they could theoretically carry their own nested inputResponses/requestState/task fields - this is also an issue with my earlier implementation of having it on RequestParams as well, we'll need to take a closer look here. -- Removed inheritance from TaskAugmentedRequestParams since these are not ServerRequest objects anymore.

Additionally, we wrote the SEP saying IncompleteResult could be sent back on any ServerResult, however as is we only send it back on some of them, so we'll need to fix that as well. Currently the following ServerResults do not support returning an IncompleteResponse.

EmptyResult
InitializeResult
CompleteResult
CreateTaskResult
GetTaskResult
ListTasksResult
CancelTaskResult

…e no longer Requests in the MCP Request/Response sense

…xtprotocol#2321) * Update roadmap to reflect 2026 core maintainer priorities Replaces the release-oriented roadmap with a strategic, WG-oriented document reflecting the consensus of core maintainer priority votes. Priority order (Borda count across 6 ranked votes): 1. Transport Evolution & Scalability (unanimous, 4x #1) 2. Agent Communication (incl. partial/streamed results) 3. Governance Maturation 4. Triggers & Event-Driven Client Updates Also adds: - SEP Prioritization guidance: aligned SEPs get expedited review - On the Horizon section for Security, Enterprise, and Extensions — areas with real interest where we'll support community-driven WGs but won't actively stand them up this cycle - Updated Validation and Get Involved sections oriented around WG/IG participation * Tighten roadmap prose and separate result types from agent work Writing fixes: - Collapse redundant goal/deliverable splits where WG focus just restated the goals (Agent Comm, Governance) - De-scaffold Triggers to prose; it was too thin for bullet structure - Convert single-item lists to sentences - De-overlap Transport bullets 1 and 2 (stateless vs session lifecycle) - Cut On the Horizon intro from 60 words to 30 - Give Enterprise and Extensions bullets verbs instead of noun-lists - Remove hedges and clichés already covered by the top-level disclaimer Conceptual fix: - Separate Result Type Improvements (streaming, large responses) from Agent Communication. These are constraints on result types regardless of whether the operation is agentic. Moved to On the Horizon since only one maintainer explicitly ranked it. - Agent Communication now scoped to Tasks lifecycle only: retry, cancellation, expiry, error reporting. * Update docs/development/roadmap.mdx Co-authored-by: Kurtis Van Gent <31518063+kurtisvg@users.noreply.github.com> * Swap Enterprise and Triggers to match vote breadth Enterprise scored 8 pts across 5/6 voters; Triggers scored 7 pts across 3/6 voters. The previous ordering favored intensity-when-present over breadth-of-support, but the Borda count and voter coverage both point the other way. Enterprise section is framed honestly as earlier-stage: problem definition rather than solution delivery, with most output expected to land as extensions. Also dropped the stale "trigger mechanisms" reference from Validation. * minor updates * update time * Drop unsubstantiated Task lifecycle gaps per review Luca correctly flagged that: - Cancellation "guarantees" are already answered by the spec: servers MAY ignore cancellation, it's best-effort by design. The bullet was re-asking a closed question. - Error reporting beyond status + statusMessage has no cited demand. Keeping only Retry and Expiry, which have concrete open questions. Added a sentence directing the Agents WG to surface additional gaps from production rather than speculating here. --------- Co-authored-by: Den Delimarsky <hi@den.dev> Co-authored-by: Kurtis Van Gent <31518063+kurtisvg@users.noreply.github.com>

@main

The slash-commands branch in modelcontextprotocol/actions was deleted after PR #1 merged. Point at @main where the action now lives. :house: Remote-Dev: homespace

CaitieM20 added 15 commits February 20, 2026 10:36

add SEP doc from transport-wg

b4f29a6

copilot initial pass, still WIP and under my review

a1b65dc

Merge branch 'modelcontextprotocol:main' into SEP-MRTR

12d910c

hand edits

21b4481

add Incomplete Result to server result, add sections to schema.mdx, r…

df843c7

…emove garbage file

renamed ElicitationInputRequest → ElicitationCreateRequest and Sampli…

7519d64

…ngInputRequest → SamplingCreateRequest.

removing standalone ServerRequests for CreateMessageRequests and Elic…

8b66f20

…itRequets these should only be sent as part of IncompleteResponse Objects now

update examples

ca03c4e

moving JSONRPCIncompleteResultResponse location in schema.ts

944a6a5

update GetTaskPayloadResultResponse to be a JSONRPCResultResponse or …

ac8b3e6

…a JSONRPCIncompleteResultResponse and add examples

remove URLElicitationRequiredError

053d9cb

updating SEP examples to adhere strictly to schema

9fd8dde

WIP on updating Spec to be more readable, added new spec V2 to test o…

c741ca4

…ut content ordering changes

markdroth reviewed Feb 26, 2026

View reviewed changes

schema/draft/schema.ts Outdated Show resolved Hide resolved

markdroth added 2 commits February 26, 2026 23:16

schema changes for ephemeral workflow

2d37d9d

schema changes for persistent workflow

08cffb1