Should Client "roots" be considered as implementation details instead of specification?

[rodrigopavan]

Pre-submission Checklist

• I have checked that this question would not be more appropriate as an issue in a specific repository
• I have searched existing discussions and documentation for answers

Question Category

• Protocol Specification
• SDK Usage
• Server Implementation
• General Implementation
• Documentation
• Other

Your Question

I've been looking into the client specification and saw this roots concept. I think that client could be anything that consumes MCP servers, so it's not necessarily a GUI application or something that runs on the end-user machine. I'm thinking if the "roots" aren't just part of "tools" that a client can have access to.

[dsp-ant]

I think roots can inherently affect every primitive, hence they are separate concept. The idea here is that IDE's advertise roots abilities, where as other clients don't advertise roots and don't use them. These is very much intended for local apps and particularly IDEs, but it's optionally

[rodrigopavan]

These is very much intended for local apps and particularly IDEs

This is my main concern: Shouldn't we design a specification that's agnostic to its client's implementations? Having a spec that's specifically for 'local apps' or IDEs sounds like breaking the abstraction paradigm. WDYT?