Can a server update the progress token in the response to tasks/get

[stindall]

Pre-submission Checklist

• I have checked that this question would not be more appropriate as an issue in a specific repository
• I have searched existing discussions and documentation for answers

Question Category

• Protocol Specification
• SDK Usage
• Server Implementation
• General Implementation
• Documentation
• Other

Your Question

Can Progress token be used in conjunction with Tasks such that the progres is displayed in calls to tasks/get rather than sent as a notification. For example, consider the following task request and response and the subsequent tasks/get response. Is the response valid?

REQUEST
{
"jsonrpc": "2.0",
"id": 1,
"method": "tools/call",
"params": {
"name": "get_weather",
"arguments": {
"city": "New York",
"_meta": {
"progressToken": "abc123"
}
},
"task": {
"ttl": 60000
}
}
}

RESPONSE
{
"jsonrpc": "2.0",
"id": 1,
"result": {
"task": {
"taskId": "786512e2-9e0d-44bd-8f29-789f320fe840",
"status": "working",
"statusMessage": "The operation is now in progress.",
"createdAt": "2025-11-25T10:30:00Z",
"lastUpdatedAt": "2025-11-25T10:40:00Z",
"ttl": 60000,
"pollInterval": 5000
}
}
}

CALL TO TASKS/GET
{
"jsonrpc": "2.0",
"id": 3,
"method": "tasks/get",
"params": {
"taskId": "786512e2-9e0d-44bd-8f29-789f320fe840"
}
}

RESPONSE
{
"jsonrpc": "2.0",
"id": 3,
"result": {
"taskId": "786512e2-9e0d-44bd-8f29-789f320fe840",
"status": "working",
"statusMessage": "The operation is still in progress.",
"createdAt": "2025-11-25T10:30:00Z",
"lastUpdatedAt": "2025-11-25T10:40:00Z",
"ttl": 30000,
"pollInterval": 5000
}
"params": {
"progressToken": "abc123",
"progress": 50,
"total": 100,
"message": "Still working on it..."
}
}

Essentially, I am asking if progress token can be combined with tasks/get responses.

Thanks in advance.

[isheng-eqi]

The short answer: no, the example response you show is not valid per the current spec. Progress is delivered via notifications/progress notifications, not embedded in tasks/get response bodies. But your instinct is reasonable — let me explain why the spec separates them and what you can do instead.

What the spec says

Progress tracking in MCP uses a push model, not a pull model:

1. Client sends a request with _meta.progressToken
2. Server sends zero or more notifications/progress messages to the client
3. Client routes these notifications to the original request using the progressToken

The tasks/get response is defined as returning task status metadata (status, statusMessage, ttl, pollInterval), not progress data (progress, total, message). Your proposed response mixes these two concerns:

// Your proposed tasks/get response — NOT valid
{
  "result": {
    "taskId": "...",
    "status": "working",
    ...
  },
  "params": {                          // ← This field does not exist in a JSON-RPC response
    "progressToken": "abc123",         // ← Progress goes via notifications, not responses
    "progress": 50,
    "total": 100,
    "message": "Still working on it..."
  }
}

A valid JSON-RPC 2.0 response has exactly jsonrpc, id, and result (or error). There is no params field in a response — params only exists in requests and notifications.

Why the spec separates task status from progress

The separation exists because task polling and progress streaming are different patterns with different lifecycles:

	tasks/get polling	notifications/progress
Initiated by	Client (pull)	Server (push)
Frequency	Client-controlled (pollInterval)	Server-controlled (whenever progress changes)
Transport	Request-response	One-way notification
Content	Task lifecycle status	Granular progress (X of Y, message)

If you are using tasks/get polling, you already have a pull mechanism. Embedding progress in the poll response would create a hybrid push-pull model that the spec does not support.

The "Streamable HTTP way" to solve this

In Streamable HTTP transport, notifications can be sent on the response stream. A more idiomatic approach for your scenario:

1. If you use Tasks (polling-based):
The tasks/get response gives status. For detailed progress, the server can still send notifications/progress via the SSE/streaming channel that Streamable HTTP provides. The client subscribes to progress notifications separately from polling task status.

2. If you want to simplify (avoid dual channels):
You could embed a lightweight progress summary in the statusMessage field, which is already part of tasks/get:

{
  "taskId": "...",
  "status": "working",
  "statusMessage": "Processing: 50/100 items complete (50%)",
  "ttl": 30000,
  "pollInterval": 5000
}

This is valid because statusMessage is an opaque string. The client can parse it if it wants structured progress, but it remains spec-compliant.

Bottom line

Your proposed JSON structure mixes response and notification formats. The spec cleanly separates them. Use notifications/progress for real-time progress during task execution, and tasks/get for polling task lifecycle status. If you want a simpler single-channel approach, embed progress info in statusMessage as human-readable text.