- In short
- An MCP server exposes three primitives: tools are callable actions Claude invokes, resources are readable data Claude reads, and prompts are reusable templates. Choosing the right primitive keeps the server interface clear to the model: content to be read is a resource, an operation to be run is a tool, and a reusable message template is a prompt.
Three primitives, three jobs
Once you can author an MCP server, the next thing to learn is what an MCP server can actually expose. The Model Context Protocol defines three primitives, and each has a distinct job: tools, resources, and prompts. On the Claude Certified Developer - Foundations (CCDV-F) exam, this knowledge point is about knowing which primitive fits which need, because choosing correctly is what keeps the server's interface clear to the model.
The mental model is a clean split by verb. Does Claude need to do something? That is a tool. Does Claude need to read something? That is a resource. Do you want to hand Claude a reusable message template? That is a prompt. Keeping those three verbs separate is the whole knowledge point.
- MCP primitives
- The three kinds of capability an MCP server can expose: tools are callable actions the model invokes, resources are readable data the model reads, and prompts are reusable templates. Each primitive signals a different kind of interaction to the model.
Tools: callable actions
MCP tools are the primitive closest to what you already know from tool use and function calling. A tool exposes a callable action: an operation Claude invokes to make something happen or to fetch a computed result. Creating a ticket, sending a message, running a search, executing a query: these are operations, and they belong as tools. When Claude uses a tool it is asking the harness to run something, and the result comes back for the model to reason about.
The key signal a tool sends is "this is an operation you invoke." If the interaction is fundamentally about performing an action or triggering a computation, the tool is the right primitive.
Resources: readable data
A resource exposes readable data: content Claude reads rather than an operation it runs. A configuration file, a document, a database record surfaced for reading, a reference dataset: these are content, and they belong as resources. The signal a resource sends is "this is data available for you to read," which is a fundamentally different interaction from invoking an action.
This distinction is the central exam trap on this knowledge point: exposing readable data as a tool call instead of a resource. It is tempting to wrap everything in a tool, so you write a get_config tool that returns the configuration. But if the intent is simply that Claude should be able to read the configuration, a resource models it more clearly than an action. Modelling readable content as a resource keeps the server's interface honest: tools are for doing, resources are for reading, and blurring the two muddies what the model understands the server to offer.
Prompts: reusable templates
The third primitive is the prompt: a reusable template the server exposes. A prompt is a pre-written, parameterised message or workflow template that an application or user can pull in, rather than an operation the model executes. It packages a reusable way of asking for something so it does not have to be rewritten each time.
The trap here is conflating an MCP prompt template with an executable tool. A prompt is not a function Claude calls to perform work; it is a template. If a scenario describes something that should run and produce a result, that is a tool, not a prompt. If it describes a reusable template that shapes how a request is phrased, that is a prompt. Keeping the prompt primitive distinct from the tool primitive is exactly what the exam checks.
Why the right primitive matters
Choosing the right primitive is not pedantry; it keeps the server's interface clear to the model. When readable data is exposed as a resource and actions are exposed as tools, Claude can tell at a glance what kind of interaction each capability affords, and it reaches for the right one. When everything is jammed into tools, the model loses that signal: it cannot easily distinguish "read this" from "do this," and its behaviour gets muddier. The primitives are a vocabulary, and using each word for its meaning is what makes the server legible.
This clarity also compounds with the other MCP knowledge points. A well-modelled server, exposing the right primitives, is the thing that then gets connected over one of the MCP communication patterns, and it is what makes an MCP the right choice when you weigh it against a packaged procedure in Skills versus MCPs.
The traps the exam sets
Two traps dominate here, and both are about primitive confusion. The first is exposing readable data as a tool call instead of a resource. A scenario might describe a server that wraps a reference document behind a read_document tool, when the intent is purely that Claude should read the document. Modelling it as a resource is the clearer choice, because the interaction is reading, not acting.
The second is conflating an MCP prompt template with an executable tool. A candidate might expect an MCP prompt to run and return a result like a function. It does not; it is a reusable template. If work must actually execute, that is a tool.
Worked example
A developer authors an MCP server for a knowledge base. They expose the company style guide, a create_article action, and a standard 'summarise this article' template, but model all three as tools.
The developer's instinct is that since tools are the primitive they know best, everything should be a tool: a get_style_guide tool, a create_article tool, and a summarise_article_template tool. The create_article case is correct, because creating an article is an operation Claude invokes.
But the other two are mismodelled. The style guide is content Claude should be able to read, so it belongs as a resource, not a tool call. Wrapping it in a tool tells the model "this is an action to run" when the real intent is "this is data to read." And the summarise template is a reusable message template, so it belongs as a prompt, not a tool that supposedly executes.
Remodelling gives a clear interface: the style guide is a resource, create_article stays a tool, and the summarise template is a prompt. Now Claude can tell what each capability affords. The lesson the exam wants: match the primitive to the interaction, readable data is a resource, an action is a tool, and a reusable template is a prompt.
Common misreadings to avoid
Misconception
Everything an MCP server offers should be a tool, since tools are the main primitive.
What's actually true
Misconception
An MCP prompt is basically a tool that runs and returns a result.
What's actually true
How this is tested on the exam
Domain 8 questions on this knowledge point give you a capability and ask which primitive fits, or show a mismodelled server and ask what is wrong. The correct answers come back to the split by verb: tools for actions Claude invokes, resources for data Claude reads, and prompts for reusable templates. Because this is an understand-level knowledge point, you are expected to explain the three primitives and choose correctly among them, keeping the server's interface clear so the model knows what each capability offers.
An MCP server needs to make the organisation's onboarding policy document available so Claude can read and cite it during conversations. The document is never modified by Claude. Which primitive best models this?
People also ask
What are the three MCP primitives?
What is the difference between an MCP tool and a resource?
What is an MCP prompt?
Watch and learn
Official Anthropic Academy lessons first, then hand-picked walkthroughs. Videos load only when you press play.
No videos curated for this concept yet
We are still curating the best official and community videos for this topic.
References & primary sources
Master this concept with Archie
Practice it inside an adaptive study session. Archie, your Socratic AI tutor, tracks your mastery with Bayesian Knowledge Tracing and schedules the perfect next review.