The spec's resource_link content type (introduced in protocol revision 2025-06-18, still present in 2025-11-25 — both of which this SDK advertises in ProtocolVersion) has no corresponding schema class: src/Schema/Content/ contains TextContent, ImageContent, AudioContent, EmbeddedResource, and the ResourceContents variants, but grepping the whole src/ tree for resource_link/ResourceLink at v0.7.0 comes up empty.
Why it matters: resource_link is the lightweight way for a tool result to reference a resource without embedding its bytes. The only current alternative, EmbeddedResource, inlines the full ResourceContents — the wrong tool when a result references many or large resources. The concrete case we hit: a Pimcore DAM MCP server (pimcore/data-hub-simple-rest#287) whose search/tree tools return hits referencing image/video assets that are separately readable via registered resource templates. Per spec, each hit should carry a resource_link block with the template-constructed URI; embedding blobs in a 25-hit search result is not viable, so tool output is stuck smuggling URIs through text/structured content until the type exists.
Proposal: add Schema/Content/ResourceLink (type: "resource_link" with uri, name, plus the optional title/description/mimeType/size/annotations fields from the spec schema), accepted anywhere tool-result content blocks are (de)serialized.
Happy to open a PR for it if that's welcome — it looks self-contained (new schema class + registration in the content deserialization map).
The spec's
resource_linkcontent type (introduced in protocol revision 2025-06-18, still present in 2025-11-25 — both of which this SDK advertises inProtocolVersion) has no corresponding schema class:src/Schema/Content/containsTextContent,ImageContent,AudioContent,EmbeddedResource, and theResourceContentsvariants, but grepping the wholesrc/tree forresource_link/ResourceLinkat v0.7.0 comes up empty.Why it matters:
resource_linkis the lightweight way for a tool result to reference a resource without embedding its bytes. The only current alternative,EmbeddedResource, inlines the fullResourceContents— the wrong tool when a result references many or large resources. The concrete case we hit: a Pimcore DAM MCP server (pimcore/data-hub-simple-rest#287) whose search/tree tools return hits referencing image/video assets that are separately readable via registered resource templates. Per spec, each hit should carry aresource_linkblock with the template-constructed URI; embedding blobs in a 25-hit search result is not viable, so tool output is stuck smuggling URIs through text/structured content until the type exists.Proposal: add
Schema/Content/ResourceLink(type: "resource_link"withuri,name, plus the optionaltitle/description/mimeType/size/annotationsfields from the spec schema), accepted anywhere tool-resultcontentblocks are (de)serialized.Happy to open a PR for it if that's welcome — it looks self-contained (new schema class + registration in the content deserialization map).