SEP-2202: Allow Non-File URI Schemes for Roots#2202
SEP-2202: Allow Non-File URI Schemes for Roots#2202chughtapan wants to merge 1 commit intomodelcontextprotocol:mainfrom
Conversation
chughtapan
force-pushed
the
non_file_roots_sep_branch
branch
from
fd095f3 to
4bb9808
Compare
chughtapan
force-pushed
the
non_file_roots_sep_branch
branch
from
4bb9808 to
b2516f5
Compare
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
chughtapan
changed the title
|
|
||
| ## 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. |
There was a problem hiding this comment.
"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.
|
|
||
| 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 |
There was a problem hiding this comment.
I think adding scope (like read, write) to roots as future work would be incredibly useful.
| 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. |
There was a problem hiding this comment.
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)
|
|
||
| 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. |
There was a problem hiding this comment.
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?
3 participants
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
Reference Implementation
🤖 Generated with Claude Code