A server lists a resource with the URI file:///projects/app/src that represents a directory rather than a regular file. The team wants clients to recognise it as a folder. What does the resources specification allow?
Select an answer to reveal the explanation.
Short Explanation
Folders don't have a normal MIME type, so the spec borrows one from the desktop world: inode/directory. You keep the file:// URI and just label it properly. Don't get tricked into thinking file:// is only for regular files; the spec says it doesn't even have to map to a real disk.
Full Explanation
The file:// scheme identifies resources that behave like a filesystem, and those resources need not map to an actual physical filesystem. For non-regular files such as directories, which have no standard MIME type, the specification says servers may use an XDG MIME type like inode/directory in the resource's mimeType. A client can then render the item as a folder, and when the directory resource is read the server may return several resource contents in one resources/read response. Switching to git:// fails because git:// is the scheme for version-control integration, and nothing restricts file:// to regular files. Removing the directory from resources/list because folders belong in roots fails twice: roots are a client feature that tells servers which locations matter, not a way for servers to publish folders, and roots are deprecated in this revision. Setting audience to a folder value fails because the audience annotation accepts only "user" and "assistant" and describes who the content is for, not its type. Exam caveat: the XDG type is permitted (MAY), not required, so clients should handle directories that omit it. Operational check: call resources/list, confirm the directory entry carries mimeType inode/directory, and confirm that reading it returns the expected child contents.