Why does progressToken exist?

[LeeSaferite]

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

Working through the specification and the concept of a progressToken is confusing me. Mechanically I fully understand it and how to use it. My confusion relates to why it's even a distinct thing. It's only relevant when sending a Request, has to be unique across all Active Requests, and there's only one per Request. Why not simply use requestId and a flag in _meta indicating a desire to receive progress tracking? A requestId has stricter requirements and there's already precedent in the spec for using requestId in a notification with request cancellations. As it is, it's adding an extra level of tracking/routing where I have to match up the incoming notification to a request by that progressToken instead of simply by the requestId. It's extra complexity for no obvious reason.

Now that I have understood this, I'll simply be using requestId as a progressToken in my code. It'll make the Requestor code simpler as they don't need a more complicated lookup to route progress notifications. Obviously I can't do anything about the Processor code unless the spec gets updated in the future.

[isheng-eqi]

This is a sharp observation — you have identified real surface-level redundancy between progressToken and requestId. But the separation exists for three reasons that are not immediately obvious from the spec text alone.

1. Separation of concerns: routing vs progress

requestId and progressToken serve different purposes in the protocol state machine:

• requestId is a response routing key. The client uses it to match an incoming Result or Error to the original Request it sent. It is consumed exactly once — when the response arrives, the mapping is discarded.

• progressToken is a notification subscription token. The client uses it to subscribe to a stream of ProgressNotification events that may arrive zero, one, or many times over an arbitrary duration. The subscription may outlive the request's response cycle (the server could send a final progress update after the result).

These are different lifecycle patterns. Conflating them into requestId + flag would couple two independent concerns: request-response matching and event subscription.

2. Implementation flexibility

The spec intentionally does not mandate that progressToken == requestId. This gives implementations freedom:

• A client might reuse a stable progress token across multiple related requests (e.g., a batch job that reports cumulative progress). The spec says "unique across all active requests" but does not require a 1:1 mapping.
• A server might route progress notifications through a separate channel that uses a different identifier scheme (e.g., a WebSocket connection ID) and maps progressToken to that channel internally.
• A proxy or middleware layer might rewrite progressToken without touching requestId, since the two tokens have different scope and lifetime.

If the spec hard-coded "progressToken is always requestId," all of these patterns would break.

3. Security boundary

In multi-tenant or proxied MCP deployments, the requestId may be visible to intermediary layers (load balancers, API gateways, logging systems). A separate progressToken allows the client to generate a cryptographically opaque token for progress subscriptions that intermediaries cannot correlate with specific requests — a minor but real privacy property.

Your workaround is correct

That said: using requestId as progressToken is perfectly valid and common. Most SDK implementations default to this. Your observation that it simplifies the client is accurate — and for single-process, single-tenant deployments, there is zero downside.

The spec allows the separation because it was designed for a broader range of deployments than just "one client, one server, one process." In your case, progressToken = requestId is the right call. The extra complexity exists for the cases where it is not.