MCP Prompts Explained

An MCP prompt is a reusable, server-defined message template that a user picks on purpose, often as a slash command like /code_review. The client asks the server for the prompt with prompts/get, passes any arguments, and gets back ready-to-use messages for the AI model.

Status in the 2026-07-28 spec: core. Prompts are one of the three server features, with tools and resources. A server opts in by declaring the prompts capability.

Prompts are the least known of the three features, but they are useful. They let a server owner package expert instructions once, so every user gets the same good starting point. This page is based on the 2026-07-28 Prompts page, checked on 28 October 2026.

What a prompt is

The spec says prompts let servers "provide structured messages and instructions for interacting with language models." Clients can discover them, fetch their contents and pass arguments to customize them.

A prompt definition has:

• name: the unique identifier, such as code_review.
• title: an optional display name.
• description: optional text explaining what it does.
• arguments: an optional list, each with a name, description and required flag.
• icons: optional images for the interface.

Why prompts exist

The three server features differ by who is in control:

The spec explains that "user-controlled" refers to "who decides when the prompt is used, not who authors its content. Prompt content is defined by the server." Its main example is a slash command in the chat box.

For a business, prompts are a way to share best practice. A reporting server might offer a "weekly sales summary" prompt that already knows which data to pull and how to format it. Users do not have to write that instruction themselves.

How it works

Listing prompts

The client sends prompts/list. The result supports pagination and includes caching hints. The spec's example lists a code_review prompt with one required argument, code.

Getting a prompt

The client sends prompts/get with the prompt name and argument values. This is the spec's example response:

{
  "jsonrpc": "2.0",
  "id": 2,
  "result": {
    "resultType": "complete",
    "description": "Code review prompt",
    "messages": [
      {
        "role": "user",
        "content": {
          "type": "text",
          "text": "Please review this Python code:\ndef hello():\n    print('world')"
        }
      }
    ]
  }
}

Each message has a role of user or assistant. That lets a prompt include example turns, not just one instruction. The client then sends these messages to the model.

Message content

Prompt messages support the same content types as tool results: text, images, audio, resource links and embedded resources. Images and audio must be base64-encoded with a valid MIME type. Embedded resources let a prompt pull in server-managed content, such as documentation, directly.

Auto-completing arguments

The spec says prompt arguments "may be auto-completed through the completion API." A client can suggest values as the user types. See MCP argument completion.

Asking for more input

New in 2026-07-28, a server may answer prompts/get with resultType: "input_required". The client gathers the requested input and retries with inputResponses. This is the multi-round-trip request pattern.

When prompts change

If the server declared listChanged, it should send notifications/prompts/list_changed. In 2026-07-28, that goes to clients that opened a subscriptions/listen stream with promptsListChanged: true.

What changed across spec versions

The 2024-11-05 page said servers declare the prompts capability "during initialization." In 2026-07-28 there is no initialization. The capability appears in the result of server/discover. See MCP capabilities explained.

Common mistakes

1. Using a prompt where a tool fits. A prompt only returns messages. It does not run anything on the server's systems by itself.
2. Skipping argument checks. Servers SHOULD validate arguments. Missing required arguments or an unknown prompt name should return -32602.
3. Pasting user input straight into instructions. The spec says implementations MUST validate prompt inputs and outputs "to prevent injection attacks or unauthorized access to resources." See prompt injection through MCP.
4. Embedding data the user should not see. An embedded resource in a prompt is still data from your server. Apply the same access checks you use for resources/read.
5. Assuming every client shows prompts. Client support varies, so do not hide core features behind prompts alone.

Our Learn MCP lesson on adding prompts shows how to build one.

Next step

Prompts become easier to use when the client can suggest argument values. Read MCP argument completion next, or return to the MCP specification reference.

Frequently asked questions