SEP-2557: Stabilizing Tasks by LucaButBoring · Pull Request #2557 · modelcontextprotocol/modelcontextprotocol

LucaButBoring · 2026-04-12T20:40:09Z

This proposal builds on tasks by introducing several simplifications to the original functionality to prepare the feature for stabilization, following implementation and usage feedback since the initial experimental release. In particular, this proposal allows tasks to be returned in response to non-task requests to remove unneeded stateful handshakes, and it collapses tasks/result into tasks/get, removing the error-prone interaction between the input_required task status and the tasks/result method. Additionally, following the acceptance of SEP-2260: Require Server requests to be associated with a Client request, we are removing client-hosted elicitation/sampling tasks, as they further complicate the transport-related interactions that SEP-2260 intends to simplify.

Motivation and Context

Tasks were introduced in an experimental state in the 2025-11-25 specification release, serving as an alternate execution mode for certain request types (tool calls, elicitation, and sampling) to enable polling for the result of a task-augmented operation.

As we move toward stabilizing tasks in the June specification release, there are a few challenges to resolve to make them easier to implement support for in both the host application and on the server:

Clients are expected to handle cross-request capability negotiation: Tasks expose method-level capabilities which declare if they’re supported at all (e.g. tasks.requests.tools.call signals that tools/call supports task-augmentation) while also having a tool-level execution.taskSupport to declare if a particular tool supports tasks, requiring an initial tools/list call to prime some state that controls if the client should use tasks or not. This is non-obvious behavior and forces clients to do an implicit state warmup.
input_required is a transition point into SSE side-channeling: In Streamable HTTP, tasks rely on some SSE stream being used to deliver elicitations and sampling, but cannot define which stream is used, instead requiring tasks/result to be called prematurely to have a consistent option to open a stream on, from the server’s perspective.
tasks/result is a blocking method: To enable being used as a vehicle for SSE side-channeling, tasks/result is not allowed to return until the entire operation is complete, complicating polling implementations for clients and making servers pay a heavier cost for using elicitation or sampling at all, and undermining the incentives for servers to use tasks in certain cases.

Furthermore, in #2322 (Multi Round-Trip Requests), we identified that we would need to make a breaking change to tasks/result for these changes anyways, but that redesigning the flow within #2322 would be a scope expansion that would derail MRTR discussion. Regardless, MRTR relies heavily on tasks as a solution for "persistent" requests that require server-side state, so these two proposals are somewhat interdependent.

To both improve the adoption of tasks and to reduce their upfront messaging overhead, this proposal simplifies their execution model by allowing peers to raise unsolicited tasks to each other and consolidating the polling lifecycle entirely into the tasks/get method.

How Has This Been Tested?

TBD

Breaking Changes

Several; described in detail in the proposal.

Types of changes

Bug fix (non-breaking change which fixes an issue)
New feature (non-breaking change which adds functionality)
Breaking change (fix or feature that would cause existing functionality to change)
Documentation update

Checklist

I have read the MCP Documentation
My code follows the repository's style guidelines
New and existing tests pass locally
I have added appropriate error handling
I have added or updated documentation as needed

Additional context

Supersedes #2229 and #2339.

AI Use Disclosure: The core SEP document was written entirely by me, but the actual specification and schema changes were written with Claude Code. The LLM-annotated diff validating the specification and schema changes against the SEP requirements is available here.

LucaButBoring · 2026-04-12T20:51:14Z

@CaitieM20 @markdroth @Randgalt moving discussion here

Updated low-level specification language is pending; the SEP document consolidates #2229 and #2339 with additional changes following @markdroth's feedback and discussion with @CaitieM20 a couple of days ago, and factors in the approval of #2260 which makes server-to-client task augmentations invalid (covered in the Rationale section).

Randgalt · 2026-04-13T06:30:00Z

Seeing as we're breaking things...

Would it be possible to add a requestState field to the Task like we now have in MRTR?

LucaButBoring · 2026-04-13T21:02:14Z

Seeing as we're breaking things...

Would it be possible to add a requestState field to the Task like we now have in MRTR?

Yes, I'll add this in the next round of revisions - once MRTR lands we can potentially even just share most of the same types for those fields.

…vior." This reverts commit 54946b8.

CaitieM20 · 2026-04-13T23:04:30Z

+   * The structure matches the result type of the original request.
+   * For example, a {@link CallToolRequest | tools/call} task would return the {@link CallToolResult} structure.
+   */
+  result?: JSONObject;


