Returning an EmbeddedResourceBlock from a tool do not work with Claude Desktop

[eng-marani]

Describe the bug
I'm playing with tools attempting to return different ResultContent from an MCP server.

This works:

 ImageContentBlock imgResult = new ImageContentBlock() { Data = base64, MimeType = mimeType };
 result.Content[0] = imgResult;
 return result;

This do not work (mimetype is "application/pdf")

 BlobResourceContents resContent = new BlobResourceContents() { Blob = base64, MimeType = "application/pdf", Uri = $"file:///mypdf.pdf" };
 EmbeddedResourceBlock resResult = new EmbeddedResourceBlock() { Resource = resContent };
 result.Content[0] = resResult;
 return result;

To Reproduce
Steps to reproduce the behavior:

1. Create an MCP server in c# with a tool that return a contentresult
2. Setup Claude Desktop as a client

Expected behavior
The resource file should be available in LLM context

Observed result
Claude claims that the tool returned a BAD IMAGE with a wrong mimetype

Claude is basically interpreting the result as an image instead of the suggested mimetype

I do not know if this is a problem of SDK or possibly some wrong implementation in Claude Desktop.

[stephentoub]

What do you see as the mime type if you use the MCP Inspector to interact with your tool? It's very unlikely something in the SDK is changing your mime type from pdf to an image.

[eng-marani]

Using the inspector seem good. And also i tried to connect MCP server to Copilot inside VS Code and the file is downloaded.
I assume there is something wrong in Claude client implementation, but i would like to crosscheck if it's just my case, because Claude Desktop is spreadly used to test MCP servers, and i wonder how nobodyone detected such a big mistake of that client handling only images and text based content when using a tool result.

[PederHP]

Anthropic API supports DocumentBlockParam in tool results, which can be pdfs.

But the SDK used by Claude might not map it correctly.

You also need to actually put the resource contents into the tool result I think. A uri is probably not enough. That could be it. If that still doesn't work, it's a Claude platform bug.

Check if full pdf base 64 is in the response in inspector.

Vs code treating this as a resource link might be a resilience thing, because I am not sure impliclity linking via uri is fully spec compliant.