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

3.1 KiB

Raw Blame History

Cancellation 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	Cancellation utility (MCP Specification v2025-11-25)
Source URL	https://modelcontextprotocol.io/specification/2025-11-25/basic/utilities/cancellation
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

Cancellation is an optional notification (notifications/cancelled with requestId and optional reason) that references only same-direction requests believed still in progress. Clients must never cancel initialize. Receivers should stop processing, free resources, and send no response, while both sides must handle the race between a cancellation and an in-flight response gracefully.

Key findings

Cancellation is "optional", via {"method":"notifications/cancelled","params":{"requestId":"123","reason":…}}.
"MUST only reference requests that: Were previously issued in the same direction; Are believed to still be in-progress."
"The initialize request MUST NOT be cancelled by clients."
Receivers "SHOULD: Stop processing… Free associated resources… Not send a response"; "MAY ignore" unknown or already-completed requests; the sender "SHOULD ignore any response… that arrives afterward."
"Both parties MUST handle these race conditions gracefully" (cancel vs. response in flight).

Pros / strengths

Small, complete contract: one notification shape plus clear rules for both sides (when to send, what to reference, what receivers do, how to treat late responses).
The initialize carve-out removes a dangerous edge case by fiat: the handshake can never be cancelled out from under the connection.
Race-condition handling is normative ("MUST handle these race conditions gracefully"), so a client that drops late responses after cancelling is compliant, not sloppy.

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.
Cancellation is advisory: receivers MAY ignore unknown or completed ids, so a client cannot rely on cancellation to actually stop server work, only to signal disinterest.
Requires request-id bookkeeping (same direction, believed in-progress) that a truly minimal fire-and-forget client would otherwise skip.

Relevance to tai

This is the client-side timeout path: on request timeout, send notifications/cancelled with the timed-out request id, then drop late responses. Pairs directly with the lifecycle page's cancel-on-timeout SHOULD.

Changelog

Date	Change
2026-10-18	Initial dossier created.

3.1 KiB Raw Blame History