SEP-2202: Allow Non-File URI Schemes for Roots by chughtapan · Pull Request #2202 · modelcontextprotocol/modelcontextprotocol

chughtapan · 2026-02-04T01:43:55Z

Summary

This PR transfers SEP-1573 to the new PR-based SEP workflow per SEP-1850.

This SEP proposes removing the restriction that root URIs must begin with file://, allowing servers to work with remote resources through any URI scheme.

Motivation

Enable cloud storage boundaries (S3, Azure blob containers)
Support version control repository scoping
Allow database schema boundaries
Maintain consistency with resources which already support any URI scheme

Reference Implementation

Python SDK: SEP: Allow non-file URI schemes for Roots python-sdk#1390
Typescript SDK: SEP: Allow non-file URI schemes for Roots typescript-sdk#997
Client (fast-agent): WIP: Implement support for non-file roots chughtapan/fast-agent#3

🤖 Generated with Claude Code

Transfers SEP-1573 to the new PR-based SEP workflow per SEP-1850. This SEP proposes removing the restriction that root URIs must begin with file://, allowing servers to work with remote resources through any URI scheme. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

PederHP · 2026-02-04T08:18:55Z

+
+## Abstract
+
+This SEP proposes removing the restriction that root URIs must begin with `file://`, allowing servers to work with remote resources through any URI scheme. Reference implementations in `python-sdk`, `typescript-sdk`, client (`fast-agent`) a helper for enforcement are provided.


"Remote resources" could be "client and remote resources"? Using roots as a way to communicate what local resources are within limits is still a very useful (and underutilized) application of the capability.

PederHP · 2026-02-04T08:20:12Z

+
+Creating separate mechanisms for local and remote servers does not provide any clear benefits and fragments the ecosystem. The simple approach of allowing any URI maintains complete backward compatibility. Existing clients continue sending file:// roots unchanged, existing servers continue accepting them, and the ecosystem can gradually adopt support for additional schemes as needed
+
+### Future Work


I think adding scope (like read, write) to roots as future work would be incredibly useful.

💯 - will add

PederHP · 2026-02-04T08:22:47Z

+We discussed proposing programmatic discovery mechanisms for which schemes a server supports, but decided to keep this change simple by removing the file restriction. The lack of programmatic discovery follows MCP's existing patterns and shouldn't limit practical usefulness because:
+
+1. Servers will naturally document what they support, clients will implement common patterns, and the ecosystem will converge on standards, just like with resource URIs.
+2. When a client provides an unsupported root, the server returns a clear error. In this case clients can gracefully degrade or prompt users to adjust roots.


I don't think the server should return an error. It is a reasonable pattern for the client to just broadcast roots - it is not an error to have a root that a server doesn't support, and it adds complexity if there needs to be a negotiation of back and forth to establish a set of supported roots for each server. The SEP also doesn't describe how this would happen. If roots are to be adjustable this would require further changes, I believe?

(I agree that the lack of programmatic discovery is not a problem)

PederHP · 2026-02-04T08:52:09Z

+
+The specification should include guidance that
+
+1. Servers must document their supported URI schemes and validate them. Clients may provide roots with any URI scheme, and servers must gracefully handle unsupported schemes by returning clear error messages rather than failing silently.


Protocol level errors? That seems harsh for this. When would this be needed and how are client supposed to handle and act on error messages?

sep-automation-bot · 2026-02-23T09:21:49Z

Maintainer Activity Check

Hi @olaservo!

You're assigned to this SEP but there hasn't been any activity from you in 19 days.

Please provide an update on:

Current status of your review/work
Any blockers or concerns
Expected timeline for next steps

If you're no longer able to sponsor this SEP, please let us know so we can find another maintainer.

This is an automated message from the SEP lifecycle bot.

sep-automation-bot · 2026-03-16T09:26:46Z

Maintainer Activity Check

Hi @olaservo!

You're assigned to this SEP but there hasn't been any activity from you in 21 days.

Please provide an update on:

Current status of your review/work
Any blockers or concerns
Expected timeline for next steps

If you're no longer able to sponsor this SEP, please let us know so we can find another maintainer.

This is an automated message from the SEP lifecycle bot.

sep-automation-bot · 2026-03-30T09:34:10Z

Maintainer Activity Check

Hi @olaservo!

You're assigned to this SEP but there hasn't been any activity from you in 14 days.

Please provide an update on:

Current status of your review/work
Any blockers or concerns
Expected timeline for next steps

If you're no longer able to sponsor this SEP, please let us know so we can find another maintainer.

This is an automated message from the SEP lifecycle bot.

sep-automation-bot · 2026-04-13T09:38:27Z

Maintainer Activity Check

Hi @olaservo!

You're assigned to this SEP but there hasn't been any activity from you in 14 days.

Please provide an update on:

Current status of your review/work
Any blockers or concerns
Expected timeline for next steps

If you're no longer able to sponsor this SEP, please let us know so we can find another maintainer.

This is an automated message from the SEP lifecycle bot.

olaservo · 2026-04-20T18:22:40Z

Sharing a few overdue thoughts and updates as the sponsor of this SEP:

Where things are at

After chatting with Tapan a while back, I did a bunch of tinkering on non-file:// Roots using the GitHub MCP server as a concrete example. One use case we were exploring was Roots could communicate intended boundaries around a GitHub org (especially relevant for enterprise GH) or the specific repo(s) in scope for a given host connected to the server.

The idea was that this would:

