Updates the 2025-11-25 and draft spec versions to clarify that servers SHOULD NOT advertise support for tasks/list if they do not have any form of context-binding.

Motivation and Context

This change explicitly states an implicit conclusion of the Tasks specification.

Specifically, the current specification strongly suggests binding Tasks to the authorization context that created them, and states that the recipient of a tasks/list request "MUST ensure the returned task list includes only tasks associated with the requestor's authorization context." It also states that if "context-binding is unavailable, receivers MUST generate cryptographically secure task IDs with enough entropy to prevent guessing". However, if the requestor identity can not be verified, tasks/list undermines any protections that a cryptographically-secure task ID would provide against guessing attacks, as the list cannot effectively be filtered. It follows that the only way to follow both stipulations is to reject tasks/list requests entirely if requestors cannot be identified.

This does not have any implications for existing implementations of the specification, so I'm raising this without an SEP associated with it. If this becomes a point of disagreement, I can remove the 2025-11-25 spec change and open a formal SEP for the June specification instead.

How Has This Been Tested?

N/A

Breaking Changes

None

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update

Checklist

• I have read the MCP Documentation
• My code follows the repository's style guidelines
• New and existing tests pass locally
• I have added appropriate error handling
• I have added or updated documentation as needed

Additional context

Fixes #2054.