DevSpace currently supports the host-to-workspace direction with download_artifact, but there is no corresponding way to hand an existing workspace file back to an MCP host as a native attachment.
I reproduced this with ChatGPT over remote MCP. Returning a resource_link whose URI is an HTTPS download URL causes ChatGPT to recognize a file-shaped result, but it does not fetch that URL. Returning a resource_link to a registered MCP resource instead (artifact://...) causes the host to follow up with resources/read and materialize the result as an attachment.
A small implementation could keep this bounded and host-agnostic: add one read-only export_artifact({ workspaceId, path }) tool, expose files up to a fixed size as short-lived registered MCP resources, return text for textual MIME types and blob for binary content from resources/read, and reject paths whose real target escapes the selected workspace. This would not require a public artifact HTTP endpoint or a new persistent artifact service.
I have a working local implementation and regression coverage for cross-session resource reads and the size boundary, including a real ChatGPT attachment materialization test. Happy to send the focused PR if this direction fits DevSpace.
DevSpace currently supports the host-to-workspace direction with
download_artifact, but there is no corresponding way to hand an existing workspace file back to an MCP host as a native attachment.I reproduced this with ChatGPT over remote MCP. Returning a
resource_linkwhose URI is an HTTPS download URL causes ChatGPT to recognize a file-shaped result, but it does not fetch that URL. Returning aresource_linkto a registered MCP resource instead (artifact://...) causes the host to follow up withresources/readand materialize the result as an attachment.A small implementation could keep this bounded and host-agnostic: add one read-only
export_artifact({ workspaceId, path })tool, expose files up to a fixed size as short-lived registered MCP resources, return text for textual MIME types andblobfor binary content fromresources/read, and reject paths whose real target escapes the selected workspace. This would not require a public artifact HTTP endpoint or a new persistent artifact service.I have a working local implementation and regression coverage for cross-session resource reads and the size boundary, including a real ChatGPT attachment materialization test. Happy to send the focused PR if this direction fits DevSpace.