Make scope more explicit to both the host and the server, and
Reduce the chances of the agent hallucinating the wrong value when populating org/repo parameters (which still happens fairly often, even with advanced harnesses and models).

The prototype did the job, but a couple of things have pushed this into the background:

To make this genuinely usable, we'd need to solve the race condition problem in the spec.
Demand for something like Roots seems limited compared to more standard scoping mechanisms (e.g. auth-based approaches, which would provide more enforced boundaries).
Roots is reportedly on a proposed deprecation path.

Proposal

I'd like to officially pause this SEP until:

The deprecation proposal matures and gets more community feedback (I'm expecting this to bring any Roots enthusiasts out of the woodwork).
The larger transport-related shakeups get more finalized, so we can revisit the mechanism and where it should live (if we still think it should exist).

Thoughts welcome from anyone following along. cc @chughtapan @SamMorrowDrums

sep-automation-bot · 2026-05-11T10:17:39Z

Maintainer Activity Check

Hi @olaservo!

You're assigned to this SEP but there hasn't been any activity from you in 20 days.

Please provide an update on:

Current status of your review/work
Any blockers or concerns
Expected timeline for next steps

If you're no longer able to sponsor this SEP, please let us know so we can find another maintainer.

This is an automated message from the SEP lifecycle bot.

chughtapan · 2026-05-15T22:01:13Z

roots are deprecated in #2577

chughtapan force-pushed the non_file_roots_sep_branch branch from fd095f3 to 4bb9808 Compare February 4, 2026 01:44

chughtapan requested a review from a team as a code owner February 4, 2026 01:44

chughtapan force-pushed the non_file_roots_sep_branch branch from 4bb9808 to b2516f5 Compare February 4, 2026 01:45

chughtapan mentioned this pull request Feb 4, 2026

SEP-1573: Allow Non-File URI Schemes for Roots #1573

Closed

chughtapan force-pushed the non_file_roots_sep_branch branch from b2516f5 to f230270 Compare February 4, 2026 01:53

chughtapan changed the title ~~SEP: Allow Non-File URI Schemes for Roots~~ SEP-2202: Allow Non-File URI Schemes for Roots Feb 4, 2026

olaservo self-assigned this Feb 4, 2026

olaservo added the SEP label Feb 4, 2026

github-project-automation Bot added this to SEP Review Pipeline Feb 4, 2026

olaservo added the draft SEP proposal with a sponsor. label Feb 4, 2026

PederHP reviewed Feb 4, 2026

View reviewed changes

chughtapan closed this May 15, 2026

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

SEP-2202: Allow Non-File URI Schemes for Roots#2202

SEP-2202: Allow Non-File URI Schemes for Roots#2202
chughtapan wants to merge 1 commit into
modelcontextprotocol:mainfrom
chughtapan:non_file_roots_sep_branch

chughtapan commented Feb 4, 2026

Uh oh!

PederHP Feb 4, 2026

Uh oh!

PederHP Feb 4, 2026

Uh oh!

chughtapan Feb 4, 2026

Uh oh!

PederHP Feb 4, 2026 •

edited

Loading

Uh oh!

PederHP Feb 4, 2026

Uh oh!

sep-automation-bot Bot commented Feb 23, 2026

Uh oh!

sep-automation-bot Bot commented Mar 16, 2026

Uh oh!

sep-automation-bot Bot commented Mar 30, 2026

Uh oh!

sep-automation-bot Bot commented Apr 13, 2026

Uh oh!

olaservo commented Apr 20, 2026

Uh oh!

sep-automation-bot Bot commented May 11, 2026

Uh oh!

chughtapan commented May 15, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants


		## Abstract

		This SEP proposes removing the restriction that root URIs must begin with `file://`, allowing servers to work with remote resources through any URI scheme. Reference implementations in `python-sdk`, `typescript-sdk`, client (`fast-agent`) a helper for enforcement are provided.


		Creating separate mechanisms for local and remote servers does not provide any clear benefits and fragments the ecosystem. The simple approach of allowing any URI maintains complete backward compatibility. Existing clients continue sending file:// roots unchanged, existing servers continue accepting them, and the ecosystem can gradually adopt support for additional schemes as needed

		### Future Work


		The specification should include guidance that

		1. Servers must document their supported URI schemes and validate them. Clients may provide roots with any URI scheme, and servers must gracefully handle unsupported schemes by returning clear error messages rather than failing silently.

Conversation

chughtapan commented Feb 4, 2026

Summary

Motivation

Reference Implementation

Uh oh!

PederHP Feb 4, 2026

Choose a reason for hiding this comment

Uh oh!

PederHP Feb 4, 2026

Choose a reason for hiding this comment

Uh oh!

chughtapan Feb 4, 2026

Choose a reason for hiding this comment

Uh oh!

PederHP Feb 4, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

PederHP Feb 4, 2026

Choose a reason for hiding this comment

Uh oh!

sep-automation-bot Bot commented Feb 23, 2026

Maintainer Activity Check

Uh oh!

sep-automation-bot Bot commented Mar 16, 2026

Maintainer Activity Check

Uh oh!

sep-automation-bot Bot commented Mar 30, 2026

Maintainer Activity Check

Uh oh!

sep-automation-bot Bot commented Apr 13, 2026

Maintainer Activity Check

Uh oh!

olaservo commented Apr 20, 2026

Where things are at

Proposal

Uh oh!

sep-automation-bot Bot commented May 11, 2026

Maintainer Activity Check

Uh oh!

chughtapan commented May 15, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

PederHP Feb 4, 2026 •

edited

Loading