Why does MCP have a 'prompt' primitive separate from tools and resources?

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.