0.9.0-preview.1: ImageContentBlock throws "invalid base64" when consuming CallToolResult (works in 0.8.0-preview.1)

[monikbhatt]

Title

0.9.0-preview.1: ImageContentBlock throws "invalid base64" when consuming CallToolResult (works in 0.8.0-preview.1)

---

Description

After upgrading from ModelContextProtocol 0.8.0-preview.1 to 0.9.0-preview.1, consuming an MCP server CallToolResult that includes an ImageContentBlock now throws an "invalid base64" exception.

The exact same MCP server response works correctly in:

• 0.8.0-preview.1
• Postman (image renders correctly)

This appears to be a regression introduced in 0.9.0-preview.1, possibly related to the change of ImageContentBlock.Data from string to ReadOnlyMemory<byte> and how JSON deserialization handles base64 content.

---

Expected Behavior

CallToolResult containing an ImageContentBlock should deserialize successfully and allow access to the image data (via DecodedData or Data) without throwing.

This worked correctly in 0.8.0-preview.1.

---

Actual Behavior

When consuming the tool result:

• Accessing ImageContentBlock causes an "invalid base64" exception.
• In some cases, accessing DecodedData triggers the exception.
• The same payload renders correctly in Postman.
• The server response contains valid base64 (confirmed visually and by rendering in Postman).

---

Repro Steps

1. Use ModelContextProtocol 0.9.0-preview.1
2. Connect to MCP server
3. Invoke a tool that returns an ImageContentBlock
4. Receive CallToolResult
5. Access image content (e.g., DecodedData)

Result: FormatException / invalid base64 error

Reverting to 0.8.0-preview.1 resolves the issue immediately.

---

Sample Tool Result Payload (Redacted)

{
  "content": [
    {
      "type": "image",
      "mimeType": "image/png",
      "data": "<valid base64 string>"
    }
  ]
}

Notes:

• No data:image/... prefix
• Standard base64 alphabet
• Image renders correctly in Postman

---

Environment

• ModelContextProtocol: 0.9.0-preview.1
• .NET: (e.g. .NET 10)
• OS: (Windows)

---

Additional Context

This appears to be related to the 0.9 change where ImageContentBlock.Data is now ReadOnlyMemory<byte>. It may be caused by stricter base64 handling during JSON deserialization or a double-decode scenario.

---

[jeffhandley]

Thanks for logging this, @monikbhatt! Great catch!