See my PR on your branch. What do you think about having the Task Schema remain unchanged as a metadata object, but we create a GetTaskResult object that act as an envelope for the Task, inputRequests, results & error?

Feels a bit cleaner to not glom all this stuff into the Task Metadata object since that is light weight and can be passed around or copied. As is could be represented as a struct.

Updated the SEP text (spec is next), I'm a bit uncertain on the name but I'm calling it DetailedTask for now, and both tasks/get and notifications/tasks/status will use it. Representing the type like so:

interface InputRequiredTask extends Task { status: "input_required"; /** * Field containing the InputRequests that specify the additional information needed from the client. Present * only when task status is `input_required` (see SEP-2322). */ inputRequests: InputRequests; } interface CompletedTask extends Task { status: "completed"; /** * The final result of the task. Present only when status is "completed". * The structure matches the result type of the original request. * For example, a {@link CallToolRequest | tools/call} task would return the {@link CallToolResult} structure. */ result: JSONObject; } interface FailedTask extends Task { status: "failed"; /** * The error that caused the task to fail. Present only when status is "failed". */ error: JSONObject; } type DetailedTask = Task | InputRequiredTask | CompletedTask | FailedTask;

That makes DetailedTask a discriminated union of a regular task and our special statuses with more data.

add diagrams, schemas, http headers, and specify Gettask Behavior.

pja-ant · 2026-04-14T08:34:46Z

+
+### `tasks/result`
+
+The removal of `tasks/result` is not backwards-compatible. At a protocol level, this is handled according to the protocol version. Under the `2025-11-25` protocol version, `tasks/result` **MUST** be supported if the `tasks` capability is advertised, but under subsequent protocol versions, requests **MUST** be rejected with a `-32601` (Method Not Found) error.


Throwing out a thought: since Tasks are experimental, how much do you think SDKs should attempt to retain backwards compatibility? Curious how much complexity it introduces on SDKs and wondering what the blast radius is.

FWIW in our server we won't don't currently support tasks given the lack of client support. We will add support for this version of tasks so backwards compatibility isn't an issue for us.

My initial take is 0 support for the previous task version as it was marked as experimental and not fully supported.

cc: @felixweinberger

Additional point of information: Go SDK doesn't support tasks at all yet. No problem from our side with introducing breaking changes to achieve a better API.

My 2cents is we said this was experimental so there should be no expected backwards compatibility here. I think we should be able to make a clean break. @halter73 can you weigh in here? I think this aligns with some brief discussions we also had.

cc: @Kehrlann @chemicL (this affects modelcontextprotocol/java-sdk#755)

- Removed `task` nesting on `GetTaskResult` - Clarified header handling in the context of SEP-2243 - Clarified error semantics for tool calls with isError: true

LucaButBoring · 2026-04-14T20:49:29Z

Added requestState to the SEP text, will update the spec/schema async

LucaButBoring · 2026-04-15T00:28:18Z

Updated spec/schema language to reflect latest SEP document updates; new annotated diff here.

Randgalt · 2026-04-15T08:46:05Z

+     * when the task is in `input_required` state.
+     */
+    inputResponses?: InputResponses;
+  };


This is missing requestState?: string;

Randgalt · 2026-04-15T08:48:58Z

