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.0 KiB

Raw Blame History

Roots (client feature, 2025-11-25)

Metadata

Field	Value
Institute	Molodetz Institute - Research & Retrieval Division
Subject	mcp-client-support
Document type	Source Dossier
Tier	1
Source title	Roots (MCP Specification v2025-11-25)
Source URL	https://modelcontextprotocol.io/specification/2025-11-25/client/roots
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 (partial read; findings cover retrieved sections only, see Cons)
Status	Active

Summary

Roots is a server-initiated client feature: supporting clients declare the roots capability, answer server roots/list requests with file:// URIs, and emit notifications/roots/list_changed when their roots change (if listChanged was declared). Clients without the feature return -32601 (Method not found). It is cleanly optional: a minimal client omits the capability and answers with the standard error.

Key findings

"Clients that support roots MUST declare the roots capability during initialization" ({"roots":{"listChanged":true}}).
Server-to-client request roots/list; response {"roots":[{"uri":"file:///…","name":…}]}; a root uri "MUST be a file:// URI in the current specification."
Clients with listChanged "MUST send" notifications/roots/list_changed on change.
Unsupported: return -32601 (Method not found), e.g. "message": "Roots not supported".

Pros / strengths

Minimal surface for a server-initiated feature: one request, one optional notification, one capability flag.
The unsupported path is specified with a literal error code and message, so omission is compliant behavior rather than a gap.
file://-only URIs in the current spec keep validation trivial for any client that does implement it.

Cons / limitations / caveats

Per the pack's Uncertainty notes this page was only partially read; findings cover the retrieved sections, and deeper subsections were not read.
No explicit author names or publish dates appear on the page; the date above is the version stamp in the URL.
Deprecated in the 2026-07-28 revision ("Deprecate the Roots, Sampling, and Logging features… new implementations should not add support"), and server-initiated requests are replaced by MRTR there, so new roots code is handshake-era-only investment.

Relevance to tai

Optional server-initiated feature; a minimal client simply omits the capability and answers roots/list with -32601. Relevant to tai mainly as the pattern for all three skippable client features: omit capability, return Method not found if asked.

Changelog

Date	Change
2026-10-18	Initial dossier created.

3.0 KiB Raw Blame History