What are MCP Roots?

Roots give a server a declared working scope — typically the user's current project or workspace. Clients that support them MUST declare the roots capability during initialisation, with listChanged indicating whether the client will emit change notifications. The server then sends a roots/list request and receives a list of root objects, each with a uri (which must be a file:// URI in the current spec) and an optional human-readable name.

Clients commonly populate roots from a workspace or project picker, or detect them automatically from version control. When the user switches projects, the client sends notifications/roots/list_changed and the server re-queries.

The crucial caveat: roots are advisory, not enforcement. The spec says servers SHOULD respect root boundaries and validate paths against the provided roots — but nothing in the protocol prevents a misbehaving or malicious server from reading paths outside them. The spec's security guidance puts obligations on both sides: clients must only expose roots with appropriate permissions, validate root URIs against path traversal, and prompt users for consent before exposing roots; servers should check for the capability, handle roots becoming unavailable, and respect the boundaries in every operation.

Roots are therefore best understood as a scoping contract that well-behaved servers honour, to be combined with real controls — sandboxing, least privilege, and policy enforcement — rather than relied on alone.

PolicyLayer treats declared scope and enforced scope as different things. The catalogue's per-tool risk classification at policylayer.com/tools flags filesystem-capable tools regardless of what roots a client might declare, and gateway policies can deny or log tool calls whose arguments reach outside an approved scope — deterministic enforcement rather than a convention the server is trusted to follow.