Files

T

retoor 251c3dc2ba research: mcp-client-support subject (106 sources, 3 conclusions)

- 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)

2026-10-18 19:23:02 +02:00

2.9 KiB

Raw Blame History

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/calls 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.

2.9 KiB Raw Blame History