In MCP, what do prompts/list and prompts/get return, and who invokes a prompt?

## 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.