Prompts in MCP are reusable message templates exposed by the server. They are useful when domain expertise should travel with a capability surface instead of being reimplemented separately in every host.
The key is to treat prompts as templates for interaction, not as enforcement mechanisms.
A prompt is a reusable contract for how to ask a model to perform a known kind of work. It packages domain phrasing, expected inputs, and sometimes embedded resources, but it does not itself execute backend actions.
Prompts help hosts and users initiate common workflows consistently. A security team may want a standard prompt for reviewing an incident timeline. A support team may want one for drafting customer-facing updates from internal notes.
That consistency is valuable because it keeps domain-specific phrasing close to the team that owns the domain. The host no longer needs to recreate every high-quality prompt template itself.
Current MCP prompts can declare arguments and return message arrays. Those messages may contain text, images, audio, or embedded resources. That means prompts can carry both instructions and the exact context the prompt expects the model to see.
Embedded resources are especially helpful when the server owns canonical content that should be inserted into the prompt without requiring the host to assemble it manually.
Prompts should not hide policy or override authorization. If a prompt says, "Summarize this confidential report," the server still needs to control whether the caller is allowed to access that report in the first place.
Likewise, prompts should not replace tools. If the task requires creating a ticket or writing a file, use a tool for execution and use prompts only to structure the interaction around it.
An MCP prompt should package a repeatable user intent into a clear contract. It can collect arguments, assemble instructions, include resource references, and guide a host toward a consistent workflow. It should not hide policy, bypass authorization, or pretend that prompt wording is a security boundary.
The best prompts read like product features. A "summarize incident" prompt should explain the required incident identifier, the expected output structure, the sources that may be used, and the limits of the result. A "prepare release notes" prompt should specify audience, repository range, risk notes, and whether unresolved tickets should be included.
Keep prompt arguments typed and minimal. If a prompt needs ten optional fields, it may be trying to become a tool. If it changes backend state, it definitely should be a tool with validation and authorization. Prompts are strongest when they orchestrate language work around approved context.
Review MCP prompts the same way you review public API contracts. Ask whether the prompt is understandable, stable, permission-safe, and testable. Run it against happy-path cases, missing-context cases, adversarial resource content, and ambiguous user requests.
A prompt should degrade clearly. If required context is unavailable, it should tell the host or user what is missing rather than inventing. If a resource contains conflicting evidence, it should surface the conflict. If the task requires a privileged action, it should stop before action and route to an explicit tool or approval flow.
A production MCP prompt should define more than a block of instructions. It should define the expected arguments, where context may come from, what the output should contain, and what the prompt should do when evidence is missing. This makes prompts testable rather than mystical.
Think of a prompt as a reusable workflow template that a user or host can intentionally invoke. The prompt should explain its purpose in human language, accept only the arguments it needs, and avoid hidden dependencies. If the prompt assumes a policy document, incident record, or repository range, make that dependency explicit.
Prompts should also be versioned when behavior changes. Changing the output format, citation requirements, or refusal criteria can break host UI and downstream automation. Versioning gives teams a way to migrate safely rather than discovering prompt drift after users complain.
Most importantly, prompts do not grant authority. If a prompt says to summarize a confidential record, the server still needs resource authorization. If a prompt recommends a write action, an actual tool and approval flow should enforce execution rules.
Prompt testing should include ordinary user requests, missing arguments, contradictory sources, malicious source text, and insufficient evidence. A prompt that only works with perfect inputs will fail the first time it meets real enterprise data.
The test output should be checked for structure, tone, citations, safety behavior, and truthful uncertainty. If the prompt is supposed to create release notes, it should not invent changes. If it is supposed to summarize incidents, it should separate facts from hypotheses. If it is supposed to ask clarification, it should not guess silently.
Hosts may render prompts as slash commands, menu items, or workflow shortcuts. That means prompt names and descriptions are part of user experience. A user should understand when to choose the prompt and what information it will use.
When prompts become too complex, split them or move logic into tools. A prompt is a guide for language behavior; it is not a replacement for deterministic validation, data access, or backend workflow.
For each MCP prompt, write down the task it supports, the arguments it accepts, the resources it expects, the output it should produce, and the cases where it should refuse or ask for clarification. If this cannot be written clearly, the prompt is probably too broad.
Run the prompt with missing arguments, conflicting sources, irrelevant context, and malicious text embedded in a resource. The prompt should preserve the workflow goal without treating untrusted content as authority.
Also review host presentation. If the prompt appears as a command or menu item, the name and description should help users choose correctly. A powerful prompt with a vague label will be misused.
import { z } from 'zod';
server.registerPrompt(
'summarize_policy_for_employee',
{
title: 'Summarize Policy for Employee',
description: 'Summarize a policy in plain language for a named employee role.',
argsSchema: {
policyText: z.string(),
employeeRole: z.string(),
},
},
({ policyText, employeeRole }) => ({
messages: [
{
role: 'user',
content: {
type: 'text',
text: `Summarize the following policy for a ${employeeRole}:\n\n${policyText}`,
},
},
],
})
);server.registerPrompt(
'review_runbook',
{
title: 'Review Runbook',
description: 'Ask the model to review a runbook resource for clarity and missing steps.',
},
async () => ({
messages: [
{
role: 'user',
content: {
type: 'resource',
resource: {
uri: 'runbook://sev1/database-failover',
mimeType: 'text/markdown',
text: await loadRunbook('sev1/database-failover'),
},
},
},
],
})
);Not always. Many hosts expose them to users directly, but hosts may also apply them as part of a structured workflow.
Yes. The TypeScript SDK supports argument completion patterns for prompts and resources.
Explore 500+ free tutorials across 20+ languages and frameworks.