When should an MCP server expose a capability as a prompt rather than a tool?

## The control model, stated once MCP's server primitives are distinguished less by what they can carry than by **who initiates them**. Tools are model-controlled: the model picks one and the client issues `tools/call`. Resources are application-controlled: the host decides what context to pull in. Prompts are user-controlled: a person picks one from the host's surface and the client issues `prompts/get`. That is not decoration. It determines where the decision to run something is made, who can be asked for consent, and what the failure modes look like. A design that ignores it produces a server that technically works and is awkward to use. ## What each side actually returns `prompts/get` returns `messages` — role-tagged content blocks that seed a conversation. By construction the deliverable is *text and attached context*, not an effect. `tools/call` returns the outcome of doing something: content blocks, optionally `structuredContent`, and `isError` when the operation itself failed. Tools also declare `inputSchema` and carry `ToolAnnotations` such as `readOnlyHint` and `destructiveHint`, which exist precisely because tools may change things. So the first filter is blunt: **does something happen, or is something composed?** Sending an email is a tool. Producing the draft of an email — with the customer's last three tickets attached — is a prompt. ## Signals that say "prompt" - A human starts it deliberately, at a moment of their choosing. - Its value is in the *framing*: the phrasing, the ordering, the attached context that a user would otherwise have to assemble by hand. - It encodes house style or a reviewed procedure the organisation wants used consistently. - Its inputs are few, nameable and completable — declared `PromptArgument`s with `completion/complete` suggestions beat making the user type an opaque identifier. - You want the user to see and edit what goes into the conversation before it goes in. ## Signals that say "tool" - The model needs it mid-loop, without a human pausing to choose it. - It queries or mutates a live system and the answer depends on when you ask. - The result needs machine shape — a schema-validated object the caller parses. - It can fail in ways the model should see and react to, which is what `isError` is for. - Its arguments are numerous or nested; prompt arguments are a shallow, user-facing form. ## Reachability, and the cost of choosing wrong The asymmetry to internalise: **a model cannot invoke a prompt.** If your only route to a capability is the prompt catalogue, an agent running unattended will never use it, and hosts differ in how prominently — or whether — they surface prompts at all. Conversely, a workflow exposed only as a tool loses the deliberate, reviewable, user-initiated entry point, and you have handed a model discretion over something a person was better placed to start. Shipping both is a real option for genuinely dual-use capabilities: the prompt gives humans the curated entry point, the tool gives the model the callable one. Price it honestly. Two surfaces mean two schemas, two sets of docs, two things to keep in step when behaviour changes, and two places a security review must look. On a catalogue of any size, reflexively doubling everything is how a server becomes unusable — the listings get long, the names blur, and neither humans nor models pick well. ## Catalogue-level judgment At scale the interesting decisions stop being per-capability: - **Naming and scope.** Names must be unique within a server, and a client aggregating several servers should prefix them with a server identifier — `serverInfo.name` is self-reported and not reliable for that. Plan for your names to appear next to a stranger's. - **Granularity.** Ten narrow prompts a user can pick between beat one mega-prompt with a mode argument, because the host's picker is the discovery surface. - **Stability.** Prompt catalogues are documented by users in their own runbooks; renaming is a breaking change to their muscle memory even when nothing in the schema moved. - **Consent surface.** MCP cannot enforce its consent principles at the protocol level — the host is the enforcement boundary. Putting a capability behind a prompt puts a human in the initiating position; putting it behind a tool relies on the host asking before each call. ## What interviewers listen for A weak answer says prompts are "a nicer way to call tools" or assumes the model can invoke them. A strong one leads with initiator and return shape, then reasons about reachability, catalogue size, the cost of maintaining both surfaces, and where a human is best placed to say yes.