How to Add MCP Prompts to a Server

MCP prompts give your server a way to package repeatable workflows for AI clients. Tools let an agent take an action. Resources let an agent read context. Prompts sit one layer above both: they tell the client how to start a task with the right instruction shape, optional arguments, and domain-specific framing.

If your MCP server supports a workflow that users ask for again and again, add a prompt. A prompt can start a code review, summarize a support ticket, draft a release note, triage logs, or guide an agent through a known internal process. This guide shows how to add prompts to a Python FastMCP server, test them locally, and decide when a prompt belongs on the server instead of in a user’s chat history.

Prerequisites

You should have:

• Python 3.10 or later
• uv installed
• A basic MCP server using the Python SDK
• Claude Desktop or the MCP inspector for testing

If you need the first-server setup, start with How to Build Your First MCP Server in 30 Minutes (Python). If you want the concept first, read What Are MCP Prompts?.

1. Create a small FastMCP server

Start with a clean project:

mkdir mcp-prompt-demo && cd mcp-prompt-demo
uv init
uv add "mcp[cli]"

Create server.py:

from mcp.server.fastmcp import FastMCP

mcp = FastMCP("prompt-demo")


@mcp.tool()
def get_recent_changes(project: str) -> str:
    """Return recent changes for a project. Uses mock data for the demo."""
    return f"Recent changes for {project}: auth refactor, billing copy update, API retry fix."


if __name__ == "__main__":
    mcp.run()

This server has one tool. A client can call get_recent_changes, but it does not yet know the best way to ask for a release note, a review summary, or any other structured workflow.

2. Add a basic prompt

Add a prompt above the if __name__ == "__main__" block:

@mcp.prompt()
def release_note(project: str) -> str:
    """Draft a release note for recent project changes."""
    return f"""
Write a concise release note for {project}.

Use this structure:
1. One-sentence summary
2. User-facing changes
3. Fixes and stability improvements
4. Anything developers should know

Before writing, call get_recent_changes for {project} and base the note on those changes.
""".strip()

The decorator registers release_note as an MCP prompt. The function argument project becomes an input the client can ask for. The docstring becomes the prompt description the client shows to the user.

The result is not a tool call. It is a reusable instruction bundle. The prompt tells the agent what to do and nudges it toward the right tool.

3. Test the prompt locally

Run the MCP inspector:

uv run mcp dev server.py

Open the inspector in your browser and check the prompts section. You should see release_note listed with its description and required project argument.

Try running it with:

{
  "project": "checkout-api"
}

The inspector should return a prompt message that mentions checkout-api and instructs the client to call get_recent_changes. If the prompt does not appear, check that the function is defined before mcp.run() and that the file was saved before starting the inspector.

4. Add a prompt with stronger workflow boundaries

Prompts are most useful when they encode choices that should be consistent across users. For example, a support triage prompt can define what the agent should check, what it should not do, and what output format the team expects.

Add this second prompt:

@mcp.prompt()
def support_triage(ticket_id: str, severity: str = "normal") -> str:
    """Analyze a support ticket and suggest a safe triage path."""
    return f"""
Triage support ticket {ticket_id} with severity {severity}.

Rules:
- Identify the customer impact first.
- Separate confirmed facts from guesses.
- Do not promise refunds, credits, or account changes.
- Recommend the next internal owner.
- End with three short bullets the support agent can paste into the case notes.
""".strip()

This prompt does more than save typing. It sets a safe path for a recurring workflow. The agent still reasons through the task, but the server provides the operating frame.

5. Decide what belongs in a prompt

A good MCP prompt is narrow enough to be useful and stable enough to reuse. Use prompts for workflows like:

• Drafting release notes from recent changes
• Reviewing a pull request with a standard rubric
• Summarizing an incident in a fixed format
• Preparing a customer handoff from CRM notes
• Turning logs into a debugging checklist

Avoid prompts for one-off instructions, private user preferences, or anything that needs to change every session. Those belong in the chat, the client, or a skill system. Server prompts should describe workflows your service understands.

A useful test: if the prompt mentions your server’s tools, resources, or domain model, it probably belongs in the MCP server. If it only describes writing style, it probably does not.

6. Wire it into a client

For Claude Desktop, install the server the same way you would install any local MCP server:

uv run mcp install server.py --name "Prompt Demo"

Restart Claude Desktop. In a new conversation, look for the server’s available prompts in the MCP UI. Choose release_note, enter a project name, and confirm that the client starts the workflow with the generated instructions.

If the prompt appears but the workflow fails, test the related tools separately in the inspector. Prompts can guide a client toward a tool, but the tool still needs a clear schema, useful docstring, and valid runtime behavior.

FAQ

Are MCP prompts the same as saved chat prompts?

No. Saved chat prompts live in a client or user workspace. MCP prompts are exposed by a server and travel with the server’s capabilities. That makes them a better fit for workflows tied to server tools, resources, or business logic.

Can a prompt call a tool directly?

Not directly. A prompt returns instructions or messages for the client. The client or model decides whether to call a tool. Write the prompt so the right tool choice is obvious.

Should every MCP server include prompts?

No. If your server only exposes simple tools, prompts may add noise. Add prompts when users need a repeatable workflow, not just a function list.

What should I build next?

Pair prompts with resources. For example, expose release history as an MCP resource, expose get_recent_changes as a tool, and add a release_note prompt that tells the agent how to use both. That gives the agent context, action, and workflow framing in one server.