A server downloads PDFs from a partner's authenticated web portal using credentials the server holds, then exposes them as resources. The MCP client has no access to that portal. Which URI choice follows the resources specification?
Select an answer to reveal the explanation.
Short Explanation
Ask yourself one question: can the client fetch this URL on its own? If it can't, you're just sending it to a locked door with an https:// URI. The trap is thinking "it came from the web, so it must be https" when the spec says to use another or custom scheme.
Full Explanation
The resources specification says servers should use the https:// scheme only when the client can fetch and load the resource directly from the web on its own, without reading it through the MCP server. For other cases servers should prefer another URI scheme or define a custom one, even when the server itself downloads the contents over the internet. Here only the server holds the portal credentials, so a custom scheme that clients resolve through resources/read is the fitting design; custom schemes must follow RFC 3986. Using the portal's https:// URLs fails because the client would be invited to fetch an address it cannot authenticate to, which is the exact situation the guidance excludes. Choosing file:// for its supposed monopoly on binary data fails by concept: any resource may return text or a base64 blob, and file:// is for filesystem-like resources. Setting cacheScope to private fails because cacheScope only describes whether a cached result may be shared across users; it says nothing about who can fetch the URI. Exam caveat: https:// remains correct for public pages the client can load itself. Operational check: for each resource URI, confirm whether the client could retrieve it without the server; if not, switch it to a custom scheme and verify resources/read returns the content.