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.

[toffereins-stratusgroup]

I am very new to creating MCP servers/tools and have only had limited exposure thus far. So please bear with me.

I hit the same issue building an MCP server in C# (also using the official SDK). My get_file tool returns file
attachments from an ERP system — images, PDFs, CSVs, Office documents, etc.

What I tried: Following the TinyImageTool sample pattern, I returned DataContent for non-image files alongside a TextContent base64 fallback block, expecting that the SDK's automatic mapping to EmbeddedResourceBlock would either work or be silently ignored by unsupported clients.

What happened: Both Claude Desktop and claude.ai treat all blob content blocks as images and validate the MIME type against image/jpeg, image/png, image/gif, image/webp. When validation fails (e.g. application/pdf), the entire tool response is rejected — including the companion TextContent block. This means including an EmbeddedResourceBlock for non-image types is not just unsupported, it's destructive to the response.

Current behaviour: I am restricting DataContent to the four supported image MIME types only. Non-image files are returned as base64 inside a TextContent JSON block — no blob/resource blocks at all. This restores correct behaviour but means non-image binary files can only be delivered as base64 text.

[eng-marani]

I really think the problem is in Claude Desktop.
I tried to join the MCP server from Cursor, and also using the node.js inspector (spectacular tool) and it worked right out of the box.
Unfortunately, i do not have any supported plan for Claude Desktop, so i am unable to give them any feedback and bug report about this. In my humble opinion, Claude Desktop is simply an immature product, and that is very fancy because they have invented and pushed the standard, but they are the same company where MCP standard is not properly handled.
If you know any way to let Anthropic take into consideration handle other kind of mime types except images, let me know. Returning a PDF properly would be the bare minimum for me.