This SEP extends the MCP Tasks extension (SEP-2663) with three methods for interacting with running tasks: tasks/steer (unsolicited mid-run feedback), tasks/pause (cooperative halt), and tasks/resume (continue from paused). Together, these enable human-in-the-loop and agent-in-the-loop patterns for long-running task execution — the ability to redirect, pause, and resume work without cancelling and losing accumulated state.

The methods follow the design patterns established by SEP-2663: they use the reserved tasks/ method prefix, carry taskId as the routing key, and respect the consistency model (ack-only writes, cooperative operations, capability negotiation via sub-capabilities within io.modelcontextprotocol/tasks).

This proposal requires SEP-2663 (Tasks Extension, currently in-review) and cannot land until SEP-2663 is accepted, as it depends on the types, methods, and consistency model SEP-2663 introduces.

Motivation and Context

SEP-2663 provides the foundation for durable, asynchronous task execution: create a task, poll for status, deliver input when requested, cancel if needed. This covers the lifecycle, but treats the running task as a closed box — the only client interactions are responding to server-initiated input requests (tasks/update) and terminating (tasks/cancel). For subagent-as-a-service — where a parent agent or human user delegates work to a specialist agent consumed over MCP — two interaction patterns are missing:

1. The user can't redirect. Once a task starts, there is no way for a user or parent agent to provide unsolicited feedback. Deployed human-in-the-loop agent systems (GitHub Copilot, Cursor, Windsurf, Devin) each implement their own form of mid-run feedback, but with no standard mechanism. The absence of a protocol-level primitive forces each to invent its own, fragmenting the ecosystem — exactly the outcome MCP's "convergence over choice" principle aims to prevent. tasks/update is not suitable because it delivers inputResponses keyed to specific inputRequests the server issued; steering is unsolicited direction the server didn't ask for.

2. The user can't pause. Long-running tasks (browser automation, multi-step research, code generation) often reach a point where the user wants to pause — review partial output, think, then continue. Or the server itself needs to pause (browser completed the ask, holding the VM for follow-up). Today the only options are "let it run" or "cancel and lose all progress." tasks/cancel is destructive — it discards accumulated context and partial results.

This proposal solves these by adding:

• tasks/steer — ack-only unsolicited feedback, queued for delivery at the next server-determined safe point. Follows the same ack-only, eventually-consistent pattern as tasks/update and tasks/cancel. Diverges from those methods for terminal tasks (rejects with -32602 rather than silent ack, since delivering queued messages to a completed task would be misleading).
• tasks/pause and tasks/resume — cooperative halt/continue adding a paused status to the task lifecycle. Returns DetailedTask (unlike ack-only writes) so the client has immediate feedback on whether the cooperative operation succeeded. Server MAY also initiate pause without a client request (resource management, billing checkpoints).

Prior Discussion

@LucaButBoring welcomed a formal SEP in #2663: "I would welcome a formal SEP for that... I do like the idea of leveraging the ack-only pattern we're introducing to do unsolicited messaging."

How Has This Been Tested?

Reference implementation deployed across multiple agent services. Key patterns: per-task async queues for steer delivery at safe points, async events for cooperative pause at yield points, custom MCP request handlers.

Breaking Changes

None. Fully backward compatible with SEP-2663. No changes to existing methods, status values, or transitions. The paused status is additive. Capability negotiation via sub-capabilities ensures no silent failures.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update

Checklist

• I have read the MCP Documentation
• My code follows the repository's style guidelines
• New and existing tests pass locally
• I have added appropriate error handling
• I have added or updated documentation as needed

Additional context

Seeking sponsor: @CaitieM20 or @LucaButBoring from the Agents WG would be natural fits given the prior discussion and alignment with the tasks roadmap.

AI Use Disclosure: AI tools were used for cross-referencing SEPs (2663, 2322, 2567, 2575) and adversarial review of the proposal against upstream specs. All design decisions were human-directed.