A document server exposes a resource whose content is a PDF file rather than plain text. How should the server represent that content in its resources/read result?
Select an answer to reveal the explanation.
Short Explanation
Resources come in two flavors: text and blob. A PDF is binary, so you base64 it into a blob and label it application/pdf. Cramming raw bytes into text is the classic trap.
Full Explanation
The resources specification defines two forms of resource contents: text content, which carries a text field, and binary content, which carries a blob field holding base64-encoded data. Each item includes the resource URI and should carry a mimeType so the client knows how to interpret it. A PDF is binary, so the server returns it as a blob with a MIME type such as application/pdf. The security considerations also state that binary data MUST be properly encoded. Placing raw bytes in a text item is incorrect because text contents are meant for character data, and binary bytes inside a JSON string would be corrupted or invalid. A resource_link is a content type used inside tool results and prompt messages to point at a resource; resources/read is the call that actually returns contents, and it supports binary data through blob. URL-mode elicitation exists for sensitive out-of-band interactions such as credential entry, payments or third-party authorization, not for delivering ordinary resource data. Exam caveat: resources/read may return multiple content items, for example when a directory resource is read, and each item uses either text or blob. Operational check: call resources/read on the PDF's URI and confirm the item has a blob field that decodes to bytes starting with %PDF and a mimeType of application/pdf.