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)
58 lines
4.4 KiB
Markdown
58 lines
4.4 KiB
Markdown
# 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. |
|