The Model Context Protocol (MCP) provides a standardized way for clients to expose filesystem “roots” to servers. Roots define the boundaries of where servers can operate within the filesystem, allowing them to understand which directories and files they have access to. Servers can request the list of roots from supporting clients and receive notifications when that list changes.
Roots in MCP are typically exposed through workspace or project configuration interfaces.
For example, implementations could offer a workspace/project picker that allows users to select directories and files the server should have access to. This can be combined with automatic workspace detection from version control systems or project files.
However, implementations are free to expose roots through any interface pattern that suits their needs—the protocol itself does not mandate any specific user interaction model.
Clients that support roots MUST declare the roots
capability during
initialization:
listChanged
indicates whether the client will emit notifications when the list of roots
changes.
To retrieve roots, servers send a roots/list
request:
Request:
Response:
When roots change, clients that support listChanged
MUST send a notification:
A root definition includes:
uri
: Unique identifier for the root. This MUST be a file://
URI in the current
specification.name
: Optional human-readable name for display purposes.Example roots for different use cases:
Clients SHOULD return standard JSON-RPC errors for common failure cases:
-32601
(Method not found)-32603
Example error:
Clients MUST:
Servers SHOULD:
Clients SHOULD:
Servers SHOULD:
The Model Context Protocol (MCP) provides a standardized way for clients to expose filesystem “roots” to servers. Roots define the boundaries of where servers can operate within the filesystem, allowing them to understand which directories and files they have access to. Servers can request the list of roots from supporting clients and receive notifications when that list changes.
Roots in MCP are typically exposed through workspace or project configuration interfaces.
For example, implementations could offer a workspace/project picker that allows users to select directories and files the server should have access to. This can be combined with automatic workspace detection from version control systems or project files.
However, implementations are free to expose roots through any interface pattern that suits their needs—the protocol itself does not mandate any specific user interaction model.
Clients that support roots MUST declare the roots
capability during
initialization:
listChanged
indicates whether the client will emit notifications when the list of roots
changes.
To retrieve roots, servers send a roots/list
request:
Request:
Response:
When roots change, clients that support listChanged
MUST send a notification:
A root definition includes:
uri
: Unique identifier for the root. This MUST be a file://
URI in the current
specification.name
: Optional human-readable name for display purposes.Example roots for different use cases:
Clients SHOULD return standard JSON-RPC errors for common failure cases:
-32601
(Method not found)-32603
Example error:
Clients MUST:
Servers SHOULD:
Clients SHOULD:
Servers SHOULD: