skip to content

MCP deprecated roots in 2026-07-28 — what replaces them, and by when?

level: seniorimportance: should knowfreq 42%

answer

  1. deprecated, not deleted
  2. three named migration paths
  3. twelve months minimum in the spec
  4. one date, plus a year
  5. make the path an argument

basics

~20 s

Revision 2026-07-28 deprecates roots under SEP-2577 and directs implementers to pass directories and files as tool parameters, resource URIs, or server configuration. Deprecated features stay at least twelve months, so the earliest removal is a revision released on or after 2027-07-28.

solid answer

~50 s

Roots were deprecated in revision 2026-07-28 (SEP-2577), alongside sampling and logging. The named migration is to make the path ordinary data: declare the directory or file as a parameter in the tool's `inputSchema`, expose it as a resource URI the client reads, or configure it on the server side. Deprecated is not removed — a deprecated feature remains in the specification for at least twelve months, so the earliest revision that may drop roots is the first released on or after 2027-07-28. Practically that means an existing server should keep answering while it has legacy-era clients, and a new server should not adopt roots at all. The migration is also a strict improvement: a path in a tool argument is visible in the call the user approves, cannot go stale between calls now that the roots-changed notification is gone, and costs no extra round trip through an input-required result.

code

json · 12 lines
json
{
  "name": "search_code",
  "description": "Search a project directory for a pattern",
  "inputSchema": {
    "type": "object",
    "properties": {
      "directory": { "type": "string", "description": "Absolute path to search" },
      "pattern": { "type": "string" }
    },
    "required": ["directory", "pattern"]
  }
}

go deeper

for a junior

Remember that MCP 2026-07-28 deprecates roots and that the replacement is to pass the directory as a normal tool parameter.

for a middle

State the policy correctly — still in the spec, at least twelve months, earliest removal on or after 2027-07-28 — and name all three migrations: tool parameters, resource URIs, server configuration.

for a senior

Explain why roots were deprecated (advisory not enforced, session-shaped under a now-stateless protocol, extra round trip) and describe a staged migration that does not break clients still on the older era.

for a principal

Own the fleet-level call: which servers keep answering through the window, how you instrument fallback usage, and the general principle that context the client already holds should travel as call arguments rather than as a protocol side channel.

## What the deprecation says Revision 2026-07-28 marks roots deprecated under SEP-2577, in the same sweep that deprecated sampling and logging. The migration guidance is explicit: pass directories or files via **tool parameters**, **resource URIs**, or **server configuration**. ## The deprecation policy, precisely MCP's policy has three parts worth stating exactly, because interviewers probe whether "deprecated" was heard as "gone": 1. A deprecated feature **remains in the specification** — it is still legal to implement and to use. 2. It remains for **at least twelve months** from the revision that deprecated it. For roots, deprecated in 2026-07-28, the earliest revision that may remove it is the first one released **on or after 2027-07-28**. 3. **New implementations SHOULD NOT adopt it.** So the correct posture differs by situation. A shipped server with real users on older clients keeps its roots handling working through the window; there is no urgency and no breakage. A server being written now should never grow the code path in the first place. ## Migration one: tool parameters The most direct replacement. Instead of asking for roots mid-call, declare the path in the tool's `inputSchema`: A `search_code` tool gains a required `directory` string. The client fills it — from the user's open workspace, exactly the knowledge roots existed to convey. The argument then appears in the `tools/call` the host shows the user for consent, which is a real gain: with roots, the folder disclosure happened in a side channel the user never saw. ## Migration two: resource URIs When the point is to *expose* content rather than to scope work, resources are the better fit. `resources/list` and `resources/read` handle many URI schemes under RFC 3986 — `file://`, `git://`, `https://` — where a root was restricted to `file://` and could only ever hint. Templates via `resources/templates/list` cover parameterised paths. ## Migration three: server configuration For a server deployed with a fixed scope — an internal docs server bound to one repository — the path is deployment configuration, not protocol traffic. This also has an isolation benefit roots never delivered: pin the directory at launch and run the process under a restricted user or in a container, and the boundary is enforced by the kernel rather than requested politely. ## Why roots were deprecated at all Several threads converge: - **They read as a security boundary and were not one.** A field that looks like a sandbox but is purely advisory is a hazard in design reviews. - **They assumed a session.** A roots list handed over once and held is session-shaped thinking, and 2026-07-28 made MCP explicitly stateless: every request self-contained, no reliance on prior requests, an open stdio process is not a conversation. - **Their update channel is gone.** `notifications/roots/list_changed` and the `roots.listChanged` sub-capability were removed, leaving no way to keep a roots list fresh. - **They cost a round trip.** With server-initiated requests removed, fetching roots now means returning an `input_required` result and having the client retry the original `tools/call` under a new id — a whole extra exchange to learn something the client could simply have passed as an argument. - **They were client-shaped.** Roots really encoded "the folders open in this IDE", which is host-product configuration rather than protocol substance. ## What to do with an existing server A sensible sequence: add the explicit parameter to the tools that need a path and mark it optional at first; keep the roots request as a fallback when the parameter is absent; watch how often the fallback fires; drop it once it is quiet or once the deprecation window is closing. Do not break clients on day one — the deployed fleet in 2026 straddles both eras, and roots are legal for at least another year. ## Answering well Give all three named migrations, get the date arithmetic right (deprecated 2026-07-28, earliest removal on or after 2027-07-28, at least twelve months, still in the spec until then), and be able to explain *why* — advisory-not-enforced, session-shaped in a stateless protocol, an extra round trip for data the client already had.

  • Does deprecated mean a 2026-07-28 server may stop answering roots requests?
    A server never had to answer them — it is the client that supplies roots. What deprecation means for a server is that it should stop *asking*, and for a client that it need not add support if it lacks it. Existing support on either side stays legal for at least twelve months, so a client that already answers should keep answering until roots are actually removed in a revision on or after 2027-07-28.
  • What else did revision 2026-07-28 deprecate alongside roots?
    Sampling and logging, both under SEP-2577, plus Dynamic Client Registration via RFC 7591 in favour of OAuth Client ID Metadata Documents. Sampling's migration is to integrate with an LLM provider API directly; logging's is to write to `stderr` on stdio and use OpenTelemetry for observability. Elicitation was explicitly *not* deprecated — it is the surviving way a server asks the user for input.
  • Your server takes a directory as a tool parameter now. What did you gain besides future-proofing?
    Visibility and freshness. The path appears in the `tools/call` arguments the host shows the user before approving, so the folder disclosure is part of the consent decision rather than a side channel. It is also current by construction — there is no cached list to go stale, which matters because 2026-07-28 removed the roots-changed notification entirely. And you save the input-required round trip.
  • How would you stage the migration for a server with live users on mixed-era clients?
    Add the path parameter as optional and prefer it when present, keeping the roots request as a fallback. Instrument how often the fallback fires. As clients adopt the parameter the fallback goes quiet; then make the parameter required and delete the roots path well before the removal window opens after 2027-07-28. Nothing breaks on any single day, which matters when the deployed fleet straddles two eras.

saying these in an interview costs you the question

  • Says roots were removed in 2026-07-28 rather than deprecated
  • Expects removal immediately in the next revision
  • Cannot name a migration path for the directory
  • Claims elicitation was deprecated in the same sweep
  • Proposes roots for a newly written MCP server

context

resolving links…