A client exposes one root, file:///home/dev/project, to a filesystem server and assumes the server therefore cannot touch any files outside that folder. What should a reviewer tell the team?
Select an answer to reveal the explanation.
Short Explanation
A root is a sticky note that says "please work here," not a locked door. The server can still wander anywhere its process can reach. If you need a real fence, you build it with a sandbox, and since roots are deprecated you pass paths another way.
Full Explanation
The roots specification describes roots as informational guidance rather than an access-control mechanism and states that the protocol does not enforce that servers stay within them. A local server runs with whatever privileges its process has, so a real boundary must come from sandboxing, containers or host policy. Revision 2026-07-28 also deprecates Roots; existing implementations should migrate to passing directories or files through tool parameters, resource URIs or server configuration. Claiming the protocol enforces roots fails directly against that statement; a well-behaved server should respect them, but nothing stops one that does not. Claiming readOnlyHint turns roots into enforcement fails by concept: tool annotations are hints supplied by the server, untrusted unless the server is trusted, and they describe tool behaviour rather than file boundaries. Claiming roots bind once echoed in requestState fails because requestState is opaque server state that clients must not inspect or modify, so the client cannot check it. Exam caveat: the client-side rules still apply while the feature lives; clients must only expose roots with appropriate permissions and validate root URIs against path traversal. Operational check: run the server in a sandbox limited to the project folder and confirm a read outside it fails at the operating-system level.