Can Your Bot Trust an MCP Progress Notification?
A progress event can help a person see that an MCP tool call has advanced. It cannot certify that the call will finish, and silence does not prove that it stopped. The current Tasks extension uses its own status mechanism for work that outlives a request.
AI-assisted editorial: researched and drafted with AI using the primary sources linked below. Examples are illustrative; they are not measured product results. Editorial policy.
Key takeaways
- A client asks for request progress with a unique progressToken, but the server may send no updates at all.
- Only accept increasing progress values for an active request; a notification after completion is not valid request progress.
- Use the final tool result or the Tasks extension's terminal state for completion, plus an independent deadline and readback for uncertain side effects.
What a request progress event actually says
Suppose an illustrative report bot calls a tool that may take a minute. It includes a progressToken in the request metadata so the server can send notifications/progress while that particular request is running. The current MCP progress specification calls the mechanism optional: the server may send updates, but it is free to send none and to choose its own frequency. A quiet progress channel therefore says nothing reliable about whether the tool is busy, stalled, or already on its way to returning a result.
A notification that does arrive carries the token and a current progress value. It may also carry a total and a human-readable message. This is useful display information, not a completion receipt. A message such as 'reading source 3 of 4' describes the server's reported intermediate state. It does not prove that the fourth source was read, that a report was saved, or that a later error cannot occur. Keep the final tool response as the separate outcome signal.
Sources: Progress - Model Context Protocol.
Validate updates while the original request is active
The current progress specification requires a token to be a string or integer and unique among active requests. A progress notification must refer to a token supplied in an active request and an operation still in progress. Its progress value must increase on each update, even when the total is unknown, and notifications must stop after completion. A client can apply those rules locally: associate the token with one call, remember its highest progress value, and discard stale, duplicate, decreasing, or post-result updates.
In the illustrative report bot, Run A sends values 1, 2, and 3 before a final result. The UI can show each step, while the bot decides success only from the result. Run B sends no notifications and returns successfully after 45 seconds; that is permitted. Run C emits a notification for a token whose request already finished; the client drops it rather than reopening or retrying a completed call. These are protocol and client-handling examples, not measured behavior of BotBento or a particular MCP server.
Sources: Progress - Model Context Protocol.
Use task status for work that outlives the call
The 2026-07-28 protocol places durable asynchronous work in the separate io.modelcontextprotocol/tasks extension. A server may answer a supported tools/call with a task handle when the client has declared that extension. The client can then poll tasks/get for the task's status and eventual result. The extension also permits notifications/tasks after an explicit subscription. This is a different lifecycle from an active request's optional notifications/progress stream.
The Tasks extension explicitly does not support notifications/progress or notifications/message on tasks in general, and forbids them on the task subscription stream. Do not carry the initial request's progress token forward as if it were a task-lifetime heartbeat. In the report example, once the call returns a task handle, track that task ID with tasks/get or the subscribed task-status notifications. Inspect its terminal state and result, including a tool result's isError field, before calling the report successful. A task-status update is still not proof that an external side effect is visible; check the destination separately when it matters.
Sources: Tasks - MCP Tasks Extension.
Give the bot a deadline and an outcome check
Set a deadline for the request according to the operation you are willing to wait for. Progress updates may make waiting less opaque to a person, but do not let an endlessly chatty server postpone an absolute deadline without limit. When the deadline expires, record the outcome as unknown until you can check the tool result or an external destination. A timeout tells you about your waiting policy; it does not prove that the server stopped executing or that no side effect occurred.
For the illustrative report bot, write down a stable report slot before calling the tool. Show increasing progress as a courtesy. If the call returns a completed result, inspect it and read back the report destination if a saved artifact is required. If the call times out, check that destination before retrying, so a report that arrived late does not become a duplicate. If the server returned a task handle, observe the task through its own status method instead of inferring state from missing request-progress notifications. This keeps progress, completion, and external effect as three different pieces of evidence.
Sources: Progress - Model Context Protocol, Tasks - MCP Tasks Extension.
Primary sources
Sources checked 2026-10-02. Standards and product documentation can change; follow the linked version when implementing.
- Progress - Model Context Protocol — Model Context Protocol
- Tasks - MCP Tasks Extension — Model Context Protocol
BotBento is in development. Suggest a correction.