Wiki · Concept · Last reviewed June 25, 2026

MCP Prompts

MCP prompts are the Model Context Protocol server feature for exposing reusable prompt templates and structured messages that clients can discover, display, customize, and retrieve.

Category: Concept Published: June 25, 2026 Modified: June 25, 2026 Last reviewed: June 25, 2026 Tags: MCP, Prompts, AI Agents, Context, Governance

Definition

MCP prompts are a server feature in the Model Context Protocol that lets servers expose prompt templates to clients. The 2025-11-25 specification describes prompts as structured messages and instructions for interacting with language models. A client can discover available prompts, retrieve a selected prompt, and supply arguments that customize the returned messages.

A prompt in this sense is not merely a string pasted into a chat box. It is a protocol object with a name, optional display title, optional description, optional icon metadata, and optional arguments. That makes it a reusable interface between a server's domain knowledge and a user's model session.

How It Works

A server that supports prompts declares the prompts capability during MCP initialization. The capability can include listChanged, which indicates that the server will notify clients when its available prompt list changes. The MCP lifecycle page places prompts among server capabilities that are negotiated before normal operation, alongside resources, tools, logging, completions, and other server features.

Clients discover prompts with prompts/list, which supports pagination. A prompt definition can include a unique name, optional title, optional description, optional icons, and an optional list of arguments. A client retrieves one prompt with prompts/get, passing the prompt name and any argument values. The specification also notes that arguments may be auto-completed through the completion API.

If a server declared listChanged, it should send notifications/prompts/list_changed when the prompt list changes. Error handling is ordinary JSON-RPC error handling: the prompts page lists invalid prompt names and missing required arguments as invalid-params cases, and internal failures as internal errors.

Message Shapes

The result of prompts/get can include a description and a list of prompt messages. Each prompt message has a role, either user or assistant, and content. The content may be text, image, audio, or an embedded resource. Image and audio content use base64-encoded data with a MIME type. Embedded resources reference server-managed content using a resource URI, MIME type, and either text content or encoded binary content.

This gives prompts more expressive power than a plain instruction template. A server can return a structured conversation starter, include example assistant messages, attach multimodal context, or embed documentation and code samples as resources. The same capability also creates a larger review surface: a prompt can quietly import context, examples, and role framing that shape a model response before the user sees the final answer.

Governance Requirements

A governed deployment should treat MCP prompts as change-controlled artifacts. The record should preserve the server identity, prompt name, version or hash if available, displayed title, description, argument schema, supplied arguments, returned message roles, content types, embedded resource URIs, user who selected the prompt, timestamp, client, model route, and whether the returned messages entered a model context window.

Prompt catalog changes should be reviewed like changes to tool schemas or access policy. A title such as "Summarize Contract" may hide instructions about legal tone, risk thresholds, examples, or external resources. The client should show enough detail for users and auditors to understand what instruction bundle is being invoked, not only a friendly command name.

Failure Modes

Template authority drift. A prompt becomes treated as institutional policy even though it is only a server-provided template.

Argument injection. User-supplied arguments are interpolated into prompt messages without validation, creating an instruction-confusion path. The MCP prompts specification explicitly requires careful validation of prompt inputs and outputs to prevent injection attacks or unauthorized resource access.

Hidden embedded context. A prompt includes embedded resources that change the model's working context without the user understanding what data entered the session.

List-change ambiguity. A prompt name stays stable while the actual returned messages change, leaving saved workflows and audit records unable to explain why behavior shifted.

Source Discipline

Claims about MCP prompts should cite the versioned prompts specification and distinguish prompt discovery, prompt retrieval, prompt arguments, message content types, and list-change notifications. Security claims should cite the prompt page's validation requirement and broader MCP security guidance rather than treating prompt templates as harmless because they do not execute code by themselves.

Spiralist Reading

MCP prompts are liturgy for agent infrastructure: repeatable forms of address that shape how a model enters a task. They can be useful because they give users a shared interface for recurring work. They can be dangerous because repetition hardens into authority.

The Spiralist question is not whether a prompt is clever. It is whether the prompt's authorship, purpose, boundary, and revision history remain visible after the model starts speaking in the user's name.

Open Questions

Sources

Return to Wiki