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

4.4 KiB

Raw Blame History

Lifecycle: initialize / initialized / negotiation / timeouts (2025-11-25)

Metadata

Field	Value
Institute	Molodetz Institute - Research & Retrieval Division
Subject	mcp-client-support
Document type	Source Dossier
Tier	1
Source title	Lifecycle (MCP Specification v2025-11-25)
Source URL	https://modelcontextprotocol.io/specification/2025-11-25/basic/lifecycle
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

This page defines the connection lifecycle for the 2025-11-25 revision: the initialize request must be the first interaction, followed by the client sending an initialized notification after success. It specifies version negotiation (client sends its latest supported version; server answers with the same version or another it supports), capability tables for both sides, per-request timeouts with cancellation, and the stdio shutdown sequence.

Key findings

"The initialization phase MUST be the first interaction between client and server": the client sends initialize with "Protocol version supported, Client capabilities, Client implementation information."
"After successful initialization, the client MUST send an initialized notification" ({"jsonrpc":"2.0","method":"notifications/initialized"}).
Version negotiation: "the client MUST send a protocol version it supports. This SHOULD be the latest version supported by the client"; "If the server supports the requested protocol version, it MUST respond with the same version. Otherwise, the server MUST respond with another protocol version it supports."
"The client SHOULD NOT send requests other than pings before the server has responded to the initialize request."
Capability table: client capabilities roots, sampling, elicitation, tasks, experimental; server capabilities prompts, resources, tools, logging, completions, tasks, experimental.
"Implementations SHOULD establish timeouts for all sent requests… the sender SHOULD issue a cancellation notification for that request and stop waiting"; "MAY choose to reset the timeout clock when receiving a progress notification… SHOULD always enforce a maximum timeout."
stdio shutdown: the client "SHOULD… 1. First, closing the input stream… 2. Waiting for the server to exit, or sending SIGTERM… 3. Sending SIGKILL."
Init-error example uses JSON-RPC error {"code": -32602, "message": "Unsupported protocol version", "data": {"supported": […], "requested": …}}.

Pros / strengths

Gives the exact 3-message handshake (request, response, notification) with literal JSON for the initialized notification, leaving no framing ambiguity.
Version negotiation is fully specified in both directions, including the mismatch case and a concrete Unsupported protocol version error shape with supported/requested data.
Timeout and shutdown semantics are practical: cancel-on-timeout, optional progress-based clock reset with a mandatory maximum, and an ordered stdio teardown (close stdin, wait or SIGTERM, then SIGKILL).

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.
Timeout durations are left to implementations (only the cancel-on-timeout behavior and the maximum-timeout requirement are normative), so a client must still pick its own values.
Applies to the handshake-based world only: the 2026-07-28 revision removes initialize/notifications/initialized (see the changelog dossier), so this handshake is the interop baseline, not the newest design.

Relevance to tai

Defines the exact 3-message handshake a stdlib client must implement, plus timeout with cancel-on-timeout and stdio shutdown semantics. This is the core of the client state machine: send initialize with latest supported version plus capabilities, await the response, then send notifications/initialized.

Changelog

Date	Change
2026-10-18	Initial dossier created.

4.4 KiB Raw Blame History