Pre-submission Checklist

• I have verified this would not be more appropriate as a feature request in a specific repository
• I have searched existing discussions to avoid duplicates

Your Idea

This is a distillation of thoughts across multiple threads and other protocols to enable multi-turn interactions in MCP. Starting with discussion thread to get feedback, before raising PR.

Abstract

This proposal outlines a mechanism to enhance the Model Context Protocol with request status tracking capabilities. By introducing a progress field in responses and associated retrieval methods, MCP can support multi-turn interactions, partial streaming responses, and agent-driven conversation flows.

Proposed approach here in one way or other is adopted by majority of hosted agents(return of control, function call) and multi-turn protocols(interrupts, awaits), ie, provide job like semantics spanning multiple requests/results.

1. Alternative would be for MCP servers to send a request/notification to client, but that leave the state of existing request ambiguous, specially in serverless compute env with long delays in-between turns. Further not all servers would want to support server sent notifications because of complexity.
2. Another dimension would be introduce a new capability, which provides task semantics geared towards agents, similar to how sampling is geared towards LLMs

Motivation

As MCP gains traction as a protocol for agent interactions, several limitations have emerged in the current specification:

1. Lack of multi-turn interactions: Currently, MCP tools must complete their execution within a single request-response cycle, making it impossible to pause execution to request additional user input.
2. Incomplete streaming support: While progress notifications provide basic updates, there's no standardized way to return partial results before an operation completes.
3. No request retrieval mechanism: Clients have no standardized way to check on the status of a previously initiated request or to fetch results after an arbitrary delay.
4. Limited agent interactivity: Agents need to pause execution, ask follow-up questions, and resume based on user responses - patterns not currently supported by the protocol.

This problem is especially apparent in scenarios like:

1. Long-running operations that benefit from streaming partial results
2. Workflows requiring additional user input to complete
3. Agent hierarchies where sub-agents need to request human feedback
4. Asynchronous operations where results aren't immediately available

Proposal

MCP already supports progress and cancellation notifications. This proposal introduces progress state tracking to the MCP protocol, enabling multi-turn interactions and partial result streaming through two core mechanisms:

1. Enhanced Result Objects with Progress State

We propose extending the existing Result interface to include a progress field within the _meta object. This enhancement allows servers to communicate the current state of a request directly within response objects:

export interface Result {
    // Existing fields
    _meta?: {
        /**
         * Current status of the request
         */
        progress?: {
            /**
             * Progress token field already supported as part of request _meta field
             */
            progressToken: ProgressToken;

            /**
             * The current state of the request
             * - completed: The request has finished successfully
             * - input-required: Additional input is needed to continue processing
             * - working: The request is still being processed
             * - failed: The request failed to complete
             */
            state: "completed" | "input-required" | "working" | "failed";
            
            /**
             * Optional timestamp of the status update
             */
            timestamp?: string;
            
            /**
             * An optional message describing the current progress
             */
            message?: string;
        };
    };
}

This extension enables:

1. Multi-turn interactions by allowing servers to indicate when additional input is needed (input-required state)
2. Streaming partial results while still processing by returning content with a working state
3. Consistent status reporting across different operation types

2. Progress Retrieval Method

To complement the enhanced result objects, we introduce a new method for clients to retrieve the current progress of any ongoing request:

export interface GetProgressRequest extends Request {
    method: "progress/get";
    params: {
        /**
         * The token identifying the request to check progress for
         */
        progressToken: string;
    };
}

export interface GetProgressResult extends Result {
    result: Result
}

This method enables:

1. Asynchronous checking of long-running operations
2. Retrieval of the latest partial results at any time
3. Reconnection to in-progress operations after client disconnections

3. Extend tool annotation

Extend tool annotations to hint if it support multi-turn interactions.

export interface ToolAnnotations {
  // Existing fields
  multiTurnHint?: boolean;
}

Request Flow Examples

Multi-turn conversation with human in the loop

# Request
HEADER: mcp-session-id=1
{
  "id": 2,
  "method": "tools/call",
  "params": {
    "name": "weather_agent",
    "arguments": {
      "input": "What's the weather?"
    },
    "_meta": {
      "progressToken": "123"
    }
  }
}

# Response
HEADER: mcp-session-id=1
{
  "id": 2,
  "result": {
    "content": [
      {
        "type": "text",
        "text": "Which city?"
      }
    ],
    "_meta": {
      "progress": {
        "progressToken": "123"
        "state": "input_required"
      }
    }
  }
}

# Request
HEADER: mcp-session-id=1
{
  "id": 3
  "method": "tools/call",
  "params": {
    "name": "weather_agent",
    "arguments": {
      "input": "seattle"
    }
    "_meta": {
      "progressToken": "123"
    }
  }
}

Stream of partial chunked response

# Response
HEADER: mcp-session-id=1
{
  "id": 3,
  "result": {
    "content": [
      {
        "type": "text",
        "text": "Weather in"
      }
    ],
    `"_meta": {
      "progress": {
        "progressToken": "123"
        "state": "working"
      }
    }`
  }
}

Get latest progress

# Request
HEADER: mcp-session-id=1
{
  "id": 4,
  "method": "progress/get",
  "params": {
    "progressToken": "123"
  }
}

# Response
HEADER: mcp-session-id=1
{
  "id": 4,
  "result": {
    "content": [
      {
        "type": "text",
        "text": "Weather in"
      }
    ],
    "_meta": {
      "progress": {
        "progressToken": "123"
        "state": "working"
      }
    }
  }
}

Backward Compatibility

This proposal is designed to maintain full backward compatibility:

1. All status fields are optional and extend existing interfaces rather than replacing them.
2. Servers not supporting these features can ignore the new fields and respond normally.
3. Clients not supporting these features can simply disregard status fields in responses.
4. The existing request/response model remains unchanged.

Older clients will simply ignore the additional fields, while older servers will not provide status information, leading to graceful degradation of functionality.

Server Implementation Requirements

Servers implementing this proposal must:

1. Maintain state for in-progress requests identified by progressToken
2. Handle additional requests with the same progressToken as continuations
3. Respond to progress/get requests with the latest status and content
4. Support appropriate timeout and cleanup mechanisms for abandoned requests

Client Implementation Requirements

Clients implementing this proposal must:

1. Generate and track unique progressToken values for requests
2. Handle partial responses with different progress states accordingly
3. Send appropriate follow-up requests for input-required states
4. Poll for updates using progress/get when needed

Alternatives

1. Progress notification expansion: This option would have been to provide out of band progress update from servers to clients, this approach is still usable, but doesn’t solve to communicate progress when client want to know out of band.
2. Separate request type from server: Define a separate request type which a server can initiate to get input from client. Concern here is that there should anyway be a way to capture status of a request, so this approach unblocks both use-cases. Server wants to request some additional information from client completely out of band is supported via sampling, but its more complex than needed for this use-case.
3. Long-polling approach: Instead of introducing status fields, implement a long-polling mechanism where clients continuously poll for updates. This was rejected due to inefficiency and increased server load.

References

1. MCP Agents Discussion: Improvements for MCP-based agents #111
2. Streaming Tool Use Results: Streaming tool use results #117
3. Model Context Protocol Schema: https://github.com/modelcontextprotocol/modelcontextprotocol/blob/main/schema/2025-03-26/schema.ts

Scope

• Protocol Specification
• SDK Features
• Documentation
• Developer Experience
• Other