The Model Context Protocol (MCP) provides a standardized way for servers to expose prompt templates to clients. Prompts allow servers to provide structured messages and instructions for interacting with language models. Clients can discover available prompts, retrieve their contents, and provide arguments to customize them.
Prompts are designed to be user-controlled, meaning they are exposed from servers to clients with the intention of the user being able to explicitly select them for use.
Typically, prompts would be triggered through user-initiated commands in the user interface, which allows users to naturally discover and invoke available prompts.
For example, as slash commands:
However, implementors are free to expose prompts through any interface pattern that suits their needs—the protocol itself does not mandate any specific user interaction model.
Servers that support prompts MUST declare the prompts
capability during
initialization:
listChanged
indicates whether the server will emit notifications when the list of
available prompts changes.
To retrieve available prompts, clients send a prompts/list
request. This operation
supports pagination.
Request:
Response:
To retrieve a specific prompt, clients send a prompts/get
request. Arguments may be
auto-completed through the completion API.
Request:
Response:
When the list of available prompts changes, servers that declared the listChanged
capability SHOULD send a notification:
A prompt definition includes:
name
: Unique identifier for the prompttitle
: Optional human-readable name of the prompt for display purposes.description
: Optional human-readable descriptionarguments
: Optional list of arguments for customizationMessages in a prompt can contain:
role
: Either “user” or “assistant” to indicate the speakercontent
: One of the following content types:All content types in prompt messages support optional annotations for metadata about audience, priority, and modification times.
Text content represents plain text messages:
This is the most common content type used for natural language interactions.
Image content allows including visual information in messages:
The image data MUST be base64-encoded and include a valid MIME type. This enables multi-modal interactions where visual context is important.
Audio content allows including audio information in messages:
The audio data MUST be base64-encoded and include a valid MIME type. This enables multi-modal interactions where audio context is important.
Embedded resources allow referencing server-side resources directly in messages:
Resources can contain either text or binary (blob) data and MUST include:
Embedded resources enable prompts to seamlessly incorporate server-managed content like documentation, code samples, or other reference materials directly into the conversation flow.
Servers SHOULD return standard JSON-RPC errors for common failure cases:
-32602
(Invalid params)-32602
(Invalid params)-32603
(Internal error)Implementations MUST carefully validate all prompt inputs and outputs to prevent injection attacks or unauthorized access to resources.