MCP Roots are the boundary mechanism that tells an MCP server which file system paths or URIs the client allows it to operate inside. When a host like Cursor connects a filesystem MCP server, it advertises a root pointing at the user’s current project folder. The server then knows it should not read or write files outside that root. Roots are a client-declared scope, not a server-enforced lock. The server can technically ignore them, which makes roots an honor-system boundary unless the host backs them up with OS-level isolation. Treating roots as a real security control without sandboxing is one of the most common MCP misconfigurations in production.
How MCP Roots Work
During the initialize handshake, the client declares its roots capability. After initialization, the client sends a roots/list response when asked, returning an array of URIs like file:///home/user/project. Whenever the user changes context (opens a different project, switches workspaces), the client sends a notifications/roots/list_changed message. The server is expected to respect the new roots. There is no protocol-level enforcement. The server’s compliance depends on its implementation and the trust model of its developer.
Certified MCP Security Expert
Attack, defend, and pen test MCP servers in 30+ hands-on labs. Get certified.
Why MCP Roots Need Sandbox Backing
Because roots are advisory, a malicious or buggy server can simply read files outside the declared root. The host’s only real enforcement layer is OS-level: file system permissions, container mounts, or bind mounts that physically prevent access. Combine roots with a Docker container that mounts only the project directory, and now the boundary holds. Use roots alone with a server running at full user privilege, and the boundary is fiction. The 2026 OWASP MCP Security Cheat Sheet calls this out explicitly.
How to Use Roots Correctly
Always pair roots declarations with OS-level isolation. Run filesystem MCP servers in containers with selective bind mounts. Reject server responses that reference paths outside declared roots. Audit server source code for root respect, especially community-contributed servers. Treat roots as a hint to the LLM, not a security perimeter. The Certified MCP Security Expert (CMCPSE) course covers root enforcement patterns with practical container-based labs.
Summary
MCP Roots are client-declared scope boundaries that tell servers which paths or URIs to stay inside. They are not security controls on their own, only hints. Pair them with OS-level isolation or skip them entirely. The Certified MCP Security Expert (CMCPSE) certification teaches engineers to combine roots with sandboxing for boundaries that actually hold.