Split McpTasksCapability into ServerMcpTasksCapability and ClientMcpTasksCapability#1529
Conversation
mikekistler
left a comment
There was a problem hiding this comment.
Looks good. 👍
Just a few minor documentation issues to fix.
| /// The tasks capability enables servers to augment their requests with tasks for long-running | ||
| /// operations. Tasks are durable state machines that carry information about the underlying | ||
| /// execution state of requests. |
There was a problem hiding this comment.
Tasks are not necessary for long-running operations.
| /// The tasks capability enables servers to augment their requests with tasks for long-running | |
| /// operations. Tasks are durable state machines that carry information about the underlying | |
| /// execution state of requests. | |
| /// The tasks capability enables servers to augment their requests with tasks to enable status | |
| /// monitoring and persistent result retreval. Tasks are durable state machines that carry | |
| /// information about the underlying execution state of requests. |
| /// The tasks capability enables clients to augment their requests with tasks for long-running | ||
| /// operations. When present, clients can request that certain operations (like tool calls) | ||
| /// execute asynchronously, with the ability to poll for status and retrieve results later. |
There was a problem hiding this comment.
Tasks are not necessary for long-running operations.
| /// execute asynchronously, with the ability to poll for status and retrieve results later. | |
| /// The tasks capability enables clients to augment their requests with tasks to enable status | |
| /// monitoring and persistent result retreval. When present, clients can request that certain | |
| /// operations (like tool calls) support the ability to poll for status and retrieve results later. |
| /// The tasks capability enables clients to augment their requests with tasks for long-running | ||
| /// operations. Tasks are durable state machines that carry information about the underlying | ||
| /// execution state of requests. |
There was a problem hiding this comment.
Tasks are not necessary for long-running operations.
| /// The tasks capability enables clients to augment their requests with tasks for long-running | |
| /// operations. Tasks are durable state machines that carry information about the underlying | |
| /// execution state of requests. | |
| /// The tasks capability enables clients to augment their requests with tasks to enable status | |
| /// monitoring and persistent result retreval. Tasks are durable state machines that carry | |
| /// information about the underlying execution state of requests. |
|
@PranavSenthilnathan Can you take a look at this? I think we'll probably want do something similar for the draft (non-experimental) version of Tasks you're working on at #1579. |
|
@halter73 |
SEP-2663 moves the task capability on the client to be per-request now. So the capability for tasks would unambiguously only be for the server. There is a separate capability for extension negotiation - whether the tasks extension as a whole is supported. But I'm not sure if we need to expose that as an option since we can always say that we support the extension and defer choosing whether or not to use tasks on a per-request basis. But we can still add the feature implemented in this PR before we implement SEP-2663. |
Split
McpTasksCapabilityintoServerMcpTasksCapabilityandClientMcpTasksCapabilityCloses #1183
What changed
McpTasksCapabilityandRequestMcpTasksCapabilitywere shared by bothServerCapabilities.TasksandClientCapabilities.Tasks, but their valid sub-capabilities are role-specific:tasks.requests.tools.calltasks.requests.sampling.createMessageandtasks.requests.elicitation.createThe single shared type allowed setting sampling/elicitation capabilities on a server (and tools on a client)
with no compile-time error.
After this change
ServerMcpTasksCapabilityServerCapabilities.TasksServerRequestMcpTasksCapability—ToolsonlyClientMcpTasksCapabilityClientCapabilities.TasksClientRequestMcpTasksCapability—Sampling+ElicitationonlyEach capability file is named after its dominant type, consistent with the existing convention in the
Protocol/folder.No behavioral changes — JSON property names and all capability check paths are identical.