René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"[notes] Agents WG Meeting, October 28th, 2025","articleBody":"# Agents WG Meeting Notes\n\n**Date:** October 28, 2025\n\n## Attendees\n\n- Luca Chang\n- Che Liu\n- John Harris\n- Jonathan Hefner\n- Peder Holdgaard Pedersen\n- Peter Alexander\n- Shaun Smith\n\n## Discussion\n\nThe working group reviewed [SEP-1686: Tasks](https://github.com/modelcontextprotocol/modelcontextprotocol/issues/1686), which supersedes the earlier [SEP-1391: Long-Running Operations](https://github.com/modelcontextprotocol/modelcontextprotocol/issues/1391) proposal. The new approach focuses on data-layer concerns and avoids changing tool call semantics, instead relying on notification-based patterns for progress updates.\n\n### Server-to-Client Task State Management\n\nThe proposal allows servers to request task augmentation from clients, raising questions about distributed state management. While clients are typically not distributed, some implementations may be. This creates implementation complexity around whether the host application or the MCP client should own the task store.\n\nIn the reference implementation, the client needs to expose an extension point for task storage, but only the host application can actually fulfill that requirement, separating their responsibilities.\n\n### Task-Augmentation Opt-In Mechanism\n\nA key concern is whether clients should expect any operation (like `tasks/list`) to potentially take minutes or hours when task-augmented. MCP requests can already be slow, and the SEP does not change this. However, the SEP clarifies that receivers choose whether to accept task augmentation for specific requests, allowing servers to refuse task augmentation on requests that it expects will be quick.\n\nHowever, this design raises a discoverability problem: clients need a way to know which requests support task augmentation, or else the expectation must be that they attempt to augment every request with a task. The group discussed using either capabilities or tool annotations to signal this support, and left it up to the SEP to clarify.\n\n### ListTasks Security and Consistency\n\nThe `tasks/list` operation needs filtering capabilities for security reasons, as clients should not see tasks from other contexts. The group agreed on a consistency requirement: if a client can call `tasks/get` to retrieve a specific task, that task must appear in `tasks/list` results for that client.\n\nThere was also discussion about bidirectional symmetry—whether it makes sense for servers to call `tasks/list` on a client. This would only be relevant if the client supports server-to-client task augmentation and would require explicit configuration, but it should be allowed under those circumstances.\n\n### Relationship to TrackElicitation\n\nThe group noted potential overlap with [SEP-1036: URL Mode Elicitation](https://github.com/modelcontextprotocol/modelcontextprotocol/issues/1036), which introduces an `elicitation/track` method carrying a progress token. While `elicitation/track` and Tasks serve different purposes, they may be redundant in some scenarios. The group recommended coordinating with the proposers of #1036 to clarify the relationship.\n\n### Implementation Patterns and SDK Concerns\n\nThe proposed `beginX` pattern (e.g., `beginCallTool` returning a `PendingRequest`) needs validation with SDK maintainers across different languages. In C#, \"Task\" already has a well-established meaning in the standard library, which will require awkward naming like `McpTask` to avoid confusion.\n\n### Idempotency and Client-Generated IDs\n\nThe group debated whether idempotency should be tightly coupled to tasks. The original rationale was twofold:\n\n1. Tasks are generally long-running and expensive, making idempotency important for retry scenarios\n2. Client-provided task IDs enable future subtask association features, allowing servers to pre-allocate IDs for follow-up operations\n\nClient-generated IDs provide valuable message association benefits, particularly for future subtask extensions. However, this comes at a complexity cost for servers that simply want to expose existing workflow APIs.\n\nMore broadly, the group observed that request association and idempotency are useful features independent of the full task lifecycle. Requiring implementers to adopt the complete task model to get these benefits may be unnecessarily restrictive.\n\n### Reference Implementation Evolution\n\nThe [Python reference implementation](https://github.com/modelcontextprotocol/python-sdk/pull/1398) from #1391 became complex after incorporating feedback, particularly around the task broker API. For a v0 implementation, a simpler approach seemed more appropriate, leading to the current [TypeScript reference implementation](https://github.com/modelcontextprotocol/typescript-sdk/pull/1041).\n\nThe core client changes (excluding server-to-client task augmentation) primarily involve splitting RPC methods into `beginX` variants that return `PendingRequest` objects. This simplified scope makes it feasible to create a streamlined Python implementation for real-world testing with the HuggingFace Jobs API (see **Follow-ups**).\n\n## Follow-ups\n\n**Integration and Testing:**\n- @lucalc will collaborate with @evalstate on integrating with the HuggingFace Jobs API to validate the design's usability in practice\n- @pwwpche will reach out to @ihrpr about engaging other SDK and client developers on the `beginX` method splitting pattern\n\n**Specification Updates:**\n- **DONE** Add a consistency requirement that any task retrievable via `tasks/get` must appear in `tasks/list` for that client\n- **DONE** Define a mechanism (capabilities or annotations) to signal which operations support task augmentation, avoiding unnecessary augmentation attempts\n  - **DONE** Using *both* capabilities and tool annotations to signpost this\n- **PENDING** Reconsider the coupling between idempotency and tasks—at minimum, make idempotency a **MAY** requirement rather than a **MUST**. Ideally, extract generally useful concepts (idempotency, message association) into separate features that don't require full task support\n  - **DONE** Task idempotency is no longer required","author":{"url":"https://github.com/LucaButBoring","@type":"Person","name":"LucaButBoring"},"datePublished":"2025-10-28T22:46:51.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":0},"url":"https://github.com/1726/modelcontextprotocol/issues/1726"}