A retailer is designing one MCP server. It needs a read-only product catalogue for context, an action that places an order, and a "draft a complaint reply" template that staff choose from a menu when they want it. How should these map to MCP primitives?
Select an answer to reveal the explanation.
Short Explanation
Reference shelf, cash register, and a stack of fill-in-the-blank letters: resource, tool, prompt. Ask yourself who is in control — the app, the model, or the user — and you have the mapping. The trap is making everything a tool.
Full Explanation
MCP's three server primitives differ by who controls them. Resources are application-controlled context addressed by URI, so a read-only product catalogue fits: the host decides how to bring it into the model's context, and it can be cached and subscribed to. Tools are model-controlled functions that perform actions, so placing an order is a tool, with the host keeping a human in the loop to confirm it. Prompts are user-controlled templates that users explicitly select, typically from a menu or command, and the server supplies the messages; a complaint-reply template that staff choose when they want it is a prompt. Making the catalogue a tool and the order a prompt reverses both: reading reference data does not need model-invoked execution, and a prompt only produces messages, so it cannot place an order. Making the catalogue a prompt and the template a resource confuses data with user-invoked templates. Modeling everything as tools discards the control distinctions that let the host apply the right consent and UI to each, and resources and prompts are also discoverable through their own list methods. Exam caveat: the protocol does not mandate a user interface for any primitive; the control model describes intent. Operational check: confirm the server's capabilities declare resources, tools and prompts, and each item appears in the matching list.