docs: add early version of the resources spec#13
Conversation
jspahrsummers
left a comment
There was a problem hiding this comment.
I think these docs are super useful, but I'm worried about drift between them and the actual schema (which should be canonical IMO). Is there some way that we can statically validate that we don't use types in the examples here that aren't in the schema itself?
|
|
||
| # Resources | ||
|
|
||
| Resources enable servers to expose arbitrary data to clients in a structured way. Clients can discover available resources, read their contents, and optionally subscribe to updates. Each resource is uniquely identified by a URI. |
There was a problem hiding this comment.
I would add something to the effect of:
- Resources are specifically for giving the model context
- Users may attach resources explicitly via the client UI, or clients could intelligently select the right resources to add to the context
| - params: `ListResourcesParams` defined as follows: | ||
|
|
||
| ```typescript | ||
| interface ListResourcesParams extends WorkDoneProgressParams { |
There was a problem hiding this comment.
Can you please ensure the schema file stays in sync with these identifiers?
|
|
||
| interface Resource { | ||
| uri: DocumentUri; | ||
| name: string; |
There was a problem hiding this comment.
| name: string; | |
| name: string; | |
| description?: string; |
| : Used to embed small pieces of data directly in the URI | ||
| : Useful for simple, static resources | ||
|
|
||
| custom:// |
There was a problem hiding this comment.
| custom:// | |
| {custom}:// |
Co-authored-by: Justin Spahr-Summers <justin@jspahrsummers.com>
Co-authored-by: Justin Spahr-Summers <justin@jspahrsummers.com>
Co-authored-by: Justin Spahr-Summers <justin@jspahrsummers.com>
Co-authored-by: Justin Spahr-Summers <justin@jspahrsummers.com>
Co-authored-by: Justin Spahr-Summers <justin@jspahrsummers.com>
I agree. I am skeptical about our current approach. I am looking for ideas for how to best approach this. We clearly need some set of good developer documentation that clearly outlines the request flows. |
|
Can we do something like |
This commit introduces the concept of required capabilities for using resources in the MCP specification. It specifies that servers must include a 'resources' capability in their ServerCapabilities object during initialization. The commit also adds examples of server capabilities with and without subscription support, providing clear guidance for implementers on how to properly declare resource support.
|
I actually went back to not include the exact interfaces. I'll think more about it. Likely we are best off including the interfaces but making sure we have something like a validate step. |
Update python.mdx to use uv
SEP Cleanup, fixing typos, adding collapsible sessions to make it easier to read. Renamed RetryAugmentedRequestParams to InputResponseRequestParams, to better align with other type names added in this SEP. Removed SEP wording that says ephemeral scenario does not support Elicitation Form URLs, I have a prototype of this working by leveraging request state. Also re-added URLElicitationRequiredError since this may still be necessary.
Cross-referenced the open issues in experimental-ext-server-card so the charter does not assert things the WG is still deciding: - Reference Implementation: cite python-sdk#2696 (open, in review) as the in-progress SDK reference impl instead of claiming none exists (#16). - Stop presenting .well-known as locked: add a discovery-mechanism open item for the .well-known-vs-GET-on-URL question (#12) and make the IANA registration conditional on that outcome. - Align the path/media-type open items with the reference impl's slash-form vote (#11) and the application/mcp-server-card+json direction (#9). - Add an auth-shape open item flagging the limited initial shape and the additive SEP-2742 auth fast-follow / forward-compat requirement (#13, #17). - Note that whether to add primitive listings is itself open (#10). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
No description provided.