Motivation

Currently, when sending progress notifications, there is no way to represent concurrent subtasks. If a tool kicks off a workflow with concurrent subtasks, and each subtask emits its own progress notifications, the tool must find a way to coalesce those notifications (or just drop them).

Proposal

Add a notifications/progress/createTracker notification that allows the sender to declare a new progressToken to the receiver. For example:

{
  "jsonrpc": "2.0",
  "method": "notifications/progress/createTracker",
  "params": {
    "progressToken": "New progressToken from server",
    "parent": "Prior progressToken from client OR from another notifications/progress/createTracker"
    "title": "Optional human-readable label"
  }
}

Subsequent progress notifications can then use the declared progressToken. Thus, after a tool sends an appropriate notifications/progress/createTracker notification, it can simply forward progress notifications that are emitted by its subtasks. Furthermore, the tool can also forward notifications/progress/createTracker notifications that are emitted by its subtasks, enabling passthrough notifications from nested subtasks.

Communicating subtask completion

There is an open question about how to communicate when a subtask is finished so that its progress tracker can be hidden.

One approach approach would be to add a dedicated notification, like notifications/progress/destroyTracker or notifications/progress/removeTracker.

Another approach would be to reserve special values for notifications/progress notifications. For example a notifications/progress notification with { progress: -1, total: -1 }.

Yet another approach would be to extend notifications/progress with an optional boolean field like done. For example, { progress: 100, done: true }.