retoor
251c3dc2ba
- wire spec: lifecycle, stdio + Streamable HTTP transports, tools, utilities, legacy SSE, versioning, changelog (14 Tier 1) - client ecosystem: Claude Code/VS Code/Cursor/Codex configs, mcp-remote, Smithery, registries, Glama (12 Tier 1) - security/ops: authorization draft, trust model, poisoning, rug pulls, production hardening (12 Tier 1) + 68 Tier 2 cards - conclusions: minimal stdlib client on 2025-11-25, normalizer + resolver agent for pasted configs/GitHub URLs, untrusted-until- consent trust model; nothing built yet - audit PASS (14 subjects, 797 sources, 32 conclusions)
55 lines
2.9 KiB
Markdown
55 lines
2.9 KiB
Markdown
# Progress utility (2025-11-25)
|
|
|
|
## Metadata
|
|
|
|
| Field | Value |
|
|
|---|---|
|
|
| Institute | Molodetz Institute - Research & Retrieval Division |
|
|
| Subject | mcp-client-support |
|
|
| Document type | Source Dossier |
|
|
| Tier | 1 |
|
|
| Source title | Progress utility (MCP Specification v2025-11-25) |
|
|
| Source URL | https://modelcontextprotocol.io/specification/2025-11-25/basic/utilities/progress |
|
|
| Source publisher / author | Model Context Protocol authors (Anthropic-donated open project; site docs) |
|
|
| Source type | standard |
|
|
| Source date (published) | 2025-11-25 (version stamp; no other publish date stated) |
|
|
| Date researched | 2026-10-18 |
|
|
| Researched by | tai (agent), model: Claude Sonnet 5, on behalf of retoor |
|
|
| Research method | gather-subagent direct page fetch, parent synthesis from evidence pack |
|
|
| Confidence | High |
|
|
| Status | Active |
|
|
|
|
## Summary
|
|
|
|
Progress is an opt-in utility: the requester includes a unique string-or-integer `progressToken` in `params._meta`, and the other side may send `notifications/progress` updates carrying the token, a monotonically increasing `progress` value, and optional `total` and `message`. Senders may choose to send no updates at all, and notifications must stop after completion.
|
|
|
|
## Key findings
|
|
|
|
- The requester opts in with `params._meta.progressToken` ("MUST be a string or integer… MUST be unique across all active requests").
|
|
- Updates arrive as `notifications/progress` with `progressToken`, `progress`, and optional `total` and `message`.
|
|
- "The `progress` value MUST increase with each notification, even if the total is unknown"; both "MAY be floating point."
|
|
- Receivers "MAY: Choose not to send any progress notifications."
|
|
- "Progress notifications MUST stop after completion."
|
|
|
|
## Pros / strengths
|
|
|
|
- Clean opt-in design: no capability negotiation, just a token in `_meta`, so a client can use it on one long call without committing globally.
|
|
- Monotonic-progress rule plus optional total/message gives enough structure for progress bars while permitting unknown totals and float values.
|
|
- Explicit permission to send nothing keeps it cheap for servers and means clients must already tolerate absence, which simplifies client logic.
|
|
|
|
## Cons / limitations / caveats
|
|
|
|
- No explicit author names or publish dates appear on the page; the date above is the version stamp in the URL, per the pack's Uncertainty notes.
|
|
- Purely optional end to end: a server may ignore the token entirely, so a client cannot depend on progress for correctness (for example as its only timeout reset).
|
|
- Token uniqueness is scoped across all active requests, which needs a small allocator even in a minimal client if the feature is used at all.
|
|
|
|
## Relevance to tai
|
|
|
|
Purely optional for a minimal client. If long `tools/call`s are expected, the client passes `_meta.progressToken` and routes incoming `notifications/progress` by token; otherwise it can be skipped entirely.
|
|
|
|
## Changelog
|
|
|
|
| Date | Change |
|
|
|---|---|
|
|
| 2026-10-18 | Initial dossier created. |
|