Create reusable prompts that structure how the model interacts with your server.
In the context of MCP, prompts are instruction templates that the server offers the model. They differ from tools (which perform actions) and resources (which provide data). Prompts structure such as the model should think and respond in specific scenarios, using the decorator @mcp.prompt() to register them on the server.
A MCP prompt is a reusable template that defines instructions for the model. While tools perform concrete actions (fetching data, sending messages) and resources expose static data (files, settings), prompts define interaction patterns — how the model should analyze code, generate reports, or format responses. The decorator @mcp.prompt() registers a Python function as a prompt available on the server, which the client can list and invoke.
Think of prompts as predefined recipes for the model. Instead of the user writing "analyze this code focusing on bugs, performance, and readability" every time, the server offers a ready-made "review_code" prompt. The client selects the prompt, the server returns the formatted instructions, and the model knows exactly what to do. It’s knowledge reuse in the form of instructions.
The most basic prompt is a function decorated with @mcp.prompt() that returns a string. This string contains the instructions that will be sent to the model. Simple, direct, and powerful — just define the function and MCP takes care of the rest.
Creating a simple prompt requires only the decorator and a function that returns a string:
The function name (revisar_codigo) becomes the prompt identifier. The docstring becomes the description. The returned string becomes the prompt content sent to the model.
Static prompts are useful, but their real power emerges when you add dynamic parameters. Using Python type hints, MCP automatically detects the parameters and exposes them to the client, which can fill them in before invoking the prompt.
Parameters are defined as function arguments with type hints:
MCP uses type hints to tell the client which parameters are expected. The client presents fields for the user to fill in (e.g., type="sales", period="Q1 2025") before invoking the prompt.
Use descriptive names for the parameters— tipo e periodo are better than t e p. The client displays these names to the user, so clarity matters. If a parameter is optional, use Optional[str] = None as a type hint.
The client lists the available prompts and sees "gerar_relatorio" with parameters tipo (str) and periodo (str).
The user fills in the parameters: type="sales", period="March 2025".
The server runs the function, substitutes the parameters in the string, and returns the completed prompt to the model.
The MCP client can request a list of all prompts available on the server, including their names, descriptions, and parameters. This lets user interfaces display a catalog of available prompts, making the experience intuitive and self-documenting.
The MCP protocol defines the method prompts/list that returns all prompts registered on the server. For each prompt, the client receives: the name (derived from the function name), the description (derived from the function's docstring) and the list of parameters (derived from the type hints). This means the prompt documentation is generated automatically from the Python code — there is no need to maintain separate documentation.
What the client receives when listing prompts:
MCP prompts shine when you have interaction patterns that repeat frequently. Instead of each user writing their own instructions (often inconsistently), the server offers standardized, tested prompts that ensure high-quality results.
The best MCP prompts encapsulate domain expertise in reusable templates. A code analysis prompt can include criteria a senior developer would use. A report prompt can follow the company's official format. The idea is to turn tacit knowledge into explicit, shareable instructions, allowing any user to get expert-level results.
A prompt that instructs the model to review code, focusing on bugs, security, performance, and readability — using the team’s standardized checklist.
A parameterized prompt that generates reports in a specific format with metrics, suggested charts, and actionable recommendations.
A prompt that transforms raw data into formatted tables, structured JSON, or CSV — with built-in validation rules.
A prompt that generates professional emails following the company’s tone and format, with parameters for recipient, subject, and context.
A prompt that analyzes technical documentation for clarity, completeness, examples, and consistency with project standards.
Before making prompts available for production use, it's essential to test them. The MCP Inspector lets you list all the server's prompts, view expected parameters, and invoke prompts manually to verify that the generated instructions are correct and complete.
O MCP Inspector is the ideal tool for testing prompts. In the “Prompts” tab, it lists all registered prompts along with their names, descriptions, and parameters. You can fill in the parameters and click “Get Prompt” to see exactly what will be sent to the model. This lets you validate that the instructions are complete, the parameters are substituted correctly, and the format is appropriate—all without needing to connect to Claude Desktop.
Test each prompt with edge cases: empty strings, very long text, special characters. Check that the prompt handles edge cases well. If a parameter is optional, test with and without it. If the prompt uses f-strings, confirm that interpolation works correctly in all expected scenarios.
Prompts don't validate parameters automatically — if the client sends an empty string for a required parameter, the prompt will be generated with a blank space. Always validate the parameters inside the function before building the return string. Use if not tipo: raise ValueError("tipo é obrigatório") to ensure invalid data doesn't pass through silently.
@mcp.prompt() — different from tools and resources.
Next Module: 3.8 — Error Handling