A travel assistant needs three things from one MCP server: actions that book flights and hotels, the traveller's saved preferences as context, and a reusable plan-a-trip workflow that the user can start on demand. How should the server map these to primitives?
Select an answer to reveal the explanation.
Short Explanation
You can think verbs, nouns and recipes: tools do things, resources hold things, and prompts are recipes the user picks. Mix those up and the model ends up trying to read an action or run a document.
Full Explanation
MCP defines three server primitives by who controls them. Tools are model-controlled: the model decides when to invoke an action such as booking a flight, and the host applies consent before side effects occur. Resources are application-controlled data addressed by URI: the traveller's saved preferences are context the host can read and supply to the model. Prompts are user-controlled templates: the user decides when to start the plan-a-trip workflow, and the server supplies its content with arguments. Mapping bookings to prompts would make a side-effecting action depend on a user picking a template, and exposing preferences as tools would turn plain context into an invocable operation. Treating preferences as prompts confuses stored data with a workflow template. Modelling the workflow as a resource strips away the user-initiated invocation and argument handling that prompts provide, and modelling bookings as resources would mean reading a URI performs a purchase, which breaks the expectation that reads are free of side effects. Exam caveat: the same backend can feed several primitives; what matters is the control model each interaction needs. Operational check: call tools/list, resources/list and prompts/list and confirm bookings, preferences and the workflow each appear under the expected primitive.