42 lines
No EOL
4.2 KiB
Markdown
42 lines
No EOL
4.2 KiB
Markdown
# 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. |