A CRM server wants the host to be able to fetch any customer record by ID, using addresses such as customers://1042, without listing every customer individually. How should the server expose these records?
Select an answer to reveal the explanation.
Short Explanation
Think of a template as a fill-in-the-blank street address: customers://{id}. You publish the pattern once instead of printing a phone book of every customer. The trap is believing anything with a parameter has to be a tool.
Full Explanation
Resource templates let a server expose parameterized resources using URI templates as defined in RFC 6570. The server lists a template such as customers://{id} through resources/templates/list, and the client expands it into a concrete URI and fetches the record with resources/read; template arguments can even be autocompleted through the completion utility. This keeps the record application-controlled context, addressed by URI, without enumerating thousands of entries. Modeling the lookup as a tool changes who controls it: tools are model-controlled actions, and nothing about parameterized addresses forbids them from being resources. Listing every customer in resources/list is possible in principle but defeats the requirement and is not forced by any file-only restriction, since templates work with any URI scheme, including custom ones. Prompts do accept arguments, but they produce templated messages for the user to invoke, not data records. Exam caveat: templates are discoverable and cacheable like other list results, and a server should still authorize every resources/read for a concrete customer URI. Operational check: call resources/templates/list and confirm an entry with uriTemplate customers://{id}, then read customers://1042 and verify the returned contents carry that URI.