Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Restore `[McpServerTool]` composability with MRTR input requests + tasks

Aperta
  • Qualcosa non va?
#1,635 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

@KirschBluteX ci sta già lavorando.

Dal 13/8/2026.

  • #1814 di @KirschBluteX — aperta

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
35/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Tranquilla
Stack tecnologico
csharp
Ambito
backend-api-design

Direzione di ricerca

Inizia da src/ModelContextProtocol.Core/Server/McpTaskExecutionContext.cs, dal wrapper dell'attività intorno a McpServerImpl.cs:933 e dai test eliminati tests/ModelContextProtocol.Tests/Server/AutomaticInputRequiredStatusTests.cs per comprendere il comportamento esistente. Definisci e convalida la gestione degli input MRTR consapevole delle attività e la promozione sincrona delle attività, quindi documenta entrambi i pattern con esempi eseguibili in docs/concepts/tasks/tasks.md.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

enhancement P2 ready for work

Context

SEP-2663 (Tasks extension) is being implemented in #1579 and SEP-2322 (MRTR) landed in #1458. Both extensions let a tool ask the user for input mid-execution, but via different protocol mechanisms:

  • MRTR: tools/call round-trips — the server returns an input_required result, the client re-sends tools/call with input responses, the server replays the handler.
  • Tasks: tasks/update — the server sets the task to status = input_required with the pending input requests, the client sends tasks/update with input responses, the task body's ElicitAsync/SampleAsync/RequestRootsAsync await resumes.

End users writing [McpServerTool] methods don't know (and shouldn't need to know) which mechanism the client is using. Today, after #1579 lands, two composition cases break:

Case 1: [McpServerTool] + tasks _meta opt-in + input requests inside the method body

A [McpServerTool] method that calls ElicitAsync/SampleAsync/RequestRootsAsync works when invoked synchronously (MRTR translates the call into a tools/call round-trip). But when the client signals the tasks opt-in (SEP-2663 §51 _meta envelope), the SDK pre-creates a task and runs the method body in Task.Run. Inside the body, the MRTR backcompat resolver throws InputRequiredException. The task wrapper's generic catch (Exception ex) at McpServerImpl.cs:933 turns this into a Failed task with the literal exception message — no hint that "MRTR can't compose with tasks under this wrapper".

The SEP-1686-era SDK supported this case via the AutomaticInputRequiredStatusTests test class (now deleted in cec5d998), which asserted that ElicitAsync/SampleAsync inside a task body auto-transitioned the task to InputRequired status. SEP-2663 preserves this capability at the protocol level (InputRequiredTaskResult + UpdateTaskRequestParams.InputResponses) but the new task wrapper doesn't wire it through.

Case 2: Sync [McpServerTool] that needs to escalate to a task mid-execution

A [McpServerTool] method may run synchronously for "most" requests but occasionally need to do long-running work. Today, the only way to support this is to write a CallToolWithTaskHandler that drives the task lifecycle manually. The pre-#1458 SDK had a DeferTaskCreation opt-in on [McpServerTool] that I removed in #1458 to keep the MRTR PR minimal — so this capability is currently absent.

Restoring something like DeferTaskCreation would let the method run sync first, then call e.g. context.PromoteToTaskAsync() to create a task and detach.

Proposed approach

Design and implement a unified composition story that addresses both cases. Sketch (not prescriptive — the right design needs more thought):

  1. Task-aware MRTR for Case 1. When MRTR sees that it's running inside a task scope (via McpTaskExecutionContext, which already exists at src/ModelContextProtocol.Core/Server/McpTaskExecutionContext.cs), translate ElicitAsync/SampleAsync/RequestRootsAsync into task-protocol input requests (taskStore.SetInputRequestsAsync(...) and await tasks/update resume) instead of MRTR round-trips. The deleted AutomaticInputRequiredStatusTests is the behavioral contract to restore.

  2. DeferTaskCreation for Case 2. Re-introduce the [McpServerTool(DeferTaskCreation = true)] opt-in (or an equivalent McpServerToolCreateOptions shape) plus a context API (context.PromoteToTaskAsync(McpTaskInfo?) or similar) that the method can call to escalate.

  3. Documentation in docs/concepts/tasks/tasks.md covering both patterns with runnable examples.

Open design questions:

  • Should DeferTaskCreation be the default for async [McpServerTool] methods, or stay opt-in? (Default-on is more ergonomic but changes existing behavior.)
  • How should McpTaskExecutionContext be discovered from within MRTR — AsyncLocal, parameter injection, or something else?
  • What does Case 1 look like when the client supports neither the tasks extension nor MRTR? (Probably: today's behavior, error returned.)

Out of scope

  • Mid-flight transport switching (sticky session vs. resumable HTTP) — orthogonal, blocked on SEP-2575/2567 / #1610.
  • Cross-process task store handoff for DeferTaskCreation — IMcpTaskStore already abstracts this.

Related

  • #1458 — MRTR (removed the original DeferTaskCreation to keep scope minimal)
  • #1579 — SEP-2663 Tasks extension
  • #1610 — sessionless + handshake-less draft protocol (SEP-2575 + SEP-2567)
  • SEP-2663 §51 (per-request _meta opt-in envelope), §306 (durability), §186 (failed.error shape)
  • Deleted test (SEP-1686-era behavior contract for Case 1): tests/ModelContextProtocol.Tests/Server/AutomaticInputRequiredStatusTests.cs removed in commit cec5d998
Lingua principale
C#
Stelle
4.6k
Fork
819
Merge medio
8g 7h
PR unite (30g)
3

Preparare l'ambiente

Apri in Codespaces

Avvia il container di sviluppo del progetto nel browser, con il tuo account GitHub.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di modelcontextprotocol/csharp-sdk

Tutte le issue di modelcontextprotocol/csharp-sdk

Issue simili

Altre issue su C#

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.