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)
54 lines
3.0 KiB
Markdown
54 lines
3.0 KiB
Markdown
# 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. |
|