This proposal extends the experimental tasks specification to support subtasks as a form of task nesting. Tasks will become recursive and doubly-linked via optional parentTaskId and childTaskIds properties. This enables logical subdivisions of complex work and partial results, as each subtask will produce its own result value independently of its siblings and parent. Subtask result values must share a shape with that of their parent task, simplifying application integration.

Motivation and Context

Tasks are designed to enable applications to work with workflow-based services in a deterministic way, rather than relying on LLMs to poll those services themselves through tool calls, which is both unreliable and wastes tokens. However, tasks are a coarse-grained unit of execution that does not enable actually communicating the full extent of the work being done to requestors (and particularly to the LLM itself). The protocol does offer progress notifications and log messages to be streamed to requestors, but these events may be both frequent and small, and there do not appear to be any public use cases that involve directing these notifications to LLMs.

By introducing a notion of subtasks that builds on the semantics of the existing request types that tasks can already augment, we enable work to be deliberately chunked according to the designs of individual MCP servers, which can then choose specific work distributions according to what will be semantically-relevant to the requestor for a task of a given type.

How Has This Been Tested?

Not yet, will have a reference implementation before promoting from a draft state.

Breaking Changes

While tasks are experimental, we would still like to minimize breaking changes for developers building on tasks if possible. However, this proposal does represent a partial breaking change for client implementations in a few specific cases. If a server adopts subtasks and those subtasks leverage the input_required status, a client unaware of subtasks will not be monitoring them, and will time out if it attempts to invoke one.

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