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 🙂