SEP-2663: Allow IncompleteResult before task creation

Author: LucaButBoring

docs/seps/2663-tasks-extension.mdx

@@ -617,7 +617,7 @@ On each request while the task is in a `"working"` status, the server returns a
 }
 ```
 
-Eventually, the server reaches the point at which it needs to send an elicitation to the user. It sets the task status to `"input_required"` to signal this, and may additionally provide a `requestState` if it so chooses. On the next `tasks/get` request from the client, the server sends the elicitation payload via the `inputRequests` field. Note that, unlike in [SEP-2322](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2322), the standard task status result is still returned. The updated task polling flow should be thought of as distinct from the MRTR flow, despite sharing many characteristics.
+Eventually, the server reaches the point at which it needs to send an elicitation to the user. It sets the task status to `"input_required"` to signal this, and may additionally provide a `requestState` if it so chooses. On the next `tasks/get` request from the client, the server sends the elicitation payload via the `inputRequests` field. Note that while task `inputRequests` share structural similarities with [SEP-2322](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2322) multi round-trip requests, they are a distinct mechanism: task `inputRequests` are surfaced via `tasks/get` and fulfilled via `tasks/update`, not via retries of the original method. A server that needs client input _before_ returning a `CreateTaskResult` (e.g. to decide whether to proceed) uses the multi round-trip request flow on the original request; a server that needs client input _during_ task execution uses the `inputRequests`/`inputResponses` mechanism described here.
 
 ```json
 {
@@ -960,6 +960,12 @@ In the `2025-11-25` design of tasks, `tasks/cancel` returned a task describing t
 
 The eventual-consistency on the ack is the same separation as for `tasks/update`: The server may record the cancellation request and respond before the worker has actually transitioned the task, without allowing the client to interpret the ack as strongly-consistent.
 
+### Composition with Multi Round-Trip Requests
+
+A `tools/call` that supports both MRTR ([SEP-2322](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2322)) and this extension may use them sequentially by sending one or more `IncompleteResult` exchanges to gather input synchronously, followed by a `CreateTaskResult` to hand off to asynchronous execution. This composition is a consequence of the `resultType` discriminator — each response is independently typed and the client switches behavior based on the value it receives, _without_ maintaining any state between the two modes. Prohibiting this would require imposing an artificial constraint with no protocol-level mechanism to enforce it, since the client is unaware that the server will create a task ahead of time.
+
+The two flows maintain separate state despite sharing field names. The MRTR phase ends when the server returns any non-`"incomplete"` `resultType`, at which point its `requestState` and `inputRequests` keys are consumed. The task phase begins with `CreateTaskResult` and maintains _its own_ `requestState` and `inputRequests` keys independently. Key uniqueness for task `inputRequests` is scoped to the lifetime of the task and does not extend to keys from the preceding MRTR phase. Clients do not need to deduplicate across the two flows.
+
 ## Backward Compatibility
 
 The experimental tasks feature in the `2025-11-25` release is **not wire-compatible** with this extension. Specifically: