FazBrowse GitHub Viewer | Trending |
URL:
| Home
Tools: [Download Repo ZIP]   [Original HTTPS Page]

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

/ modelcontextprotocol Public

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

Closed
chughtapan wants to merge 1 commit into
modelcontextprotocol:mainfrom
chughtapan:non_file_roots_sep_branch
ConversationCommits (1)ChecksFiles changed
Closed

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

Conversation

chughtapan commented Feb 4, 2026

Copy link
Copy Markdown
Contributor

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

🤖 Generated with Claude Code

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
Closed
Add SEP-2202: Allow Non-File URI Schemes for Roots
f230270 
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>
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
olaservo added the draft SEP proposal with a sponsor. label Feb 4, 2026
PederHP reviewed Feb 4, 2026
View reviewed changes
Comment thread docs/community/seps/2202-non-file-uri-roots.mdx

## 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.

PederHP Feb 4, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality

"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 reviewed Feb 4, 2026
View reviewed changes
Comment thread docs/community/seps/2202-non-file-uri-roots.mdx

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

PederHP Feb 4, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality

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

chughtapan Feb 4, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality

💯 - will add

PederHP reviewed Feb 4, 2026
View reviewed changes
Comment thread docs/community/seps/2202-non-file-uri-roots.mdx
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.

PederHP Feb 4, 2026 •
edited
Loading

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality

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 reviewed Feb 4, 2026
View reviewed changes
Comment thread docs/community/seps/2202-non-file-uri-roots.mdx

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.

PederHP Feb 4, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality

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 Bot commented Feb 23, 2026

Copy link
Copy Markdown

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 Bot commented Mar 16, 2026

Copy link
Copy Markdown

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 Bot commented Mar 30, 2026

Copy link
Copy Markdown

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.

1 similar comment

sep-automation-bot Bot commented Apr 13, 2026

Copy link
Copy Markdown

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 commented Apr 20, 2026

Copy link
Copy Markdown
Member

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:

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

Proposal

I'd like to officially pause this SEP until:

  1. The deprecation proposal matures and gets more community feedback (I'm expecting this to bring any Roots enthusiasts out of the woodwork).
  2. 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 Bot commented May 11, 2026

Copy link
Copy Markdown

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 commented May 15, 2026

Copy link
Copy Markdown
Contributor Author

roots are deprecated in #2577

chughtapan closed this May 15, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
Show hidden characters
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

PederHP PederHP left review comments

Assignees

olaservo

Labels

draft SEP proposal with a sponsor. SEP

Projects

SEP Review Pipeline
Status: No status

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

3 participants

Back | FazBrowse Home | New Git URL