Roots

## The misconception this question exists to catch Ask an engineer what roots do and a common answer is "they limit the server to those folders". They do not, and the gap between how the feature reads and what it does is exactly why interviewers ask about it. ## What MCP is, structurally MCP is a JSON-RPC protocol carried over stdio or Streamable HTTP. Its vocabulary is requests, results, notifications and errors. When a client hands a server a list of roots, what physically happens is that a JSON array of `file://` strings crosses a pipe or an HTTP body. The server receives some strings. The server is a separate program. On stdio it is a subprocess the host launched; on HTTP it is a service somewhere else entirely. When that program opens a file it makes a system call to its own kernel. There is no point in that path where the MCP client sits, and no place where a protocol message could veto it. A client cannot revoke a file descriptor a server already holds and cannot inspect what the server reads. So the only thing roots can be is a request: *please work here*. ## Advisory in the specification's own terms The specification describes servers as expected to respect roots — a should, aimed at cooperative implementations. That is a useful contract between honest parties: a search server told the project directory indexes the project directory, which is faster and less surprising than scanning a home folder. It is not a contract that survives contact with a server you do not trust, because it is enforced by the server's own good behaviour. A useful way to phrase it in an interview: roots are a *hint from the client to the server*, in the same family as `ToolAnnotations` being hints from the server to the client. Both are declarations by one party about intent. Neither is checked by the protocol, and MCP is explicit that annotations must be treated as untrusted unless the server itself is trusted. Roots are the mirror image of that asymmetry. ## Where confinement actually lives If the requirement is "this server must not read anything outside the project", the answer is never roots. It is one of: - Process isolation — run the stdio server as a dedicated OS user with read access only to the intended tree, or in a container with only that tree mounted. - Filesystem namespacing or sandbox profiles — the kernel refuses paths outside the mount, regardless of what the server code attempts. - Not running the server locally at all — a remote server behind OAuth 2.1 authorization gets exactly the data the token's audience and scopes permit, and the boundary is the resource server's own checks. All three share a property roots lack: they are enforced by something other than the code being constrained. ## Consent sits with the host, not with roots MCP's security model puts enforcement in the host application: User Consent and Control, Data Privacy, Tool Safety. The host decides which servers run, which tool calls proceed, and what the user is shown before data leaves. Roots never carried any of that weight. Sending a root is not asking the user's permission for anything and does not record a decision; it just tells the server where the interesting files are. ## Why this fed into the deprecation Revision 2026-07-28 deprecates roots (SEP-2577) and points implementers at explicit tool parameters, resource URIs, or server configuration. Part of the argument is exactly the confusion described here. A path passed as a tool argument is visible in the tool call the user approves; it is obviously data, and nobody mistakes an argument for a sandbox. A separate protocol channel that hands a server "the directories it should stay in" invites the wrong mental model. Deprecated does not mean removed — the feature stands for at least twelve months, so the earliest removal is a revision on or after 2027-07-28 — but new servers should not adopt it. ## Answering well Say the guarantee out loud: none. Then explain structurally why — the protocol cannot mediate a separate process's filesystem calls — and name where real isolation comes from. Candidates who say "roots restrict the server" have revealed they have never had to reason about an untrusted server.