Prompts: Reusable, Server-Defined Templates

Recall Module 6’s own closing promise — Prompts complete the three real capability types. Recall your prompt engineering coursework’s own core lesson: the same real prompt, rewritten slightly differently in three separate places, is a genuine, recurring problem. An MCP Prompt is a predefined, reusable prompt template a Server exposes, so real, tuned prompting logic lives in exactly one place, usable by any real, connected Client.

Your first real, exposed prompt

Let’s build one directly, using the same, familiar FastMCP pattern.

We’ll expose a genuine, reusable code review prompt — real, tuned wording, defined once.

from fastmcp import FastMCP

mcp = FastMCP("dev-tools-server")

@mcp.prompt()
def code_review(code: str, language: str = "python") -> str:
    """A real, reusable prompt for reviewing a code snippet."""
    return (
        f"You are a senior {language} engineer. Review this code for real, "
        f"genuine bugs, security issues, and style problems:\n\n{code}"
    )

Notice @mcp.prompt() — a real, third decorator, distinct from @mcp.tool() and @mcp.resource(). Any real Client connected to this Server can now request this exact, tuned prompt, without ever needing to know or reproduce its actual wording.

A real document summarization prompt

Let’s build a genuinely different, second real prompt, showing the same pattern applied to another common, real task.

We’ll expose a prompt template specifically tuned for real, consistent summarization behavior.

@mcp.prompt()
def summarize_document(document: str, max_sentences: int = 3) -> str:
    """A real, reusable prompt for summarizing a document consistently."""
    return (
        f"Summarize the following document in exactly {max_sentences} sentences, "
        f"focusing only on real, concrete facts, not opinions:\n\n{document}"
    )

A real, enterprise-specific workflow prompt

Let’s build something closer to genuine, real business logic — a prompt encoding an actual, specific company workflow.

We’ll expose a prompt that enforces a real, deliberate business process, not just a generic instruction.

@mcp.prompt()
def draft_refund_response(customer_name: str, order_id: str, eligible: bool) -> str:
    """A real, company-specific prompt for drafting a refund response, following our actual tone guidelines."""
    if eligible:
        return (
            f"Write a warm, professional email to {customer_name} confirming their refund "
            f"for order {order_id} has been approved and will process within 5-7 business days."
        )
    return (
        f"Write a warm, professional email to {customer_name} explaining that order {order_id} "
        f"is outside our 30-day return window, while offering a genuine, real alternative — store credit."
    )

Notice this genuinely encodes real, specific company policy — the exact tone, the exact real timeline, the exact real fallback offer — directly into the reusable template, rather than leaving every real, calling application to reinvent this business logic on its own.

Why this matters, precisely, at real, protocol scale

Recall this module’s own opening lesson from your prior coursework — a prompt rewritten slightly differently across separate places is a genuine, recurring problem. Here’s the complete, real picture, now that all three capability types are on the table together.

flowchart LR
    A[Tool] --> A1["Does something\n(action, side effects)"]
    B[Resource] --> B1["Is something\n(read-only data)"]
    C[Prompt] --> C1["Says something\n(reusable text, for an LLM)"]

MCP Prompts solve the real, recurring duplication problem at a genuinely larger, real scale: instead of one team’s prompts staying consistent across one codebase, a Server’s prompts stay consistent across every real, different application that connects to it — a different team, a different company, a different agent framework, all genuinely using the identical, tuned wording.

Prompt discovery, the same real, consistent pattern

Recall Modules 5 and 6’s own tools/list and resources/list — Prompts use the exact same, real discovery shape.

# the real, actual shape of a prompts/list request
list_prompts_request = {"jsonrpc": "2.0", "id": 4, "method": "prompts/list"}

list_prompts_response = {
    "jsonrpc": "2.0",
    "id": 4,
    "result": {
        "prompts": [
            {"name": "code_review", "description": "A real, reusable prompt for reviewing a code snippet.", "arguments": [{"name": "code", "required": True}, {"name": "language", "required": False}]},
        ]
    },
}

Common mistakes worth avoiding

Treating a Prompt as if it were a Tool. Recall this course’s own real, capability distinction — a Prompt genuinely returns text, meant to be sent to an LLM; it never performs an action or returns raw data the way a Tool or Resource does.

Hardcoding business-specific wording directly into every calling application, instead of exposing it as a Prompt. Recall this module’s own real refund example — that logic belongs on the Server, once, so every real, connected application gets the identical, tuned behavior automatically.

Writing a Prompt with no real, meaningful parameters. Recall this module’s own three, real examples — each one genuinely takes real arguments, letting the same template adapt to real, different situations, rather than being a single, rigid, hardcoded string.

What you should take away from this module

• An MCP Prompt is a predefined, reusable, server-defined prompt template — recall your own prompt engineering coursework’s real “single source of truth” lesson, now applied at protocol scale.
• @mcp.prompt() is the real, third decorator, distinct from Tools and Resources — it returns text meant for an LLM, not an action’s result or raw data.
• A Prompt can genuinely encode real, specific business logic — tone, timelines, fallback offers — kept consistent across every real, connected application.

Where this goes next

With all three real capability types covered — Tools, Resources, and Prompts — the next module covers Transports: the actual, real communication channel connecting a Client and Server, including a genuine, honest look at a transport that’s already been deprecated.