A host displays garbled output whenever a charting tool returns an image content block. Inspection shows that the block's data field holds raw PNG bytes and its mimeType field is empty. Which fix aligns the result with the specification?
Select an answer to reveal the explanation.
Short Explanation
JSON can't carry raw binary safely, so you send images as base64 with a label on the box. That label is the MIME type, like image/png. Leave either out and the host is left guessing at bytes.
Full Explanation
Image and audio content blocks carry their payload in a data field that must be base64-encoded and must include a valid MIME type; the prompts specification states this explicitly, and tool results use the same content format. JSON-RPC messages are JSON text in UTF-8, so raw binary bytes cannot be embedded safely, and without a MIME type the host has no reliable way to choose a decoder or renderer. Base64-encoding the PNG and declaring image/png resolves both defects. Moving the bytes into a text block is wrong because text content holds human-readable strings; it offers no binary channel and would corrupt the data the same way. Progress notifications report the status of an in-flight request through progress, total and message values and are not a delivery path for result payloads. The $schema keyword selects a JSON Schema dialect for validation and has nothing to do with media formats. Exam caveat: hosts that render images should treat MIME types as advisory and verify the actual bytes before rendering, a precaution the specification spells out for icons. Operational check: decode the data field from base64, confirm the bytes begin with a PNG signature, and confirm mimeType is set to image/png before the host renders the block.