A tool returns a content item of type resource_link pointing to file:///exports/report-7.csv. The client checks resources/list and the URI is not there. A developer suspects the server is broken. What is the correct assessment?
Select an answer to reveal the explanation.
Short Explanation
A tool handing you a link is like a colleague emailing you a file path; it doesn't have to be in the library catalogue for you to open it. The spec says those links may not show up in resources/list. The trap is treating the list as the only valid inventory.
Full Explanation
Tools may return resource links to provide additional context or data, in which case the result contains a URI that the client can fetch or subscribe to, along with descriptive metadata such as a name and MIME type. The tools specification adds an explicit note that resource links returned by tools are not guaranteed to appear in the results of a resources/list request. A freshly generated export is a typical example: the server can make it readable through resources/read without adding every transient file to its advertised list. Calling the server non-compliant invents a requirement the specification does not contain. Discarding the link because it is unlisted is equally unfounded; resources/list is a discovery aid, not an access-control list, and readability is decided by the server when resources/read is called. Sending list_changed before every link is also not required, and that notification reaches only clients that opted in with resourcesListChanged, so it could not serve as a precondition anyway. Exam caveat: the opposite type, an embedded resource, places the content itself in the tool result rather than pointing to it, and servers that use embedded resources should implement the resources capability. Operational check: call resources/read on the linked URI and confirm the server returns the CSV contents even though resources/list does not include it.