+The `Task` schema defining the task metadata remains unchanged. However, we introduce new derived types that inline `result`/`error`/`inputRequests`, to be used by `tasks/get` and `notifications/tasks/status`. This allows us to avoid introducing redundant/bloated fields in `CreateTaskResult` and in `ListTasksResult`.
+
+```typescript
+interface InputRequiredTask extends Task {


on the initial tool call that returns a task there is no request state? My thoughts regarding requestState:

maybe it could be called taskState and put directly in the Task model'

currently, our server has to have a storage mechanism to keep track of the task's running state

all of a tasks state can be moved into the requestState/taskState mechanism and be managed by clients completely removing the need for server managed storage.

completely removing the need for server managed storage

I thought the whole point of Tasks was to introduce a persistence layer for long running calls? How do you handle a situation when a worker that is executing the call is killed? How do you handle task/get if the request lands at a different server than the one the worker is executing on?

Sorry, I didn't mean to imply there would be no server context. But, task specific state could be managed in this additional carrier.

Here's a real world example:

Our server might have a tool that initiates a long running query in Trino

When the tool is called we start the query

It would be nice if we could associate an object with the task. Something like:

{ "queryId": "XXXXX", "userId": "XXXXXX", ... etc. ... }

When tasks/get is called the MCP server can check with Trino directly to see if the query is complete and return the results when done

This way, the "task" that is operating has no need to know that it's part of an MCP call. Our MCP server can manage the independently operating process

Thanks, that's helpful to get a better understading.

LucaButBoring force-pushed the feat/tasks-stabilization branch from 4215bbd to 554c8bc Compare April 12, 2026 20:44

LucaButBoring requested review from a team as code owners April 12, 2026 20:44

LucaButBoring changed the title ~~SEP-0000: Stabilizing Tasks~~ SEP-2557: Stabilizing Tasks Apr 12, 2026

LucaButBoring force-pushed the feat/tasks-stabilization branch 2 times, most recently from 6c61b6e to c1aa24a Compare April 12, 2026 20:47

This was referenced Apr 12, 2026

SEP-2229: Unsolicited Tasks #2229

Closed

SEP-2339: Task Continuity #2339

Closed

LucaButBoring added this to the 2026-06-30-RC milestone Apr 13, 2026

LucaButBoring added 2 commits April 13, 2026 12:26

SEP-2557: Stabilizing Tasks

71df9fa

SEP-2557 spec language

6a4a14c

LucaButBoring force-pushed the feat/tasks-stabilization branch from 8b2d86d to 6a4a14c Compare April 13, 2026 19:26

SEP-2557 formatting fixes

40b56d0

CaitieM20 self-assigned this Apr 13, 2026

CaitieM20 added SEP draft SEP proposal with a sponsor. labels Apr 13, 2026

github-project-automation bot added this to SEP Review Pipeline Apr 13, 2026

Add CaitieM20 as sponsor for SEP-2557

9b82826

CaitieM20 added the rc-high-priority Related to an upcoming specification release and needs to be addressed with a high priority. label Apr 13, 2026

CaitieM20 removed the rc-high-priority Related to an upcoming specification release and needs to be addressed with a high priority. label Apr 13, 2026

CaitieM20 added 3 commits April 13, 2026 15:25

add diagrams, schemas, http headers, and specify GetTask Behavior.

54946b8

Revert "add diagrams, schemas, http headers, and specify GetTask Beha…

a858fa9

…vior." This reverts commit 54946b8.

add diagrams, schemas, http headers, and specify Gettask Behavior.

cb3f52c

CaitieM20 reviewed Apr 13, 2026

View reviewed changes

Merge pull request #1 from CaitieM20/tasks-stabilization-edits

614ec39

add diagrams, schemas, http headers, and specify Gettask Behavior.

pja-ant reviewed Apr 14, 2026

View reviewed changes

LucaButBoring added 3 commits April 14, 2026 12:40

SEP-2557 formatting fixes

c4f683f

SEP-2557 formatting fixes

dbe7029

SEP-2557 revisions

f142a59

- Removed `task` nesting on `GetTaskResult` - Clarified header handling in the context of SEP-2243 - Clarified error semantics for tool calls with isError: true

CaitieM20 mentioned this pull request Apr 14, 2026

SEP-2322: Multi Round-Trip Requests #2322

Open

9 tasks

SEP-2557 spec/schema updates for latest SEP revision rounds

d7c6d4f

Randgalt reviewed Apr 15, 2026

View reviewed changes

dsp-ant added the roadmap/agents Roadmap: Agent Communication (Tasks lifecycle) label Apr 15, 2026


		### `tasks/result`

		The removal of `tasks/result` is not backwards-compatible. At a protocol level, this is handled according to the protocol version. Under the `2025-11-25` protocol version, `tasks/result` MUST be supported if the `tasks` capability is advertised, but under subsequent protocol versions, requests MUST be rejected with a `-32601` (Method Not Found) error.

Conversation

LucaButBoring commented Apr 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Motivation and Context

How Has This Been Tested?

Breaking Changes

Types of changes

Checklist

Additional context

Uh oh!

LucaButBoring commented Apr 12, 2026

Uh oh!

Randgalt commented Apr 13, 2026

Uh oh!

LucaButBoring commented Apr 13, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

LucaButBoring commented Apr 14, 2026

Uh oh!

LucaButBoring commented Apr 15, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

7 participants

LucaButBoring commented Apr 12, 2026 •

edited

Loading