MCP Primitives
MCPDefinition
The three fundamental building blocks of the MCP protocol: Tools (model-controlled actions Claude can invoke), Resources (application-controlled data Claude can read), and Prompts (user-controlled templates for common interactions). Each serves a distinct control model.
Example Usage
Use Tools for actions Claude decides to take, Resources for data the app provides to Claude, and Prompts for user-initiated interaction templates.
In Depth
MCP servers expose exactly three kinds of capabilities, called primitives: Tools, Resources, and Prompts. Each primitive maps to a different control model — that is, a different answer to the question "who decides when this is used?"
Tools are model-controlled. The AI decides when to invoke a tool based on its interpretation of the task. You register a tool by giving it a name, a description, and a JSON Schema for its input. When the model determines a tool call is appropriate, it emits a tool_use block; the client executes it and returns the result. Because the model initiates tool use, tools are suited for actions: querying a database, creating a file, sending a message.
Resources are application-controlled. The host application decides what data to inject into Claude's context. Resources are identified by URIs and contain read-only content — text, JSON, binary blobs, or template-generated output. The application calls resources/read and passes the result to Claude; Claude does not autonomously request a resource by URI. Resources suit ambient context: the current user's profile, a document being edited, environmental state.
Prompts are user-controlled. They are reusable interaction templates that surface in the UI so humans can invoke them directly. A Prompt might package a common workflow — "summarise this ticket," "review this PR" — as a named command. The human selects the prompt; the client renders it and sends it to Claude. Prompts are the primitive closest to slash commands.
The three-primitive model is one of the highest-yield exam areas in Domain 2 because every MCP question eventually comes back to "which primitive fits this requirement?" Misclassifying a Resource as a Tool (or vice versa) is the most common error — the giveaway is the control question: if the *model* initiates it, it is a Tool; if the *app* provides it, it is a Resource; if the *user* triggers it, it is a Prompt.
See MCP Tools (Primitive) and MCP Resources for deeper dives into those specific primitives.
How It Compares
| Primitive | Controlled by | Initiates as | Typical use |
|---|---|---|---|
| Tools | Model | Model decides to call | Actions: query DB, create issue, send message |
| Resources | Application | App injects into context | Ambient data: user profile, open document |
| Prompts | User | Human selects in UI | Reusable workflows: /review-pr, /summarise |
| *(not a primitive)* | — | — | Server configuration, transport, session lifecycle |
How It's Tested & Common Confusions
- Classification scenarios: given a capability description, identify which primitive it is.
- Control-model questions: "who decides when this is invoked?" — correct answer maps to model/app/user.
- Design questions: asked to design an MCP server for a use case, choose the right primitive type for each capability.
- Distractor format: one answer option swaps Tool and Resource for the same use case; you must apply the control-model test to distinguish them.
Frequently Asked Questions
Can a single MCP server expose all three primitives?
Yes. Primitive types are not mutually exclusive. A file-system server might expose Tools for write operations, Resources for read-only directory listings, and Prompts for common file-manipulation workflows. Each primitive is discovered independently via its own list endpoint.
If a Resource is read-only, how does Claude 'use' it?
The application reads the resource and includes its content in Claude's context — typically in the system prompt or as injected user-turn content. Claude processes the content but does not call a read function itself. This is the application-controlled nature of Resources: the app decides what to surface and when.