4.2 KiB
2025-11-18 Agents WG
Originally published as https://github.com/modelcontextprotocol/modelcontextprotocol/discussions/1836
Date: November 18, 2025 Attendees: Luca Chang, Che Liu, Felix Weinberger, Mike Kistler, Max Isbey, Peter Alexander, Rajesh Kamisetty
Discussion
SEP-1686: Tasks
The Agents Working Group discussed the last-minute revisions to SEP-1686 from the previous week. The proposal has been merged, with only minor corrections as follow-ups.
On taskHint
It was noted that the name "taskHint" is misleading, as tool annotations traditionally only represent non-functional aspects of a tool, whereas taskHint actually implies guarantees about the tool behavior that affect how the client has to handle it. The group discussed renaming it to something like executionMode, and potentially moving it out of ToolAnnotations in the future.
It was also noted that taskHint: "optional" is ambiguous from a client perspective, as it doesn't imply deterministic behavior for e.g. client SDKs. It is intended to mean that a client SDK that is aware of tasks should always use them unless it has a reason not to, but it also allows non-task-aware clients to continue to call these tools.
The group recommended clarifying this in the specification.
On the input_required status
Concerns were raised about the stipulation that clients call tasks/result for a long-running SSE stream after encountering the input_required status, and that the tasks/result stream pattern seems to always be undesirable compared to the tasks/get stream pattern. Instead of having this requirement, tasks/get could simply only return an application/json response if there are no pending messages.
The reason for this specification requirement was to encourage implementations using Streamable HTTP to avoid SSE streams where possible, particular to avoid cases where servers always open an SSE stream on tasks/get, even if there are no pending messages. This is a cross-cutting concern for all request types, but is of particular interest in tasks, where a common motivation for using them is to avoid the need for streams (it is worth noting this was not an explicit goal of the proposal, even if it is a practical consideration by developers building MCP servers).
However, it was also noted that this may create a race condition if a tasks/result stream is terminated by either the client or the server. If the task re-transitions back to input_required, the client has no way of seeing this without additional polling or resuming the result stream.
@LucaButBoring will discuss this with @000-000-000-000-000.
Planned follow-up SEPs
- Subtasks: Enables task nesting and provenance chains, which can also form a basis for multi-turn interactions. Noted as a future direction in #1686.
- Extension to webhooks: This was a common ask from stakeholders for being able to wake an agent when the task status changes. Likely ties into #992.
- Idempotency tokens: Task IDs were originally intended to be client-generated and idempotent, but both of these properties were eventually dropped. Idempotency should be reintroduced as a general-purpose property across all requests. This is the domain of the Transports WG.
- Message association: Task IDs are attached to all messages originating from a task for association purposes, but it has also been noted that this would be a useful feature to have across all requests. The task implementation and a future general-purpose implementation will be orthogonal and complementary. This is likely the domain of the Transports WG.
SSE early-termination:In a previous iteration of the proposal, it was noted that SSE stream behavior is ambiguous after the server terminates an SSE stream. This was planned as a follow-up SEP at the time, but is now resolved by #1699, which has been accepted for the upcoming specification release.
SEP-1792: Add agencyHint tool annotation
Due to time constraints, this was not yet formally introduced to the group (this will happen at the beginning of the next meeting in two weeks), but it was clarified that agencyHint is not intrinsically tied to tasks, as tasks will also be commonly used for tools that are not themselves backed by an agent.