Recommend clients expose resource read to models#2527
Conversation
Adds SHOULD guidance that clients provide a mechanism (e.g., a tool) for the language model to read resources by URI, with optional listing, so models can pull resource context directly rather than relying solely on application-driven inclusion.
|
Preview deployment for your docs. Learn more about Mintlify Previews.
|
SamMorrowDrums
left a comment
There was a problem hiding this comment.
So excited, I really hope this gets approved.
One note though, semantically this probably would need to be considered same as open world hint, if there's no resource annotations.
I thought model loading would be the case from day 1, and to be honest I also thought that models would be easily able to complete resource templates also. For GitHub that could have meant access to any file at any revision of any repo without the need for a get file tool.
The annotations/open world risk should definitely be considered though. Definitely could be a prompt injection risk to allow it to be arbitrary without any mechanism for annotations, or guidance for how clients should handle response.
|
Looking closer at this proposal from a security perspective (and somewhat echoing @SamMorrowDrums), I am more worried about this giving unbounded What if the returned URI is We might need to call out that model-initiated resource reads carry the same trust and safety considerations as tool invocations - that is, we need to make sure that we treat model-facing resource reads we open-world by default unless there is some kind of scoping guarantee. |
Mirrors the client SHOULD guidance from the tools security section so that model-initiated resource reads carry the same confirmation, visibility, validation, and audit expectations as tool invocations.
|
Added some additional security notes. |
|
Out of curiosity, I invesigated several open-source MCP hosts to see which already expose a model-facing
Examples of popular open source clients that don't yet follow this pattern: In VS Code and opencode, a And for others who aren't already aware, Claude Code exposes a model-facing |
|
We actually support resource reading as well in VS Code, through the standard readFile/listDirectory tool (we have a filesystem provider for MCP resource schemes, so although it all looks like it goes through 'fs', it can go to an MCP server under the hood.) Similar to |
Adds a SHOULD to the draft Resources spec recommending that clients give the language model a way to read a resource by URI (with an optional MAY for listing).
Rationale
Resources are currently described as application-driven, but the spec offers no guidance on whether the model itself should be able to pull resource content. In practice this leaves many clients without a model-facing read path, limiting how useful resources are once a URI shows up in context. This change provides clearer guidance on how resources should be implemented in clients to make them more broadly useful.
The recommendation is intentionally mechanism-agnostic ("such as a tool") rather than referencing MCP tools specifically, since the mechanism is typically a host-level LLM tool rather than an MCP server tool.