If we are going to keep requestState (which I still think we shouldn't), we need to spell out the semantics very clearly, and I don't see that we're describing them anywhere.

For example, what exactly is the lifetime of the request state from the client's perspective? Does the client always send the requestState back to the server on the next tasks/get request, but then drop it in favor of the requestState in the tasks/get response -- i.e., the client holds on to it only between two interactions, and the server needs to echo it back on each tasks/get response?

Alternatively, are we expecting that the client will hold on to the last seen requestState for the lifetime of the task, throwing it away only when the server provides a new value?

Are there ordering concerns here? What happens if the client makes two calls to tasks/get in parallel? Or do we expect that clients will never do that? Do we have some way to guarantee that?

I fear that this mechanism is adding more complexity than it may seem on the surface.

Are you aware that this same mechanism is in MRTR?

I'm one of the main authors of the MRTR SEP, so I assure you that I am aware of it. :)

If we are going to keep requestState (which I still think we shouldn't), we need to spell out the semantics very clearly, and I don't see that we're describing them anywhere.

It's mentioned in the spec language in this PR for the extended semantics for tasks, but I'm planning to lean on MRTR for the core of it. The current phrasing is:

Under Request State Management:

Servers MAY set an optional requestState string on any Task object to pass opaque routing or state information back to the client. When a client receives a Task with a requestState value, it MUST echo back the exact value of that field in the requestState field of subsequent tasks/get and tasks/cancel requests for the same task. The server can use this echoed value to recover routing context or session state without maintaining per-task server-side session data, enabling stateless, load-balanced deployments.
[...]
The requestState value is opaque to the client — clients MUST NOT inspect, parse, modify, or make assumptions about its contents. Servers MAY return a different requestState value on each tasks/get and tasks/cancel response; clients MUST always use the most recently received value in their next request. If no requestState is present in the server's response, the client MUST NOT include it in the next request. Servers that include requestState SHOULD encrypt it to protect confidentiality and integrity, and MUST validate any received requestState before acting on it.

Upon receiving a notifications/tasks/status notification for a task status update, clients MUST update their tracked requestState value with any value provided in the notification, as they would do with a standard response.

...and under Data Types > Task:

• requestState: Optional opaque string set by the server for stateless routing or state management. Clients MUST echo this value back exactly in subsequent tasks/get requests (see Request State Management).

(I forgot to add "and tasks/cancel" there; I will do that now)

What happens if the client makes two calls to tasks/get in parallel? Or do we expect that clients will never do that?

Last writer wins, and the server needs to reconcile that. Functionally, this should be no different from the non-parallel case where the client polls less frequently than the state is updating; eventually the server needs to handle the client's last-seen requestState potentially being out of sync with some upstream source of truth.

Ah, okay -- guess I didn't read carefully enough. Thanks!

After feedback from a few folks who would be implementing this I think we need to add a tasks/update or tasks/continue method.

This channel is where the client can send async messages to the server on. This is effectively a POST. So we should move Cancel Message & InputResponse messages here.

This ensures both sides of tasks, get & update are modeling truly async message passing. One of the problems currently is when InputResponses is provided on the get method the server either needs to process it before returning the status or might return something confusing like input_required again. this implies some kind of transaction semantics which aren't required and adds complexity.

This also has the nice benefit of tasks/get is idempotent, while tasks/update is not. So this more closely mimics REST GET & POST semantics.

Good catch. This is why Tasks are experimental.

I remember we were quite deliberate about the client creating the task in the past. Do you remember the reasoning @LucaButBoring ?

It was partially durability, and partially SDKs - it's hard to handle polymorphic results in many programming languages.

Regarding durability, there are other ways to handle that for task-augmented tool calls via tool arguments being used to bootstrap the task ID, and it was determined that layering a broader protocol-wide durability mechanism on top of that would be helpful, but out of scope for tasks themselves.

This makes sense and i generally agree. Notable there are two appraoches:

• The OS approach of poll()+accept(), which allows the polling to operate on multiple handlers, while accepting only one
• The busy-polling approach from the web, which combines getting + results at the expense that you cannot ignore a task result until you want to deliberately accept it, but you save roundtrips.

Busy polling is probably best here, since it avoids race condition, reduces roundtrips and avoid the server to have to cache the result for a long time.

complete and incomplete relate to tasks. Alternatively we can have two types:

type ResultType = "task" | "tool";

type TaskResultStatus = "incomplete" | "complete" | "created"

this way it's clear, and with a simple pattern match, the SDK can distinguish between complete tool results and complete task results.

I might be mistaken here, so correct me if you think the proposed result type is sufficient and clear enough.

These are two separate concepts - complete is used to identify complete non-task requests, incomplete is used to identify incomplete non-task requests (both come from SEP-2322), and we're extending that with task to specifically identify CreateTaskResult.

I do not like that.

Not all client want to support tasks. There are many situations where you only want to allow tools and nothing else, for example, because they dont want to support client side state. These should be free to not have to deal with tasks.

It also means that everyone upgrading to the new protocol MUST support tasks. That's a big ask.

We need to find a way for this to be an expressed capability of the client.

We can add back execution.taskSupport to allow task-returning tools to be filtered out of tools/list, but as long as task polling is transparent to applications by default (which I want to be the standard implementation path), there shouldn't be any additional burden regarding client state requirements. There are niche use cases where that cannot be the case, but I think the worst outcome is for task support to be optional, because that leads to the status quo where you need to have a state contract between the client and server to use tasks at all.

If at all possible, I think we should make it an invariant and only make it technically possible to opt out of, along the lines of stateless servers today (except in this case it would be stateless clients). The only use case I can see explicitly not being able to handle this is perhaps things like Claude/ChatGPT remote MCP execution, but even then that seems like a stretch. It's worth noting that whether or not polling happens is orthogonal from how long something takes, and we can have either 10-second or 10-hour non-task tool calls (setting aside the transport issues with this) just like we can have 10-second or 10-hour task-augmented tool calls.

Essentially, I want 90% of host applications to be able to call new task-returning tools without making any code changes themselves - and then we can add an escape hatch for the remaining 10%.

@LucaButBoring The problem with adding execution.taskSupport is that client that don't support it need to start supporting this. Existing clients that are not task aware would accidentally start calling tasks. I wonder if we can separate this out. For example, by adding a task/list or tools/list(tasks: true) (both seem to be not good ideas, but you get the idea).

Without Tasks being mandatory, it will be difficult to provide tools that leverage them until there is a point of critical adoption among clients. To cover the same user journeys we want to cover with tasks, we would potentially need to provide different sets of tools for different capabilities, which significantly complicates server side implementations.

It makes sense that we want people to support tasks, but we can't force anyone. If we make it mandatory, the very likely outcomes are either:

1. People won't adopt the new spec because they don't have bandwidth to add tasks support to their product, or
2. People will advertise the new spec version, but not actually implement tasks, maybe just stubbing out any client-side integration if using the SDKs.

Neither of these actually help server developers looking to leverage tasks.

I think it might be a different story if tasks were trivial to implement, but the fact that they are asynchronous makes them often non-trivial to integrate. It may even be practically impossible for some clients (e.g. a stateless endpoint backed by an agent that has to respond in seconds).

People won't adopt the new spec because they don't have bandwidth to add tasks support to their product

The point I've been pushing since the previous iteration of tasks which I don't think I've been able to get people to grasp is that client SDKs can (and should) encapsulate the polling by default. The default case should be that callTool just handles tasks under the hood, so the minimum bandwidth to add tasks is upgrading a dependency.

If applications then decide to have richer integrations with tasks (for example, background execution), they should be able to drop down a level of abstraction and leverage the lifecycle directly.

It may even be practically impossible for some clients (e.g. a stateless endpoint backed by an agent that has to respond in seconds).

duration is orthogonal to tasks

I agree with a couple of key points made above.

First, quoting @kurtisvg:

Without Tasks being mandatory, it will be difficult to provide tools that leverage them until there is a point of critical adoption among clients.

I think it's important to keep in mind that in our new stateless-by-default protocol, tasks is the mechanism to provide stateful functionality. If we don't make tasks a mandatory part of the protocol, then we're basically saying that server authors can't actually write stateful applications, because they have no guarantee that clients will support them.

In addition, I would argue that making tasks mandatory is consistent with one of the key principles that @dsp-ant articulated in our December meeting, which was to minimize the number of optional things in the protocol, since optional things themselves add complexity and fragment the ecosystem.

Next, quoting @LucaButBoring:

The point I've been pushing since the previous iteration of tasks which I don't think I've been able to get people to grasp is that client SDKs can (and should) encapsulate the polling by default. The default case should be that callTool just handles tasks under the hood, so the minimum bandwidth to add tasks is upgrading a dependency.

I think that's a really important point. It should be feasible for SDKs to handle the burden of supporting tasks, so individual clients and servers don't need to worry about it.

I think that if we do this right, making tasks mandatory will actually be much lower burden than making it optional.

I understand the why ,but i am unsure about this. what happens if clients crash, or loose track. How can they sync with the the source of truth (server). I can be convinced that this is okay for all the good reasons, but i a worry about this piece.

Host applications would have to handle this particular case, which they can do by listening on the CreateTaskResult for a task-augmented tool call and persisting the task ID, which they can then resume listening on upon resumption. It can be handled like #2567 treats session handles.

I don't think we should conflate task/get with inputResponses. Providing input and getting a status should be distinct things, otherwise task/get can't be idempotent, which can make things difficult for gateway implementors, etc to reason about. We should probably have these two:

1. task/get or task/poll for getting status and result. Idempotent.
2. task/continue or task/update for providing mutable changes to a task.

I forgot why we went with one header and I vaguely remember it was my idea, which in retrospective seems not so smart, since we are overloading the meaning of the header.

I wonder if we should have a separate MCP-Task-Id header. What do loadbalancers prefer here? @markdroth what do you think?

IIRC, the reason you suggested a single Mcp-Name header name was to avoid having to define a separate header name for each of tools, resources, and prompts -- i.e., the alternative would have been Mcp-Tool-Name for tools, Mcp-Resource-Name for resources, etc. (@kurtisvg can confirm my recollection here.)

If we have this established pattern where Mcp-Name basically indicates the object being accessed, independent of type (i.e., tool, resource, etc), then it seems reasonable to extend this same pattern to tasks. For a tool call, Mcp-Name indicates the name of the tool; for a resource read call, Mcp-Name indicates the name of the resource; and for a task call, Mcp-Name would indicate the name of the task.

IMO, I thought separate headers seemed better because it gives more flexibility, but I don't have a strong feeling or concrete use-case for it.

I do wonder that if tasks should have the original tool name in the header so it can be routed to the same place it was created from. But maybe that could be accomplished with putting tool name in the taskId some how.

I think putting the tool name in the task ID would work fine. And that case is probably a good argument for using the same header name, actually, since that will allow network data planes to always route based on the same header.

At the end of the day, we can make this work with either the same header or different headers. But I do feel that we should be consistent in how we do this across tools, resources, prompts, and tasks: if we use a separate header for tasks, then I think we should do so for the other features as well.

The DetailedTask is a task type property in the Task class? Why add more class definition instead status? what's the benefit here? since the client needs to seralized them to different task object.

DetailedTask is a subclass of Task, if you want to look at it that way

nit: It was never tied to sessions (which is good!). The current spec is around auth context.

Need to align with SEP-2549 but I'd really like this to be called ttlSeconds so that we completely remove the ambiguity. It also forces people to visit their code (which will be interpreting it as milliseconds right now, and would break on this change).

To be clear: we're keeping Tasks as experimental, but making it mandatory to implement for clients?

If so, I think this requires some justification since it feels very bad to mandate folks to implement and maintain an experimental feature with no choice.

I think it is worth discussing, I originally wanted this SEP to bring tasks out of experimental but that got walked back, and now puts this point on shaky ground.

The main reason I wanted this to involve bringing tasks out of an experimental state is to avoid a repeat of the last release, where SDK maintainers decide that experimental means forcing client applications to use entirely different API surfaces for servers that might return tasks - when the alternative would be making it transparent with hooks into the task lifecycle for deeper application integration with them.

That meant adopting tasks in any client application was a big lift, even if you just want to start by wrapping them in a blocking interface as a stepping stone.

Implementation reference: https://github.com/strands-agents/sdk-python/pull/1475/changes

If we're changing ttl to seconds we should change pollInterval to seconds also for consistency OR rename it to pollIntervalMs (and if we go for seconds, should be pollInternalSeconds).

Why would a server need to support tasks/cancel if it does not support tasks?

I was thinking that would imply that it needs a capability, and it would be silly to have a capability for cancellation that is disjoint from supporting tasks in general (which if at all possible I also want to remove all capabilities for).

In practice this is a non-issue because there are no valid task IDs to use with a server that never creates tasks, so every tasks/cancel request would fail.

This is a problem for unauthenticated servers (which tasks currently allow) since the task ID becomes the sole authz token and now we're saying that it is in a header, which gateways etc. will treat as non-sensitive.

If we're going to do this, I think we either need to just disallow tasks on unauth'd servers, or make it very clear that users should not have security expectations around access to the task.

Mcp-Task-Id may be preferrable since it has different cardinality to e.g. tool names and allows operators mask it independently.

I think it's fine to say that users should not store security-sensitive information in the task ID.

I think that any data plane that needs to do routing based on this can detect the task case by looking at the MCP method. We don't necessarily need a different header name to do that.

Does this need proper schema representation?

They're not really deprecated - they're removed.

"When clients request a task" - they're not really requesting one anymore, do they?

Receivers/requestors - can we use clients/servers terminology here?