I would be happy to have and adopt this for VS Code 👍

I think there is a use case for returning a temporary resource that can be read via resources/read but is not listed via resources/list. In which case, I think it would be useful to include all resource properties, such as mimeType and annotations (as @connor4312 mentioned). So would it be feasible to return Resource instead of ResourceReference?

We'd be far better off including Resource as it also has the LLM Facing description. And then at the same time we could add subscribable to Resource as I think that's missing. Happy to add to the PR

@bhosmer-ant if in agreement we switch to Resource we should also add this to the Prompt primitive too.

I think there is a use case for returning a temporary resource that can be read via resources/read but is not listed via resources/list. In which case, I think it would be useful to include all resource properties, such as mimeType and annotations (as @connor4312 mentioned). So would it be feasible to return Resource instead of ResourceReference?

I agree I've noted this idea in #617 as well in relation to the idea of sending back resources as part of progress notifications. I think the original motivation of resource is to find long lived static resources that the server holds. However I think there are a set of use cases for short lived temporary resources associated with a specific request.

This does open up the question of how long those resources are valid to avoid clogging up the server. I'm suggesting the idea of a keepAlive flag that tells the client how long it can expect the resource to be held by the server.

We'd be far better off including Resource as it also has the LLM Facing description.

@evalstate hey Shaun, yeah I think you and @jonathanhefner are totally right, Resource is better than ResourceReference here. (Going this way introduces ambiguity around whether resources/list is "total" - since we're now able to return resources from tool calls that may never appear in that listing - but I think that's fine.)

And then at the same time we could add subscribable to Resource as I think that's missing.

I'd like to leave subscribable to a separate PR/discussion, I think it's orthogonal to this change.

@bhosmer-ant if in agreement we switch to Resource we should also add this to the Prompt primitive too.

Yeah agreed. Actually I think it's worth factoring out

ContentBlock = TextContent | ImageContent | AudioContent | EmbeddedResource | Resource

and using it from both CallToolResult and and PromptMessage.

Happy to add to the PR

I mean, I'll take you up on it if you agree with the above, but also happy to do it if your offer has aged out! Just LMK (and 🙏 for the discussion either way)

Perfect! I'll update first thing in the morning and agree on moving the subscribable discussion elsewhere. 👍

lgtm 🙂

Thank you. Looks good to me. Some wording changes maybe.

Not sure I really like the name linked_resource compared to resource_link but I am not too fussed about it. Thoughts @ihrpr ?

Given that we are inheriting from the Resource which is basically a definition of a resource, it might be more intuitive to call it a resource_link. As then there might be confusion in type hierarchy around EmbeddedResources and LinkedResources etc

But also not a strong preference, just thinking out loud

@ihrpr @dsp-ant I'm also weak on the name. The "real" name is Resource (but with a type tag) and any name that sounds semantically nontrivial is potentially confusing, e.g. "link" (on either side) could easily be read to mean that we're adding an extra level of indirection to Resource, which we're totally not.

How about ResourceContent? It leaves EmbeddedResource in an awkward position (assuming we don't want to churn it to EmbeddedResourceContent) but eh

Followup: "content" sort of implies removing a level of indirection, so not a panacea. Going with ResourceLink

@ihrpr @dsp-ant I'm also weak on the name. The "real" name is Resource (but with a type tag) and any name that sounds semantically nontrivial is potentially confusing, e.g. "link" (on either side) could easily be read to mean that we're adding an extra level of indirection to Resource, which we're totally not.

How about ResourceContent? It leaves EmbeddedResource in an awkward position (assuming we don't want to churn it to EmbeddedResourceContent) but eh

Followup: "content" sort of implies removing a level of indirection, so not a panacea. Going with ResourceLink

I went down this path...:) We already have a ResourceContents. ResourceReference?

I went down this path...:) We already have a ResourceContents. ResourceReference?

Yeah, I also though about ResourceReference, but equally happy with ResourceLink

I ran this [naming] problem through the Claude quite a few times!