Skip to content

Add a stable server-side MCP Task execution extension point #1820

Description

@cecilphillip

Is your feature request related to a problem? Please describe.

WithTasks creates a durable task record through IMcpTaskStore, but executes the tool in a process-local Task.Run.

This prevents servers from delegating task execution to durable systems such as Temporal, Orleans, Hangfire, or an external queue. A durable IMcpTaskStore preserves task state, but it cannot control how execution is started.

Replacing the call-tool handler is not a suitable alternative because it relies on experimental alternate-result APIs and replaces parts of the standard MCP tool pipeline.

Describe the solution you'd like

Add a stable extension point that allows WithTasks to delegate execution after the task record has been created.

The extension point should provide:

  • The created task information, including task ID.
  • The matched tool request and request context.
  • Access to the normal tool invocation pipeline when local execution is desired.
  • Clear ownership of request-scoped services and disposal.
  • Defined ordering for authorization and request filters.
  • Cancellation information.

The existing process-local behavior should remain the default.

A custom executor should be able to submit the task to an external durable runtime without invoking the tool body in the MCP server process. Existing tasks/get, tasks/update, and tasks/cancel handling should continue to use IMcpTaskStore.

The exact interface is open for discussion. Conceptually:

public interface IMcpTaskExecutor
{
    ValueTask StartAsync(
        McpTaskExecutionContext context,
        CancellationToken cancellationToken);
}

Describe alternatives you've considered

  • Custom IMcpTaskStore: persists state but cannot replace the process-local execution mechanism.
  • Custom CallToolWithAlternateHandler: uses experimental APIs and replaces the normal tool pipeline.
  • Forking or reimplementing WithTasks: duplicates task negotiation, filtering, DI-scope, cancellation, and result-handling behavior.
  • Keeping execution process-local: unsuitable for tasks that must survive server process replacement.

Additional context

The extension point should preserve existing behavior for applications that do not configure a custom executor.

A useful acceptance scenario would be:

  1. An MCP task is created.
  2. A custom executor submits it to an external durable runtime.
  3. The original MCP server process exits.
  4. Another server instance continues serving tasks/get, tasks/update, and tasks/cancel.
  5. The task reaches a terminal state without depending on the original process.

Metadata

Metadata

Assignees

No one assigned

    Labels

    P2Moderate issues, valuable feature requestsenhancementNew feature or requestready for workHas enough information to start

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions