Migrating MCP roots without mistaking project scope for file access control

One migration, two decisions

Suppose an agent should summarize a project's documentation but should not read the rest of the machine. Selecting that project in a client can express the intended scope. It does not, by itself, establish what a local server process can open. The current roots page is explicit: roots are informational guidance rather than an access-control mechanism, and the protocol does not enforce that servers stay within them.[1]

Roots are deprecated as of protocol 2026-07-28, the edition reached by the latest routes when retrieved for this analysis.[1][5][8] The documented alternatives are directories or files passed through tool parameters, resource URIs or server configuration. Choosing how to pass the project location and deciding what the server may access are separate decisions. A migration can preserve the location while accidentally dropping an existing access check.

Our recommendation is to specify both before approving sensitive use: the replacement interface that carries useful scope, and the component that enforces the permitted operations. This is our evaluation method, not a new MCP requirement. A root-aware server may already enforce an effective boundary; establish where that happens rather than assuming either that roots make it safe or that every roots implementation is unsafe.

Deprecation is a migration window, not unchanged behavior

The roots notice says new implementations SHOULD NOT adopt the feature and existing implementations SHOULD migrate.[1] The official repository records Specification Enhancement Proposal SEP-2577 as merged and labeled final; its merge date is May 15, 2026 UTC.[6] That proposal history is separate from the effective deprecation revision. Neither is an October 16 launch.

Under the feature lifecycle policy, the ordinary minimum window is twelve months from release of the revision marking the feature Deprecated, not from the SEP's Final date.[2] The pinned registry lists roots' earliest removal as the first revision released on or after 2027-07-28.[3] Removal is a release-preparation decision and may happen later. The policy also permits a separately approved expedited security exception; the captured roots notice and registry do not establish that such an exception applies here. SDK removal follows each SDK's own revision-support policy, so this date is not a verified client or SDK deadline.[2]

Keeping the feature does not keep its old message flow. The 2025-11-25 page declares roots during initialization and describes notifications/roots/list_changed.[7] The 2026-07-28 changelog separately removes that notification and changes how a server asks the client for information.[9] In the pinned roots page, the client advertises roots support on each request: the roots capability sits under the io.modelcontextprotocol/clientCapabilities key in _meta. When the server needs the roots list, it returns a roots/list request inside InputRequiredResult.inputRequests; the client supplies inputResponses when retrying the original request.[1] Check the version before implementing either flow.

Inventory the actual client, server, SDK and protocol revision before choosing a compatibility plan. The SEP's statement that deprecation itself makes no wire-level changes must not be expanded into a claim that the entire 2026-07-28 revision has no wire changes.[6][9] Continued specification presence does not establish which behavior a particular installed product supports.

Compare scope interfaces without assigning them security powers

The practical distinction is who controls the value and where policy is applied. For a variable per-call path, a trusted server policy can bound the requested location. For a fixed documentation service, administrator-controlled configuration can avoid making the allowed area itself a model-selected input. Configuration is still only data until code or runtime controls enforce it. The same review is needed when a resource URI maps to a file or another backing store.

In the pinned roots definition, Root.uri MUST be a file:// URI, an identifier for a file or directory.[1] That requirement does not establish a universal URI scheme or field name for replacement interfaces. Choose the supported interface of the actual implementation; do not invent a standardized directory parameter. For a remote server, establish the remote identity, storage and authorization policy. A local project picker does not demonstrate confinement of a remote filesystem.

Match the enforcement component to the threat

The roots security section assigns clients MUST obligations, including appropriate permissions, URI validation and access controls, while servers SHOULD respect root boundaries and validate paths.[1] Those words matter, but neither a normative obligation nor a recommendation is evidence that a deployed implementation meets it. Client access controls should not be read as a protocol-level guarantee over every file operation performed by a server process.

For a cooperative server, implementation-specific path authorization may be an effective control. The review question is whether the actual operation resolves its target and checks it against trusted policy, consistently across the relevant tools and read/write modes. Review traversal, URI decoding, links, alternate operations and reconfiguration behavior as applicable. These are implementation review questions, not newly asserted MCP MUST requirements or vulnerabilities found in a named product. A simple textual path-prefix comparison is not a complete authorization design.

