MCP Prompt

The core of an MCP prompt is its template text, which contains placeholder variables (e.g., {{user_query}}, {{current_date}}). These variables are defined in the prompt's input schema. When a client requests the prompt, it provides concrete values for these variables, which the server uses to render the final, executable instruction string for the language model. This enables dynamic, context-aware prompt generation without hardcoding logic into the client application.

Every MCP prompt is defined with a strict JSON Schema that specifies the required input parameters for rendering the template. This schema:

• Defines the names and data types (string, number, array, object) of all variables.
• Can enforce validation rules like required fields, string patterns, or value ranges.
• Provides descriptions for each parameter, guiding the client on what value to supply. The client must provide arguments that conform to this schema for a successful prompt rendering request.

An MCP prompt is identified and described by essential metadata exposed by the server:

• Name: A unique, machine-readable identifier for the prompt (e.g., summarize_document).
• Description: A human-readable explanation of the prompt's purpose and when to use it (e.g., "Generates a concise summary of a provided text document"). This metadata is published during the initial capability negotiation and allows clients to discover and select the appropriate prompt from the server's available offerings.

MCP servers expose prompts through two standard JSON-RPC methods defined by the protocol:

• prompts/list: Called by a client to retrieve a catalog of all available prompts from the server, including their names, descriptions, and input schemas.
• prompts/get: Called by a client to render a specific prompt. The client provides the prompt name and the required arguments. The server validates the inputs against the schema, renders the template, and returns the final text string ready for the LLM.

A key architectural benefit of MCP prompts is the separation of prompt engineering logic from the client application. The complex template logic, few-shot examples, and formatting instructions reside on the MCP server. The client only needs to know the prompt's name and required parameters. This allows for:

• Centralized prompt versioning and updates.
• A/B testing of different prompt templates without client redeployment.
• Domain-specific prompt libraries managed by subject matter experts, accessible to any MCP-compatible client.

MCP prompts are designed to work in concert with other MCP capabilities. A common pattern is:

1. Client uses an MCP Resource (e.g., file:///reports/q3.md) to fetch data.
2. Client uses an MCP Tool (e.g., search_database) to retrieve additional information.
3. Client calls an MCP Prompt (e.g., generate_report), providing the fetched resource contents and tool results as variable inputs. This creates a powerful workflow where the prompt synthesizes dynamically retrieved context, enabling the LLM to act on live, external data.

A Prompt Template is the core structure of an MCP Prompt. It is a text blueprint containing placeholder variables (e.g., {{user_query}}, {{current_date}}). When a client requests the prompt, it provides values for these variables, which the server uses to render a final, contextualized instruction or query for the language model. This enables dynamic, reusable prompt logic without hard-coding context into the client application.

An MCP Server is the process that hosts and serves MCP Prompts (along with tools and resources). It implements the MCP specification, listening for client connections over a defined transport. The server is responsible for:

• Advertising available prompts via the prompts/list method.
• Rendering a specific prompt template with client-provided arguments via prompts/get.
• Managing the lifecycle and security of the prompt logic and any associated data sources.

An MCP Client is the AI application (e.g., an AI assistant interface) that connects to MCP Servers. It discovers available prompts and requests their rendering by supplying the necessary variable values. The client integrates the finalized prompt text into the language model's system instruction or user query, effectively using the server as a dynamic prompt engineering backend. Clients manage connections to multiple servers via a Context Directory.

Context Injection is the broader pattern that MCP Prompts facilitate. It refers to the process of dynamically inserting relevant, real-time information into a model's context window. While MCP Prompts inject pre-formatted instructions, the same protocol allows for injecting raw data via MCP Resources (e.g., file contents, database records) and live results from MCP Tools. This creates a Dynamic Context that grounds the model's responses in current, verifiable data.

While an MCP Prompt provides a static template for a query, an MCP Tool defines an executable function. Their relationship is complementary: a prompt might guide the model on when and how to use a tool. A Tool Definition specifies the tool's name, description, and a strict JSON Schema for its input parameters. Tool Invocation is the client's request to execute that tool, with arguments validated by Schema Validation. Tools enable actions, whereas prompts guide reasoning about those actions.