A client calls resources/read on a directory resource, file:///project/docs/. The response contains five separate entries in contents, each with its own file URI and text. A developer files a bug saying the server returned too much. How should the team assess the response?
Select an answer to reveal the explanation.
Short Explanation
Ask the librarian for "the docs shelf" and you get an armful of books, not one. That's fine — resources/read can hand back several items in contents. The trap is assuming one URI in means exactly one item out.
Full Explanation
The resources specification states that servers may return multiple resource contents in response to a single resources/read request and gives the example of returning the contents of several files when a directory resource is read. Each item in the contents array carries its own uri, an optional mimeType, and either text or base64 blob data, so the client can tell the entries apart. The response in the scenario is therefore working as designed, not over-sharing. The claim that exactly one entry must match the requested URI has no basis in the specification. Multi round-trip input is optional and used only when the server genuinely needs more information; it is never a precondition for returning several contents. Resource links are content items that tools can return to point at resources; a resources/read result returns resource contents, not links in place of them. Exam caveat: the opposite situation is constrained; a server must not return an empty contents array for a resource that does not exist and should instead return a -32602 error. Operational check: inspect the response and confirm each contents entry has a distinct URI under the directory and that the host's UI or context builder iterates the whole array rather than taking only the first item.