Tools and resources get most of the attention in MCP discussions, but prompts are the third primitive, and they solve a genuinely different problem — packaging a reusable, parameterized prompt template on the server side so clients don't need to hand-craft the same well-tuned instructions repeatedly.
MCP prompts are reusable, parameterized prompt templates defined by a server and exposed to clients — a way to package a well-designed prompt (with specific instructions, structure, and possibly embedded resource references) that a client can invoke with specific arguments, rather than every client having to independently craft the same prompt from scratch.
Why MCP Prompts Matter (and When Plain Instructions Suffice)
For workflows the server's maintainer understands well — a specific code review checklist, a structured incident report format, a particular data analysis approach — defining that as a reusable prompt means every client benefits from a carefully designed template, rather than each client (or each user) independently reinventing and likely under-specifying the same instructions.
Plain, ad hoc instructions suffice for one-off, conversational requests that don't benefit from a reusable, standardized structure — prompts earn their value specifically for repeated, well-understood workflows where consistency and quality of the underlying instructions genuinely matters.
Getting Started with MCP Prompts
Defining a parameterized prompt template:
server.prompt(
"code-review",
{ language: z.string(), focusArea: z.string().optional() },
({ language, focusArea }) => ({
messages: [
{
role: "user",
content: {
type: "text",
text: `Review this ${language} code${focusArea ? ` with a focus on ${focusArea}` : ""}. Check for correctness, security issues, and readability. Be specific about line numbers and concrete fixes.`,
},
},
],
})
);
A client invokes the prompt with specific arguments, receiving the fully-formed message(s) back to use in a conversation.
Core MCP Prompts Concepts Every Developer Should Know
Prompts are explicitly invoked by the user or client, not autonomously selected by the model — similar to resources in this respect, and different from tools, which the model decides to call based on its own reasoning. A prompt typically shows up as something like a slash command or menu option a user deliberately selects.
Prompts can embed references to resources, combining a template's instructions with specific data the server has access to — letting a single prompt invocation pull in both a well-crafted instruction template and relevant context data in one step, rather than requiring the client to separately fetch resources and construct the prompt.
Argument schemas work the same way as tool parameter schemas, using structured definitions (often Zod or equivalent) to specify what arguments a prompt accepts — giving clients a way to discover what parameters a prompt needs and validate them before invocation, the same correctness benefit precise schemas provide for tools.
Prompts are a server-side investment in prompt engineering quality, meaning the server maintainer's expertise in crafting effective instructions for a specific task gets distributed to every client that uses the prompt — this is the core value proposition, distinct from tools (actions) and resources (data).
Common Mistakes Using MCP Prompts and How to Fix Them
Mistake 1: not using prompts for genuinely repeated, well-understood workflows, leaving each client/user to independently reconstruct the same instructions with inconsistent quality. Fix: identify recurring, well-defined tasks your server's domain involves, and package them as prompts rather than leaving them as tribal knowledge.
Mistake 2: overly generic prompt templates that don't add real value over the user just typing their own request. Fix: invest actual prompt engineering effort into templates — specific instructions, relevant structure, embedded resource references — that meaningfully outperform an ad hoc request.
Mistake 3: not documenting what a prompt is for clearly enough for a client/user to know when to use it. Fix: give prompts clear names and descriptions, the same discoverability consideration that applies to tools and resources.
When Should You Define a Prompt Instead of Just Relying on the User's Own Instructions?
Define a prompt when a task recurs often enough, and prompt quality matters enough, that packaging a well-tested template provides real, repeated value over ad hoc instructions — code review checklists, structured report formats, domain-specific analysis workflows. Rely on the user's own ad hoc instructions for genuinely one-off, exploratory, or highly context-dependent requests where a fixed template wouldn't fit well or add value.
MCP Prompts in Production
Invest real prompt engineering effort into any defined prompt template, since its value depends entirely on being meaningfully better than what a user would type themselves — a low-effort generic template isn't worth the added primitive. Also give prompts clear, discoverable names and descriptions so clients and users actually find and use them for the workflows they're designed for.
If your MCP server's domain has recurring, well-understood tasks currently left to ad hoc user instructions, defining them as prompts is a concrete way to raise the consistency and quality of how clients approach those tasks.