An MCP server can expose three kinds of capability, and the trick is knowing who starts each one.
**Tools** are the model's lever. The LLM decides to call a tool, like `send_email` or `run_query`, and the call can change the outside world. Each tool ships an `inputSchema` so the model knows what arguments to fill in.
Resources are read-only data the host application pulls in. Think of a file, a database row, or a document chunk, addressed by a URI. The model references them, but it does not invoke them and cannot write back through them.
Prompts are reusable message templates the server registers. The host surfaces them to the user, often as slash-commands or menu items. The user picks one, fills in any slots, and it expands into a starting message.
So the recall pattern is simple: tools are model-initiated and can have side effects, resources are application-initiated and read-only, prompts are user-initiated templates.
MCP servers expose three primitive types, distinguished by who initiates them.
**Tools** are model-initiated. The LLM decides to call one, and the call may produce side effects on external systems. Every tool ships an `inputSchema` that tells the model how to form valid arguments. This is the primitive closest to classic function calling.
Resources are application-initiated and read-only. The host pulls them by URI and feeds the bytes into context. The model can reference a resource but never invokes it directly, and there is no write path back through a resource. Files, query results, and document chunks all fit here.
Prompts are user-initiated templates the server registers. The host surfaces them on user-facing surfaces, typically as slash-commands. The user picks one, fills any slots, and it expands into a seed message.
The distractors flip the initiator. Resources are not model-initiated and cannot write data back. And the spec does not mandate user approval before every call across all three primitives. Approval is a host-side safety practice for tool calls, not a universal protocol rule.
Quick reference
TL;DR
MCP servers expose three primitives: tools (model-initiated, side-effectful), resources (app-initiated, read-only), and prompts (user-initiated templates). Each has a distinct initiator.
Picture a kitchen with three drawers. The first drawer holds appliances the chef reaches for on their own to cook something, which changes the meal. Those are tools, the model decides to use them. The second drawer holds recipe cards, read-only references someone hands the chef when needed, and the chef never rewrites them. Those are resources, the app decides what to pass in. The third drawer holds pre-written order forms a diner picks from a menu to start a request. Those are prompts, the user picks them. The whole trick is remembering who opens each drawer: the chef, the kitchen staff, or the diner. Mixing up who initiates what is the classic mistake.
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.
When you only need one model-initiated action and no shared data or templates A single tool, or even plain function calling, covers it; resources and prompts add surface area you never use.
When the data the model needs is small and always present in context Exposing it as a resource adds a fetch step; inlining it directly is simpler when there is no paging benefit.
When the workflow is fully autonomous with no user picking templates Prompts target user-facing surfaces; a headless agent loop has no place to surface them, so they sit unused.
Quick scan · 2–4 min
Everything important, quickly.
3 min: name the three primitives, state the initiator for each, then explain why resources are read-only and why approval is a host policy rather than a spec rule.
Side-by-side
Primitive
Initiator
Side effects
Key field
Tools
Model
Yes, may mutate state
inputSchema
Resources
Application
No, read-only
URI
Prompts
User
No, expands a template
arguments / slots
Real-world examples
Real products, models, and research that use this idea.
1Claude Desktop discovers tools, resources, and prompts from each configured MCP server and gates tool calls behind user approval.
2Anthropic's filesystem MCP server exposes file contents as read-only resources by URI and edit actions as side-effectful tools.
3Cursor and Zed surface MCP prompts as slash-commands the developer picks, separate from the model-initiated tool calls.
Interviewer follow-ups
What an interviewer would ask next. Try answering before peeking at the approach.
QWhy does MCP separate resources from tools instead of treating every fetch as a tool call?
Sign in or go Pro to see the approach for this follow-up.
QHow does a tool's inputSchema interact with a model vendor's function-calling format?
Sign in or go Pro to see the approach for this follow-up.
QIf the spec does not mandate per-call approval, where does the safety boundary live?
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
Thinking resources are model-initiated or writable. Resources are read-only and pulled by the host application, never invoked by the model.