Roots - Model Context Protocol Documentation Index Fetch the complete documentation index at: /llms.txt Use this file to discover all available pages before exploring further. Skip to main content Model Context Protocol home page Draft Search... ⌘ K Ask Assistant ⌘ I * Blog * GitHub Search... Navigation Client Features Roots Documentation Specification Extensions Registry SEPs Community * Specification * Changelog * Deprecated Features * Architecture Base Protocol * Overview * Versioning and Compatibility * Message Patterns * Transports * Authorization Client Features * Roots * Sampling * Elicitation Server Features * Overview * Discovery * Prompts * Resources * Tools * Utilities * Schema Reference On this page * User Interaction Model * Capabilities * Protocol Messages * Listing Roots * Message Flow * Data Types * Root * Project Directory * Multiple Repositories * Error Handling * Security Considerations * Implementation Guidelines Client Features Roots Copy page Copy page Copy page Copy page Deprecated : The Roots feature is deprecated as of protocol version 2026-07-28 ( SEP-2577 ). Under the feature lifecycle policy , it remains in the specification for at least twelve months after this revision’s release before it becomes eligible for removal. New implementations SHOULD NOT adopt it; existing implementations SHOULD migrate to passing directories or files via tool parameters, resource URIs, or server configuration. See the deprecated features registry . The Model Context Protocol (MCP) provides a standardized way for clients to expose filesystem “roots” to servers. Roots inform servers about the directories and files the client considers relevant, so that servers can focus their operations accordingly. They are informational guidance rather than an access-control mechanism. The protocol does not enforce that servers stay within roots. Servers can request the list of roots from supporting clients. ​ User Interaction Model 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. ​ Capabilities Clients that support roots MUST declare the roots capability in _meta.io.modelcontextprotocol/clientCapabilities on each request: { "_meta" : { "io.modelcontextprotocol/clientCapabilities" : { "roots" : {} } } } ​ Protocol Messages ​ Listing Roots To retrieve roots during the processing of a client request, servers send an InputRequiredResult containing a roots/list request: Input request (delivered inside InputRequiredResult.inputRequests ): { "method" : "roots/list" } Client result (returned inside inputResponses on the retried request): { "roots" : [ { "uri" : "file:///home/user/projects/myproject" , "name" : "My Project" } ] } ​ Message Flow ​ Data Types ​ Root 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: ​ Project Directory { "uri" : "file:///home/user/projects/myproject" , "name" : "My Project" } ​ Multiple Repositories [ { "uri" : "file:///home/user/repos/frontend" , "name" : "Frontend Repository" }, { "uri" : "file:///home/user/repos/backend" , "name" : "Backend Repository" } ] ​ Error Handling If an error occurs, the client does not need to replay the initial call with an error message as the server is not waiting for a response with the InputRequiredResult pattern. ​ Security Considerations * Clients MUST : * Only expose roots with appropriate permissions * Validate all root URIs to prevent path traversal * Implement proper access controls * Monitor root accessibility * Servers SHOULD : * Handle cases where roots become unavailable * Respect root boundaries during operations * Validate all paths against provided roots ​ Implementation Guidelines * Clients SHOULD : * Prompt users for consent before exposing roots to servers * Provide clear user interfaces for root management * Validate root accessibility before exposing * Monitor for root changes * Servers SHOULD : * Check for roots capability before usage * Respect root boundaries in operations * Cache root information appropriately Was this page helpful? Yes No Security Considerations Sampling github Assistant Responses are generated using AI and may contain mistakes.