Unpacking Hidden MCP Gems: Roots

Angus Bezzina

•

As developers and systems grow more modular, the importance of clear boundaries and scoped operations increases. In the world of MCP, one of the most elegant yet under appreciated features that help define these boundaries are roots.

Whether you’re building tools, integrating APIs, or orchestrating file-based automation, roots act like the compass that tells your server what to pay attention to, and just as importantly, what to ignore.

What Are MCP Roots?

At its core, a root is a URI that a client suggests the server should consider as relevant. Think of it as a starting point or anchor for context: a directory, a repo, a remote API endpoint - any location that defines where the action is.

For example:

file:///home/user/projects/myapp
https://api.example.com/v1

Roots tell the server: “Hey, here’s where my stuff lives—this is where I need you to work.”

Why Do Roots Matter?

Let’s break down the practical value:

• Guidance: Roots act as hints, helping servers prioritize relevant data and actions.
• Clarity: They define what belongs to your current workspace or context.
• Separation of Concerns: You can operate on multiple independent roots (e.g., a frontend repo and an API) without them interfering with each other.
• Safety: Servers can avoid scanning or acting on unintended parts of the filesystem or network.

In short, they’re a non-intrusive way to tell servers where to look—without restricting them if needed flexibility is required.

Under the Hood: How Roots Work

When a client initiates an MCP connection and wants to use roots, it follows a three-step handshake:

1. Declare Capability: The client indicates it supports the roots capability during the connection.
2. Provide Roots: The client sends a list of suggested roots to the server.
3. Track Changes (Optional): If the client supports it, it notifies the server when roots are updated.

On the server side:

• Servers aren’t forced to use roots but are expected to respect and prioritize them.
• Operations like file indexing, resource lookup, or analysis should be scoped to roots when appropriate.

Real-World Use Cases

Roots shine in all kinds of environments:

• Local Development: Limit server operations to your current project directory.
• API Integration: Point servers to specific remote endpoints (e.g., versioned API roots).
• Configuration Context: Keep config directories or resource folders explicitly scoped.
• Multi-Project Workspaces: Operate on frontend/backend codebases in parallel without overlap.

Example in Action

Here’s what a root-aware client might declare:

{
  "roots": [
    {
      "uri": "file:///home/user/projects/frontend",
      "name": "Frontend Repository"
    },
    {
      "uri": "https://api.example.com/v1",
      "name": "API Endpoint"
    }
  ]
}

With this config, the server understands to treat both the local frontend folder and the remote API as distinct, important scopes.

Best Practices for Using Roots

To get the most out of roots:

• Be Selective: Only suggest roots that are actually needed.
• Use Descriptive Names: Names like “API Endpoint” or “Main Project” help with debugging and UI clarity.
• Check Availability: Ensure root URIs are accessible and valid.
• Gracefully Handle Changes: If your tool supports dynamic root updates, respond to them without crashing or misbehaving.

Looking Ahead

As MCP continues to evolve, roots offer a foundational pattern for contextual precision; something increasingly important as systems grow in complexity and scope. Whether you’re integrating filesystem servers, API connectors, or project-specific workflows, roots help ensure everything stays in its lane.