In MCP, what do prompts/list and prompts/get return, and who invokes a prompt?
answer
- three primitives, three initiators
- the user picks this one
- one call lists, one call fills
- name plus string arguments in, messages out
basics
~20 sprompts/list returns the server's prompt templates with their names, descriptions and declared arguments. prompts/get takes one name plus argument values and returns the filled-in, role-tagged messages. Prompts are user-controlled: a person picks one, the model does not.
solid answer
~40 sPrompts are the third server primitive in MCP, alongside tools and resources, and the distinguishing property is who initiates them. A tool is model-controlled and a resource is application-controlled, but a prompt is **user-controlled**: the host surfaces the server's prompts as slash commands, menu items or buttons, and a human deliberately picks one. `prompts/list` returns a `prompts` array — each entry has a `name`, an optional `title` and `description`, and an optional `arguments` array — plus an optional `nextCursor` for pagination. `prompts/get` takes `name` and an optional `arguments` map of string values, and returns an optional `description` plus a `messages` array, where each message has a `role` and one content block. Under revision 2026-07-28 every result also carries a required `resultType`, and `prompts/list` is cacheable, so it additionally carries `ttlMs` and `cacheScope`.
code
json · 13 lines{
"jsonrpc": "2.0",
"id": 7,
"method": "prompts/get",
"params": {
"name": "review_diff",
"arguments": { "path": "src/main.kt", "style": "strict" },
"_meta": {
"io.modelcontextprotocol/protocolVersion": "2026-07-28",
"io.modelcontextprotocol/clientCapabilities": {}
}
}
}go deeper
Be able to name the three server primitives and say which one a user picks. Know that prompts/list enumerates templates and prompts/get returns the finished messages for one of them.
Explain the shapes: name, title, description and arguments on the list side; name plus a string argument map in, description and role-tagged messages out on the get side. Mention the required resultType.
Show that you design around statelessness: each call is self-contained, prompts/get may arrive without a preceding prompts/list, and the list result's ttlMs and cacheScope drive how often a host refreshes its command menu.
Own the modelling call. Decide deliberately which capability belongs on the user-controlled surface versus the model-controlled one, because that choice determines whether a human reviews every invocation or an agent loop can fire it unattended.
## The third server primitive An MCP server can expose three kinds of things, and the specification separates them by **who initiates the use**. Tools are model-controlled: the language model decides to call one. Resources are application-controlled: the host application decides which URIs to pull into context. Prompts are user-controlled: they are message templates the server publishes so that a *person* can deliberately choose one and have it dropped into the conversation. That distinction is the whole reason prompts exist as a separate primitive instead of being modelled as "a tool that returns some text". A prompt is meant to appear in the host's user interface — a slash-command menu, a command palette, a button, a template picker — and be selected by a human. Nothing in the protocol forces a host to render them that way, but that is the intended control flow, and interviewers use the tools/resources/prompts control triangle as a quick check that a candidate has actually read the specification. ## prompts/list `prompts/list` is an ordinary JSON-RPC request. Its params may carry an opaque `cursor` for pagination; the result may carry `nextCursor` when more pages exist. The substance is the `prompts` array. Each `Prompt` object has: - `name` — the programmatic identifier used later in `prompts/get`. - `title` — an optional human-friendly display name. - `description` — optional prose explaining what the prompt is for; this is what a user reads in the picker. - `arguments` — an optional array of `PromptArgument` objects describing the values the prompt expects. Under revision 2026-07-28 the result is a `CacheableResult`, so it carries the required `ttlMs` and `cacheScope` fields alongside the required `resultType`, which is `"complete"` for an ordinary answer. A client that respects those fields can serve its prompt menu from cache instead of re-listing on every interaction. ## prompts/get `prompts/get` takes two params: the `name` of the prompt, and an optional `arguments` object mapping argument names to **string** values. The result contains an optional `description` and a required `messages` array. Each element is a `PromptMessage` with a `role` and a single content block. The server performs the templating — substitution, formatting, and any lookups it wants to do — so the client receives finished messages it can hand to the model, usually after the user has had a chance to see or edit them. Because the server does the work, a prompt can do far more than string interpolation: it can read a file, query a database, and return the result embedded in the messages. That is what makes prompts more than a client-side snippet feature. ## Statelessness changes how the pair is used MCP at 2026-07-28 is a stateless protocol. The `initialize` handshake and `notifications/initialized` that earlier revisions used were removed; every request instead carries `_meta` with `io.modelcontextprotocol/protocolVersion` and `io.modelcontextprotocol/clientCapabilities`, and a server MUST NOT rely on a prior request over the same connection to establish context. For prompts that means `prompts/list` and `prompts/get` are fully independent calls. A client MAY call `prompts/get` without ever having called `prompts/list` — for instance because it cached the list earlier, or because a user typed a known command. A server that only fills its prompt table after seeing a `prompts/list` from the same connection is broken. ## Errors and the non-complete result A request for an unknown prompt name, or one missing a required argument, is answered with the standard `-32602` invalid-params error. Separately, `prompts/get` is one of only three methods — with `tools/call` and `resources/read` — that may answer with `resultType: "input_required"` rather than `"complete"`. A robust client therefore branches on `resultType` instead of assuming `messages` is present. If an older server omits `resultType` entirely, the client must treat the result as `"complete"`. ## Common mistakes The most frequent error is describing prompts as something the model invokes; that is a tool. The second is assuming prompts are static text — they are server-computed messages. The third is assuming a prompt takes typed JSON arguments the way a tool takes an `inputSchema`; prompt argument values arrive as strings.
- Why model something as a prompt rather than as a tool that returns text?Because the initiator differs. A tool is exposed to the model, which may call it autonomously inside a loop; a prompt is exposed to the user, who picks it deliberately and can review or edit the result before it reaches the model. If the intended trigger is a human choosing a workflow, a prompt puts it in the right surface; if the model should decide, it is a tool.
- Must a client call prompts/list before prompts/get?No. MCP at 2026-07-28 is stateless, so each request is self-contained and a server MUST NOT rely on prior requests over the same connection. A client may call prompts/get directly using a name it cached or a command the user typed. The server must resolve the name on its own; if it does not recognise it, it answers -32602.
saying these in an interview costs you the question
- Saying the model chooses which prompt to invoke
- Calling prompts static text the client interpolates itself
- Claiming prompts/get requires a prior initialize handshake
- Assuming prompt arguments are typed JSON objects
- Thinking prompts/list must precede prompts/get on the same connection