Because three distinct invocation patterns matter enough to standardize separately. Tools are model-invoked (the LLM picks and calls them). Resources are host-pulled (the host enumerates and injects data). Prompts are user-invoked: reusable, parameterized templates the server registers and the host surfaces as slash commands or a template picker. The user picks a prompt by name, supplies arguments, and the server renders a structured message list for the model. Prompts encode 'I want this specific workflow now,' which is fundamentally a user decision.
MCP has a separate prompt primitive because the user-invoked invocation pattern is distinct from tools and resources, and important enough to standardize.
**An MCP prompt** is a reusable, parameterized template a server registers with the host. The host surfaces available prompts as slash commands or a template picker. The user picks one by name, fills in any arguments, and the host calls `prompts/get` to retrieve a rendered message list from the server. That message list goes straight to the model as the next inference input.
The three-way split is about who initiates the action. Tools are model-invoked: the model reads descriptions and emits function calls. Resources are host-pulled: the host enumerates available data and injects it. Prompts are user-invoked: the user picks a named workflow template.
A prompt has three parts: a name that identifies it (like `code-review`), a description explaining what it does, and typed arguments the user fills in (a PR number, a date). When rendered, the server produces an array of role-tagged messages with content blocks, not a flat string. The server can construct multi-turn scaffolding (a setup message, optional examples, a final task framing) in a single render.
Real example: a GitHub server exposes a `pr-review` prompt. The user types /pr-review 1234, the server renders a structured review request with the diff and linked issue context, and the model sees consistent, high-quality task framing every time.
MCP separates prompts from tools and resources because each primitive has a distinct invocation model, and collapsing them would produce awkward UX and protocol design.
**Tools** are model-invoked. The model reads tool descriptions during inference and emits structured function calls. Tools may have side effects.
**Resources** are host-pulled. The host enumerates available data (identified by URI) and injects content into the conversation. Resources are read-only.
**Prompts** are user-invoked. The user picks a named template from a slash-command menu, supplies arguments, and the host fetches a rendered message list from the server via `prompts/get`. The model never picks a prompt autonomously; the user does.
The protocol surface is minimal. `prompts/list` returns the catalog (name, description, argument descriptors). `prompts/get` renders a prompt with user-supplied arguments into a structured array of role-tagged messages. `notifications/prompts/list_changed` signals catalog updates. That is the complete API.
The rendered output is an array of messages with roles and content blocks, not a flat string. This makes prompts powerful scaffolds: a server can construct multi-turn priming (setup user message, optional few-shot examples, final task framing) in a single render.
The value is consistency and portability. A team can ship a prompt library (review templates, summarization styles, operational runbooks) any user can invoke without remembering optimal phrasing. Because prompts ship with the server, they travel with the integration to any MCP-aware host.
The decision test for server authors: 'Should the model invoke this autonomously, or should the user pick it from a menu?' If model-invoked, it is a tool. If user-invoked, it is a prompt.
Quick reference
TL;DR
Prompts are user-invoked reusable templates; tools are model-invoked; resources are host-pulled. Each primitive owns a distinct invocation pattern, and overloading one for another's job fights the protocol.
Imagine the AI app has a small menu of pre-written request templates, like recipe cards. Each card has a name (like /code-review or /summarize-meeting) and a few blanks the user fills in. When the user picks a card and fills in the blanks, the app sends a polished request to the model. The user never needs to remember the perfect wording; the template handles that.
MCP prompts are these cards, but instead of the app inventing them, they come from MCP servers. A GitHub server can ship a /pr-review card. A Notion server can ship a /weekly-summary card. The user picks them from the same menu, and any MCP-aware app reads them the same way. The key difference from tools is that the model does not pick prompts; the user does.
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example.
Exposing a capability the model should choose and invoke autonomously. That is a tool, not a prompt. Prompts are user-invoked; if you want model agency, use a tool with the appropriate schema.
Exposing static read-only context to inject into conversations. That is a resource. Prompts are templates with parameters that render into messages; static data fits the resource pattern better.
Building a workflow that requires multi-step tool calls and decision branches. A prompt renders a single structured request. Complex multi-step flows belong in host orchestration code or as a sequence of tool calls the model drives.
Quick scan · 2–4 min
Everything important, quickly.
5 min: state the three-way invocation split, walk the prompts/list and prompts/get API, describe the rendered output shape as a structured message list, contrast MCP prompts with system prompts and with tools, and close with three concrete examples of prompts from realistic servers.
Real-world examples
Real products, models, and research that use this idea.
1GitHub MCP server: a `pr-review` prompt that takes a PR number and renders a structured review request with diff and context.
2Postgres server: an `explain-query` prompt that takes a SQL statement and renders a request asking the model to explain the query plan.
3Sentry server: a `triage-issue` prompt that takes an issue ID and renders a triage workflow request with relevant error context.
4Sequential-thinking server ships meta-prompts that scaffold structured reasoning workflows users can pick from a menu.
5Custom team servers commonly ship prompt libraries (standup templates, retrospective templates, design-review checklists) that any team member can invoke via slash commands in any MCP-aware host.
Interviewer follow-ups
What an interviewer would ask next. Try answering before peeking at the approach.
QHow is an MCP prompt different from a system prompt?
Sign in or go Pro to see the approach for this follow-up.
QWhat does prompts/get actually return?
Sign in or go Pro to see the approach for this follow-up.
QWhy are prompts user-invoked and not model-invoked?
Sign in or go Pro to see the approach for this follow-up.
Don't say this
Red flags and common mistakes that signal junior thinking. Click to expand.
Most common mistake
Confusing MCP prompts with system prompts or with tools. MCP prompts are user-invoked reusable templates; tools are model-invoked functions; system prompts are static host configuration.