For a malicious or compromised local server, its own tool-level validator is not a sufficient boundary against code that can bypass it and use the process's remaining privileges. The relevant question becomes what the operating system or runtime permits that process and its children to access. The official security guidance notes that local MCP servers may have direct system access and recommends sandboxing, minimal privileges, and restricted filesystem and network access.[4] A container or sandbox label is not evidence of the effective mounts, credentials or permissions.

This leaves a credible alternative to always requiring a container: a narrowly trusted server with effective, tested path authorization may meet a bounded workload's threat model. It does not thereby solve compromised-process exposure. Conversely, a read-only project mount can restrict writes to that mount without proving that unrelated paths are unreadable or network disclosure is blocked. Decide which threats must be covered and verify the actual controls for them; do not compare deployment labels as if they were measured security outcomes.

A procedure for preserving the boundary

• 1. Establish the baseline. Record the installed client, server and SDK versions, the protocol revision in use, who consumes the roots list, and any existing path checks or runtime restrictions. Separate documented behavior from behavior actually observed in that environment.
• 2. State the allowed work and the threat. Name the files and operations that are needed, what must be denied, and whether the boundary must withstand a compromised server process as well as mistaken tool requests.
• 3. Select the replacement interface. Choose a supported tool parameter, resource URI or server configuration. Identify which values the caller can change and which trusted policy caps the allowed scope. Do not remove an existing validator merely because its input used to arrive through roots.
• 4. Locate each enforcement point. Follow a request through target resolution and authorization to the actual file access. Check relevant alternate tools, child processes and policy-change behavior. For remote execution, inspect the remote service's identity and storage policy rather than assuming local restrictions apply.
• 5. Obtain controlled evidence before sensitive use. In a separately authorized, disposable environment with synthetic files, check an intended allowed read and an out-of-scope denial under the proposed version and configuration. Include prohibited writes for a read-only workload and applicable link/traversal cases. Capture the rejecting component and effective permissions; an error caused by a missing file is not evidence of policy enforcement.
• 6. Make the rollout decision. Compare the new boundary with the baseline and the stated threat model. If denial evidence, required compatibility or effective permissions remain unresolved, hold sensitive rollout and keep the existing known controls. Repeat affected checks when versions, configuration or execution identity change.

This is a proposed evaluation procedure, not a test suite executed for this article or permission to probe a production system. A positive read matters alongside a denial: a server that rejects every request has not demonstrated a usable migration. A passed bounded check would support only its recorded configuration and cases, not universal filesystem confinement.

Worked decision: a documentation summarizer

Hypothetical example — not run. A team wants a local agent to summarize files under /work/atlas/docs. Its old client returned file:///work/atlas/docs in a roots list, and the team treated that selection as a machine-wide restriction. It proposes replacing the list with administrator-controlled server configuration for the same directory. These paths and configuration choices are fictional planning inputs, not a product's standard schema or an observed deployment.

For the planned controlled check, /work/atlas/docs/intro.txt is the synthetic allowed target and /work/atlas/private/fixture.txt is a synthetic outside target. Success would mean the permitted read works while the outside read is rejected by the intended policy, not merely because the file was absent. Prohibited writes need their own evidence. Those are acceptance conditions, not actual observations: no fixtures were created and no commands were run here.

The next step is to identify the exact server version, locate its file-access check and inspect its effective runtime restrictions before conducting the controlled checks. The team can continue designing the configuration change, but it should not connect sensitive host files on the strength of that design. If it instead accepts a cooperative-server-only threat model, it must document the narrower protection rather than treat it as equivalent to a boundary that withstands server compromise.

What would change the recommendation?

For a particular implementation, version-specific code or authoritative documentation locating the actual access check, together with controlled allowed/denied evidence and effective runtime permissions, could support proceeding under a defined threat model. Evidence that only a root picker or renamed path field changed would not. If an existing server already enforces the required policy, preserve and verify that mechanism through migration instead of replacing it solely to obtain a different deployment label.

The official sources here establish protocol meaning, a migration direction and lifecycle rules. They are complementary records from one project, not independent security experiments. We did not measure enforcement, inspect an installed client or SDK, establish adoption, or test an exploit. The defensible conclusion is narrower: deprecating roots changes how scope should be conveyed; whether a migration preserves access restrictions depends on the implementation and the evidence for its actual boundary.