SEP-2663 §51 says the per-request opt-in is the SEP-2575 capabilities envelope — not a bare _meta key. Spec says:

A client signals support for tasks on a per-request basis using the SEP-2575 client capabilities envelope:
_meta["io.modelcontextprotocol/clientCapabilities"]["extensions"]["io.modelcontextprotocol/tasks"] = {}

The current bare-key form will be interoperable only with our own server; non-C# peers built strictly to spec won't recognize it.

The matching constant (NotificationMethods.ClientCapabilitiesMetaKey) ships in my draft branch halter73/remove-session-id-draft together with the SEP-2575 plumbing, so the literal here will be replaceable once that lands. Until then, suggest writing the nested form directly:

Note: Also requires a matching change in the server-side detector (McpServerImpl.cs:900 left as a separate comment there). I'd also move any private const string to the beginning although it will be replaced with NotificationMethods.ClientCapabilitiesMetaKey shortly.

Two issues here, fixable together:

1. Missing JSON-RPC code field (SEP-2663 §186). The spec says failed.error MUST be a JSON-RPC error object — { code, message, data? }. Right now we emit only { "message": ex.Message }, so a strict client (or our own McpException.Converter on the round-trip) sees an invalid error object with no code.

2. JsonDocument lifetime bug. JsonDocument.Parse(...).RootElement returns a JsonElement backed by the parent JsonDocument's pooled buffer. Because the document is neither assigned nor using-disposed, it's eligible for GC immediately — its ArrayPool buffer may be returned and recycled while the JsonElement is still being held by InMemoryMcpTaskStore (or any other store implementation). This is a latent buffer-corruption / ObjectDisposedException bug, not just style.

Suggested fix — typed error object + SerializeToElement (no JsonDocument lifetime to worry about) + prefer McpException.ErrorCode when available + don't leak arbitrary exception messages from non-McpException to the client (matches how BuildInitialCallToolFilter redacts non-McpException messages at line 1144):

Requires adding JsonRpcErrorDetail to the source-gen context (McpJsonUtilities.cs). If the existing JsonRpcError/McpError type can be reused, prefer that — I didn't grep exhaustively. Either way, the shape on the wire should be { "code": -32603, "message": "..." }.

If there's a good way to consolidate this with existing our existing transport-level error writing logic, I'm open to that.

Paired with the client-side change at McpClient.Methods.cs#GetMetaWithTaskCapability — the SEP-2663 §51 opt-in is the SEP-2575 nested envelope (_meta/io.modelcontextprotocol/clientCapabilities/extensions/io.modelcontextprotocol/tasks), not a bare top-level _meta key.

Suggested helper + replacement check:

…and add this helper near the bottom of the file (or in McpExtensions):

// Per SEP-2663 §51, the client opts in to the tasks extension on a per-request basis
// via the SEP-2575 capabilities envelope. Accept the bare key as a transitional
// fallback so older C# clients keep working during the experimental window.
// TODO: drop the bare-key fallback once SEP-2575 ships and clients are migrated;
// also swap the literal for NotificationMethods.ClientCapabilitiesMetaKey at that point.
private static bool HasTaskExtensionOptIn(JsonObject? meta)
{
    if (meta is null)
    {
        return false;
    }

    if (meta["io.modelcontextprotocol/clientCapabilities"] is JsonObject caps &&
        caps["extensions"] is JsonObject exts &&
        exts.ContainsKey(McpExtensions.Tasks))
    {
        return true;
    }

    // Transitional: accept the bare-key form written by older C# clients.
    return meta.ContainsKey(McpExtensions.Tasks);
}

Reading both shapes during the experimental window keeps us compatible with both today's C# clients (bare key) and spec-shaped peers (nested envelope).

Adding the test method mirroring SampleTool_ViaTask_RedirectsThroughStore above — covers the server→client roots/list redirect added in McpClientImpl.cs#ResolveInputRequestAsync. Inline suggestion to insert between SampleTool_ViaTask_RedirectsThroughStore and ElicitTool_ViaTask_ClientDedups_InputRequests:

When a CallToolWithTaskHandler returns IsTask = true while TaskStore is also configured, the store's pre-created task is left orphaned in Working forever — the client already received the store's taskId synchronously at L951, so we can't redirect mid-flight to the user's task, and the background runner's early return; here never resolves the store's task.

Most CallToolWithTaskHandler users won't hit this (they return IsTask = false to get the typed input-request/response shape), and registration-time exclusivity would forbid that working combination. So the minimal fix is to turn the orphan into a clear runtime failure on the store's task:

Adding the matching RootsTool fixture, in the same shape as SampleTool two methods up so the test below can drive it. Inline suggestion to insert between SampleTool and IsErrorTool:

SEP-2663 §306 imposes a strong-consistency requirement on CreateTaskAsync that's currently implicit:

The server MUST NOT return CreateTaskResult until the task is durably created — that is, until a tasks/get for the returned taskId would resolve.

The InMemoryMcpTaskStore satisfies this trivially (it assigns to the dictionary before returning), and the existing GetTaskAsync_ImmediatelyAfterCreate_Resolves test enforces it for that one implementation — but the contract on the interface is silent. A custom durable store backed by, say, eventually-consistent storage (or a write-behind cache, or a queued background persistence path) could violate it without realizing it broke the spec, because the SDK's own server code on line 902 just awaits CreateTaskAsync and immediately returns the task ID to the client.

Suggested docs addition (inline):

When a [McpServerTool] method throws InputRequiredException (the MRTR signal) and the call came in with the tasks _meta opt-in, the rethrow at BuildInitialTaskToolFilter line 1133 propagates out of innerTaskHandler at line 920 — but it lands in the generic catch (Exception ex) below. The result: the client gets a Failed task with the literal InputRequiredException message in the payload, with no hint that "MRTR can't compose with tasks under this wrapper."

The PR body already lists "Mid-execution promotion to task — [McpServerTool] methods can't start sync and then escalate" as a known limitation, so the behavior (no MRTR-within-tasks) is acknowledged. The issue is that the failure mode is silent and the surfaced error is misleading.

Minimum fix for this PR — add a dedicated catch (InputRequiredException) before the general catch:

catch (InputRequiredException)
{
    var error = new JsonRpcErrorDetail
    {
        Code = (int)McpErrorCode.InvalidRequest,
        Message = "MRTR (input requests) and tasks cannot be composed via [McpServerTool] yet; " +
                  "use CallToolWithTaskHandler to manage the input-request loop manually within the task body.",
    };
    var errorJson = JsonSerializer.SerializeToElement(error, McpJsonUtilities.JsonContext.Default.JsonRpcErrorDetail);
    await taskStore.SetFailedAsync(taskId, errorJson).ConfigureAwait(false);
}

Combine this with the code-field + JsonDocument-lifetime fix above so the catch block ends up as one coherent edit.

The broader composition story — restoring DeferTaskCreation for sync-to-task escalation + task-aware MRTR so input requests issued inside a task body actually work — is tracked in #1635. Happy to have that picked up as a follow-up after this lands.