MCP has three primitives: tools, resources, and prompts. If you have built or used MCP servers before, you probably know tools well. You may have seen resources. Prompts are the third primitive, and they solve a problem the other two do not.
Tools let agents take actions. Resources let agents read data. Prompts let servers package up structured interactions — multi-step workflows, pre-built templates, guided conversations — that agents or users can invoke without having to construct the right sequence of messages from scratch.
The core idea
An MCP prompt is a reusable template defined by a server and surfaced to the client. Each prompt has a name, a description, and an optional set of arguments. When invoked, it returns a sequence of messages that the client inserts into the conversation.
A database MCP server might expose a prompt called explain-query that takes a SQL statement as an argument and returns a structured set of messages asking the model to analyze the query plan, flag performance risks, and suggest indexes. The user does not need to know how to write that prompt. The server packages the expertise.
This is different from tools in an important way. Tools are model-controlled — the AI model decides when to call them based on the conversation. Prompts are user-controlled. The client presents them as slash commands, menu items, or quick actions. A human picks the prompt, fills in any arguments, and the client injects the resulting messages into the conversation.
How prompts work
A server declares its prompts through two endpoints.
Listing prompts. The client calls prompts/list and the server returns an array of available prompts. Each entry includes a name, a human-readable description, and a list of arguments with their types and whether they are required.
{
"prompts": [
{
"name": "explain-query",
"description": "Break down a SQL query and suggest optimizations",
"arguments": [
{
"name": "sql",
"description": "The SQL query to analyze",
"required": true
}
]
}
]
}Getting a prompt. When the user selects a prompt, the client calls prompts/get with the prompt name and any argument values. The server returns a list of messages, each with a role (user or assistant) and content.
{
"messages": [
{
"role": "user",
"content": {
"type": "text",
"text": "Analyze this SQL query for performance issues:\n\nSELECT * FROM orders JOIN customers ON orders.customer_id = customers.id WHERE orders.created_at > '2026-01-01'"
}
},
{
"role": "assistant",
"content": {
"type": "text",
"text": "I'll analyze this query across three dimensions: execution plan, indexing, and potential rewrites."
}
}
]
}The client takes those messages and adds them to the conversation. The model then continues from where the prompt left off. By including an assistant message, the prompt can steer the model toward a specific approach without relying on the user to write the right instructions.
When to use prompts vs tools vs resources
The three primitives serve different roles:
| Primitive | Who controls it | What it does | Example |
|---|---|---|---|
| Tools | The AI model | Executes actions, returns results | run_query, send_email, create_file |
| Resources | The application | Exposes readable data | file:///src/app.ts, db://users/schema |
| Prompts | The user | Provides structured interaction templates | explain-query, review-code, draft-migration |
Use prompts when:
- You want to give users a pre-built workflow they can trigger on demand
- The interaction requires a specific multi-message setup to get good results
- You are packaging domain expertise into a reusable pattern
- You want to combine resource data with a structured analysis request
Prompts can reference resources through embedded resource URIs. A code review prompt might pull in the contents of a file through a resource reference and then structure the review around specific criteria. This lets servers compose primitives: a resource provides the data, a prompt structures the analysis, and the model uses tools if it needs to take action based on its findings.
Prompts in practice
Here is a practical example. A Git MCP server could expose three prompts:
summarize-changes — Takes a branch name, pulls the diff through a resource, and returns messages asking the model to summarize changes grouped by area of the codebase.
review-pr — Takes a PR number, pulls the diff and any linked issues, and returns a structured review template covering correctness, test coverage, and style.
draft-release-notes — Takes a version tag and returns messages that guide the model through writing release notes from the commit log.
Each of these captures a workflow that would otherwise require the user to write a detailed prompt every time. The server author writes it once. Every user of that server gets the same structured interaction.
Dynamic prompts
Prompts do not have to be static. The argument values passed by the user can change the structure and content of the returned messages. A review-code prompt might return different review criteria depending on whether the language argument is python or rust. A generate-tests prompt might adjust its approach based on whether the testing framework is jest or pytest.
Servers can also notify clients when their available prompts change using the notifications/prompts/list_changed notification. This is useful for servers that generate prompts dynamically based on the current project state, available data, or user configuration.
Building prompts into your MCP server
If you are building an MCP server and want to add prompts, the implementation is straightforward. Declare the prompts capability when initializing, implement a handler for prompts/list that returns your prompt catalog, and implement a handler for prompts/get that accepts argument values and returns the message array.
The key design decision is what to make a prompt vs what to make a tool. If the agent should decide on its own when to use it, make it a tool. If a human should consciously choose to invoke it, make it a prompt. Many servers benefit from having both: tools for the actions the agent takes autonomously, and prompts for the structured workflows a user kicks off intentionally.
FAQ
Q: Can prompts call tools or read resources? A: Prompts themselves do not call anything. They return messages that get added to the conversation. Those messages can reference embedded resources, and the model can then decide to call tools based on the prompt context. Think of prompts as setting up the conversation, not executing logic.
Q: How do clients present prompts to users? A: That depends on the client. Claude Desktop and similar tools typically show prompts as slash commands or in a command palette. Other clients might use buttons, menus, or keyboard shortcuts. The MCP specification defines the data format but leaves presentation to the client.
Q: Are prompts required for an MCP server? A: No. Prompts are optional. Many MCP servers only expose tools, or tools and resources. Add prompts when you have structured workflows that benefit from a pre-built template. If your server just exposes actions and data, tools and resources are sufficient.