MCP **prompts** let a server expose reusable message templates that a user can select. Per the prompts spec (2026-07-28), prompts "allow servers to provide structured messages and instructions for interacting with language models." Clients discover them, retrieve their contents, and supply arguments. Prompts are user-controlled: they are exposed so the user can explicitly select them (for example as slash commands). That names who decides when the prompt is used, not who wrote it. Mid-call requests for more input are a different primitive: MCP elicitation.
List vs get
All rows follow the prompts spec, 2026-07-28.
| Method | What it does | Result shape (high level) |
|---|---|---|
| `prompts/list` | Discover available prompts | Prompt objects: `name`, optional `title`, `description`, `arguments`, `icons` |
| `prompts/get` | Resolve one prompt | `description` and `messages` (each with `role` `"user"` or `"assistant"` and `content`) |
Servers that support prompts MUST declare the `prompts` capability and MUST respond to `prompts/list`. The set MAY be empty, MAY change over time, and MAY vary by authorization on the request. Optional `listChanged` covers change notifications (Capabilities).
Arguments on a prompt definition include `name`, `description`, and whether each is `required`. The client passes them on `prompts/get`. Message content types include text, image, audio, resource_link, and embedded resource (Getting a Prompt; Data Types). Servers MAY respond to `prompts/get` with `InputRequiredResult` when more input is needed before the prompt can be resolved.
Errors (Error Handling): invalid prompt name or missing required arguments → `-32602`; internal → `-32603`.
Client support: Cursor and Claude Code
Only clients whose docs confirm prompts support are named here:
- Cursor's MCP docs list Prompts as "Supported" — "Templated messages and workflows for users."
- Claude Code's commands docs say MCP servers can expose prompts that appear as commands; Claude Code's MCP docs cover capability discovery that includes `prompts/list`, and the docs describe running MCP prompts as commands from the `/` menu.
No other clients are claimed here.
Prompts vs elicitation vs skills
| Primitive | Who decides to use it | When it runs |
|---|---|---|
| MCP prompt | User (user-controlled) | Up front, as a selected template |
| Elicitation | Server asks mid-call | During a tool (or other) request that needs more input |
| Skill | Product-specific (agent instructions) | When the agent loads written instructions — not an MCP list/get message |
Skills and MCP tools are a separate packaging decision: skill vs MCP tool.
Pitfalls
- Treating prompts as model-auto-invoked tools. The spec frames them as user-selected.
- Mixing prompts with elicitation. A prompt is a reusable template; elicitation is mid-call input.
- Omitting required-argument handling. Missing required arguments should return `-32602`.
- Naming every MCP client. Only Cursor and Claude Code are sourced above.
How to check it
Connect the server in Cursor or Claude Code, confirm the prompt appears where the client's docs say prompts surface, call `prompts/get` with and without a required argument, and confirm a missing required argument returns `-32602`.
Where the kit fits
The MCP Starter Kit ($27) is built for teams putting OAuth-protected remote MCP servers in front of Cursor and Claude Connect. Soft path: start at /free; Cheat Sheet for the skim checklist mindset; kit when you want the auth-ready layout.
Soft next step
List the templates your users already paste by hand, expose each as a named prompt with clear required arguments, and verify list/get in Cursor or Claude Code. Soft ladder: /free, then the MCP Starter Kit ($27). Related: OAuth pillar, MCP elicitation, skill vs MCP tool.