2025-11-04 Agents WG

Originally published as https://github.com/modelcontextprotocol/modelcontextprotocol/discussions/1764

Date: November 4, 2025 Attendees: Luca Chang, Che Liu, Peter Alexander, Shaun Smith, Mike Kistler, Kryspin Ziemski

Discussion

This week's Agents WG meeting continued work on #1686, focusing on feedback integration and emerging implementation challenges as the proposal moves toward the 11/25 spec release.

Task Message Association and Scope Questions

The group discussed whether task message association via relatedTask metadata should remain in scope for the initial release. While there was some agreement that message association could be treated as a separate concern, removing this metadata has broader implications for real-world usage patterns. The most significant concern centered on the input_required status: without message association, there's no clear mechanism to signal which requests are blocking a task from advancing. The group will need to come to a decision on this scoping question before the next meeting.

Related to this discussion, the group noted that input_required is mentioned throughout the proposal but hasn't been formally added to the list of statuses in the data model, which needs to be corrected.

Task Acceptance: Notifications vs. Responses

The question of whether task acceptance should use notifications or responses surfaced again, tying back to the broader concerns around message association and task lifetime management which are documented as a design decision in the SEP. This will be discussed further following this meeting.

SDK Implementation Philosophy and Automatic Opt-in

Following the Core Maintainers meeting from the previous Wednesday, the group discussed approaches to task augmentation in the reference SDKs. The TypeScript and Python implementations will automatically opt in to task augmentation when available, treating this as an opportunity to bolster adoption by making the feature accessible by default.

However, it was noted that the C# SDK takes a different philosophical stance, avoiding automatic behavior in favor of explicit developer control. The group agreed this is an acceptable divergence, and other SDKs will likely establish their own positions on this question. The Java SDK, for instance, follows a similar philosophy to C#.

Connection Management and Server-Side Termination

The group discussed practical challenges around connection management in sHTTP, as it relates to tasks. In most cases, implementations will want to avoid keeping a connection open while polling for task completion, but current SDKs don't provide support for proactively terminating a connection from the server side after e.g. a configurable timeout. An early-termination response pattern would be ideal for this use case, but the group agreed this is better suited for a future SEP rather than expanding the current scope.

Related to this, several features being cut from SEP-1686 will be reintroduced as separate SEPs following the 11/25 release, as there isn't sufficient time to develop them in parallel with the core tasks proposal.

Technically, the current MCP specification does allow for resumable server-side termination of SSE streams, but no SDK currently implements this capability. Attempting to use MCP in this way often results in errors when trying to write messages to the broken response stream.

Session Binding and Identity Challenges

A significant implementation challenge surfaced around session binding for tasks. The current reference implementation only supports task identification via task ID, with no mechanism to bind tasks to sessions or restrict users to viewing only their own tasks. While this was initially an implementation oversight, it also reflects ongoing friction around how MCP handles sessions and identity.

The planned implementation adjustment involves passing the transport session ID into task store methods as an optional parameter. Once #1442 lands, this approach will support both sHTTP and STDIO transports, though the initial implementation will only support session binding for sHTTP.

The group also discussed why session binding needs to be optional. Session binding has to be optional because sessions themselves are optional in MCP (STDIO also does not support them). However, this creates confusion because sessions and identity are poorly defined at the application level. The transport notion of a session is separate from the application notion of a session, and this ambiguity creates challenges for implementers.

The group suggested working with the Transports WG on this, if we can benefit from application-level session semantics for tasks. In the meantime, the proposal should include a clear statement about what session binding means for tasks, providing implementation guidance even in the absence of formal application-level session definitions in MCP.

Follow-ups

DONE @LucaButBoring: Include input_required status in data models
DONE @LucaButBoring: Come to a decision on if task association metadata should be in scope
DONE @LucaButBoring: Clarify explicitly what session-binding looks like for tasks
DONE @LucaButBoring: Clarify explicitly what it means for a request to be "associated with a task"
DONE @LucaButBoring: Update reference implementations for latest SEP revisions
DONE @pwwpche / @LucaButBoring: Meet to discuss notifications vs. responses in more detail

5.5 KiB Raw Blame History