What is MCP Prompt?

How It Works

An MCP Prompt is the reusable instruction primitive in the Model Context Protocol. A Server authors and exposes a named template, a Client discovers and retrieves it, a user explicitly chooses when to use it, and the Host decides how the returned messages enter a model request. User-controlled describes selection, not authorship or trust. Retrieving a Prompt neither calls a model nor executes a Tool; MCP defines prompts/list and prompts/get, not a standard prompts/execute method.

This contract differs from nearby concepts. A generic Prompt is any model input, while an application-local Prompt Template has no MCP discovery or transport contract. A System Prompt belongs to the Host or model-provider policy layer. An MCP Prompt can return only user or assistant roles, so an Assistant Message labeled as a system instruction does not acquire System Role authority. A Chat Template is the tokenizer-specific serialization that turns roles and content into model tokens after the Host assembles the conversation. An MCP Tool performs an action, and an MCP Resource exposes URI-addressed data; a Prompt may guide their use but cannot grant either permission.

In MCP 2026-07-28, each prompts/list and prompts/get Request is stateless and carries the protocol version and relevant Client Capabilities in _meta. A Server supporting Prompts declares the prompts Capability through server/discover, optionally with listChanged. The list can be empty or filtered by credentials on the current Request, but it must not vary merely because another Request used the same Connection. Hosts aggregating Servers should qualify the Prompt name with a stable configured Server identity because a name is only meaningful within that Server.

prompts/list returns descriptors containing a programmatic name, optional display title, description, icons, and Argument metadata. It supports opaque Cursor Pagination and a Complete Result with resultType, non-negative ttlMs, and cacheScope. Use public only for a catalog identical across callers; user-, Tenant-, role-, or token-filtered lists require private and Authorization-context cache isolation. Pagination has no cross-page snapshot guarantee. A changed notification invalidates cached pages, but absence of a notification does not prove that a later rendered body is identical.

Prompt Arguments are deliberately narrower than Tool inputs. A descriptor gives each Argument a name, optional title and description, and optional required flag; prompts/get.params.arguments is a map of strings. There is no protocol-level JSON Schema, numeric type, enum, secret type, or nested object for Prompt Arguments. The Server must enforce required fields, reject unknown or oversized values according to its contract, parse domain formats deterministically, and authorize referenced repositories, records, files, or Tenants. A description or UI control improves usability but is not validation.

Clients may request completion/complete for a Prompt Argument through a ref/prompt reference. Suggestions are also authorization-sensitive data: filter them by the current Principal and Tenant, rate limit and debounce lookup, cap the result to the protocol maximum, and avoid revealing private project names or record identifiers through prefixes and match counts. Completion narrows data entry; it does not validate the final value or authorize the resulting Prompt.

prompts/get renders the selected name and strings into a Complete Result with a description and one or more Prompt Messages. Each message has a user or assistant role and one Content Block: Text, Base64 Image, Base64 Audio, Resource Link, or Embedded Resource. The Client must validate content shape, MIME type, encoded bytes, Resource access, and size before preview or model inclusion. Prefer a scoped Resource Link over inlining large or sensitive context, and preserve provenance so the user can see which Server and data source produced the message.

A rendered Prompt is not protocol-cacheable: prompts/get is absent from the MCP cacheable-operation list and its Complete Result has no ttlMs or cacheScope. Do not reuse the catalog TTL as a body TTL. If an application adds its own render cache, its key must include the exact Prompt name, all Arguments, Authorization Context, Server build, template revision, and relevant policy; MRTR retries must never use that cache. The current protocol has no standard Prompt version field or content-changed notification, so consequential deployments should pin an immutable Server build and compare descriptor and rendered-content hashes.

List-change delivery uses a long-lived subscriptions/listen Request with promptsListChanged: true. The Server acknowledges the accepted filter and tags notifications/prompts/list_changed with io.modelcontextprotocol/subscriptionId; the Client then refetches the list. An HTTP Client cancels by closing its SSE stream, while stdio sends notifications/cancelled for the listen Request. Reconnection requires a new subscription. This replaces connection-wide legacy notifications, and it signals catalog invalidation rather than delivering a new rendered Prompt body.

Only prompts/get, not prompts/list, can return MRTR resultType: "input_required" for supported Elicitation, Roots, or legacy Sampling input. The retry is an independent Request with a new JSON-RPC ID, inputResponses, and optional opaque requestState. Treat State as attacker-controlled; if it affects Prompt selection, Resource access, Arguments, or policy, protect its integrity and bind it to the Principal, method, salient parameter digest, policy revision, and short expiry. The Client echoes it exactly and must not inspect or modify it.

Invalid Prompt names and missing required Arguments use JSON-RPC -32602 Invalid Params; internal failures use -32603. Distinguish these from a valid empty Message or a Host decision not to send the result to a model. Return stable error classes without exposing Template Source, hidden policy, Resource existence, secrets, or raw Argument values. Timeout or transport loss also does not authorize a silent fallback to a different Prompt or stale cached body.

Prompt content crosses a semantic supply-chain boundary. A malicious or compromised Server can place Prompt Injection in its descriptor or rendered Text; Argument text can create direct injection, Resources can carry indirect injection, and Image or Audio can create cross-modal injection. Delimit instructions from untrusted data, apply byte and token budgets, scan and classify content, retain least-privilege Tool permissions, and require separate approval for consequential calls. Escaping or a stronger System Prompt can reduce ambiguity but cannot prove that model interpretation is safe.

Treat Prompt changes like code changes. Record an immutable Server build, Prompt and template revision or hash, Argument digest rather than raw secrets, Resource provenance, user selection and preview decision, model and Chat Template version, enabled Tools, policy revision, token usage, error class, and downstream outcome. Evaluate representative, adversarial, multilingual, long-context, and multimodal cases before release, including whether the rendered Prompt leaks data, overrides policy, selects unnecessary Tools, or degrades task quality. A successful prompts/get proves only that the Server returned valid messages, not that they are trusted, effective, or approved for execution.

Key Characteristics

• User-controlled selection: the user chooses when to use a server-authored Prompt, while the Host controls model submission and policy
• Discoverable message contract: prompts/list advertises names and string Argument metadata, and prompts/get renders user or assistant Messages
• Rich but bounded content: Text, Image, Audio, Resource Link, and Embedded Resource blocks require MIME, byte, token, and provenance controls
• List-only protocol caching: catalog results carry TTL and public/private scope, while rendered prompts/get results are not protocol-cacheable
• Stateless continuation: prompts/get can use MRTR input_required with integrity-protected requestState instead of server-initiated requests
• Instruction supply-chain surface: descriptors, Arguments, Resources, rendered Messages, model mapping, and template revisions require review and evaluation

Common Use Cases

1. Offer a user-selected code review workflow that references an authorized diff and keeps Tool execution separately approved
2. Render an incident-analysis conversation with scoped log Resources, explicit evidence instructions, and a strict context budget
3. Provide a multilingual documentation template whose locale and audience strings are validated before message generation
4. Guide a database investigation with permission-filtered schema suggestions without turning the Prompt into a query-execution Tool
5. Distribute versioned team workflows across compatible Clients while recording the exact template, model, and policy used in evaluation

Frequently Asked Questions

Related Tools

Related Terms

Related Articles