SEP-2663: Clarify MRTR+Task server behavior

Author: LucaButBoring

docs/seps/2663-tasks-extension.mdx

@@ -376,6 +376,8 @@ The embedded `task` is the seed state for the task, typically (though not necess
 
 A server **MUST NOT** return `CreateTaskResult` until the task is durably created — that is, until a `tasks/get` for the returned `taskId` would resolve. In eventually-consistent environments, the server **MUST** wait for consistency before responding. This requirement eliminates the need for clients to speculatively poll for task creation.
 
+Server implementations that use multi round-trip requests in conjunction with task creation (for example, a tool that requires elicitation over `IncompleteResult` before creating a task) **SHOULD** resolve all MRTR exchanges _synchronously_ before responding with a `CreateTaskResult`.
+
 ### Task Polling
 
 Clients poll for task completion by sending `tasks/get` requests.
@@ -962,6 +964,10 @@ The eventual-consistency on the ack is the same separation as for `tasks/update`
 
 ### Composition with Multi Round-Trip Requests
 
+The following new requirement is introduced:
+
+> Server implementations that use multi round-trip requests in conjunction with task creation (for example, a tool that requires elicitation over `IncompleteResult` before creating a task) **SHOULD** resolve all MRTR exchanges _synchronously_ before responding with a `CreateTaskResult`.
+
 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.