Model Context Protocol servers can expose three core building blocks: resources, tools, and prompts.
They solve different problems:
Resources provide context.
Tools perform actions.
Prompts package reusable instructions.
The most important difference is control. MCP's official documentation describes tools as model-controlled, resources as application-driven, and prompts as user-controlled.
The short answer
MCP primitive | Primary purpose | Typical controller | Common examples |
|---|---|---|---|
Resources | Provide data or context | Application | File contents, database schema, calendar, documentation |
Tools | Execute an operation | Model, within client controls | Search, create issue, update record, send message |
Prompts | Start a reusable workflow or instruction template | User | Review code, summarize meetings, plan a launch |
Use a resource when the application needs to retrieve information for the model.
Use a tool when the model needs to request an operation or compute a result.
Use a prompt when a user should explicitly invoke a known, parameterized workflow.
A complete MCP experience often combines all three: the user selects a prompt, the application supplies resources, and the model calls tools.
Why the distinction matters
Treating every capability as a tool creates unnecessary autonomy and risk. Treating every operation as a resource makes action awkward or impossible. Hard-coding workflows only in the host application can make useful domain guidance difficult to discover and reuse.
Choosing the correct primitive improves:
user control;
model reliability;
permission design;
UI discoverability;
auditability;
caching and context management;
interoperability across MCP clients.
What are MCP resources?
Resources are data sources an MCP server makes available for an application to retrieve and use as context.
Examples include:
a Markdown document;
source code;
a database schema;
a customer record;
calendar availability;
API documentation;
a product brief;
a table export;
a generated report.
Resources are identified by URIs and can declare metadata such as a name, description, MIME type, size, and annotations.
Resources are application-driven
The host application decides how to expose, select, retrieve, and pass resource content to the model.
A client might:
show a file or workspace browser;
suggest resources based on the current conversation;
let the user attach several resources;
search or rank resources before inclusion;
preview content before adding it;
retrieve only a relevant part.
The protocol does not require one UI pattern.
Direct resources
A direct resource has a fixed URI representing a known item.
Examples:
file:///projects/launch-plan.md
docs://workspace/security-policy
calendar://team/2026-07
crm://accounts/acme
The client discovers direct resources with resources/list and retrieves content with resources/read.
Resource templates
A resource template uses a parameterized URI to address a family of resources.
Examples:
weather://forecast/{city}/{date}
docs://workspace/{workspace_id}/document/{document_id}
crm://accounts/{account_id}/activity
database://schemas/{schema_name}
Resource templates are discovered separately and can support parameter completion.
Resource subscriptions
Servers may allow a client to subscribe to changes in a resource. This is useful for live data such as logs, files, schedules, or status documents.
Subscription support does not automatically mean every update should enter model context. The application still decides what to retrieve and present.
Resources should usually be read-oriented
Official MCP educational material describes resources as passive data sources that provide read-only access to context. Mutating a record, sending a message, or publishing a page should generally be modeled as a tool.
What are MCP tools?
Tools are schema-defined operations an AI model can request.
Examples include:
search a workspace;
query a database;
calculate a metric;
create a document;
update a table row;
open a pull request;
send an email;
publish a page;
restart a service.
Each tool has a name, description, input schema, and optional output schema and annotations.
Tools are model-controlled
The model decides when a tool is relevant to the user's request. The client remains responsible for which tools are available, how calls are approved, and whether execution is allowed.
Model-controlled does not mean uncontrolled.
A well-designed client can provide:
a visible tool list;
allow or deny rules;
per-call approval;
preapproval for safe read-only tools;
confirmation for destructive or public actions;
activity history;
rate and retry limits.
Tool discovery and execution
The two core operations are:
tools/list — discover tool definitions;
tools/call — invoke a named tool with arguments.
JSON Schema allows the client to validate inputs and show structured forms where useful.
Tool outputs
A tool result can contain text, images, audio, resource links, embedded resources, or structured content.
This means tools and resources are not mutually isolated. A search tool can return resource links. A create-document tool can return the new document as a resource. A data-analysis tool can return both a summary and a structured object.
Read-only tools
Some operations retrieve information but still fit better as tools.
Examples:
semantic search;
filtered database query;
calculate a forecast;
check deployment status;
look up an account by flexible criteria.
These are model-chosen operations with arguments and computation, rather than application-selected resource retrieval.
Write and destructive tools
Tools that change state need explicit risk design.
Classify them as:
read-only;
reversible write;
external communication;
destructive;
public or production-impacting;
financial or credential-related.
Tool annotations can communicate behavior, but clients must not blindly trust annotations from untrusted servers.
What are MCP prompts?
Prompts are reusable instruction templates exposed by an MCP server.
Examples include:
summarize my meetings;
review this pull request;
plan a product launch;
investigate an incident;
prepare an account brief;
rewrite a document for executives.
A prompt can declare arguments and return one or more messages that guide the model.
Prompts are user-controlled
Official MCP guidance describes prompts as requiring explicit user invocation.
A client may expose them as:
slash commands;
command-palette entries;
workflow buttons;
context-menu actions;
form-driven templates.
The user sees and chooses the workflow rather than the model silently activating it.
Parameterized prompts
A prompt can request structured arguments such as:
target audience;
date range;
workspace or resource;
output format;
risk level;
destination;
review owner.
Parameter completion can help the user select valid values.
Prompts can reference resources and tools
A prompt is not only a static block of prose. It can guide a client and model toward a coordinated workflow:
gather specified resources;
follow domain instructions;
call relevant tools;
return a consistent output.
Prompts standardize how a server is used without forcing the model to infer the entire workflow from tool names.
Control model: application, model, and user
!Application, model, and user control lanes for resources, tools, and prompts
The control distinction is the clearest way to remember the primitives.
Application controls resources
The application manages which context is discoverable and included. It may use user selection, search, heuristics, permissions, or retrieval.
Model controls tool selection
The model reasons about which available operation to request. The client enforces permissions and approval.
User controls prompts
The user explicitly chooses a reusable workflow and supplies its arguments.
Question | Resource | Tool | Prompt |
|---|---|---|---|
Who usually initiates it? | Application | Model | User |
Does it primarily provide context? | Yes | Sometimes as output | Can request context |
Can it cause side effects? | Normally no | Yes | Not by itself |
Does it have typed arguments? | URI/template parameters | JSON Schema input | Prompt arguments |
Typical UI | Picker, browser, attachment | Tool approval or activity | Slash command or workflow form |
Decision tree
!A branching decision path leading to a resource, tool, prompt, or combined workflow
Ask these questions in order.
1. Is the capability a known piece of data?
If yes, expose it as a resource.
Examples: a policy document, schema, source file, customer profile, or published report.
2. Does the capability execute logic with parameters?
If yes, use a tool.
Examples: search, calculate, create, update, send, deploy, or publish.
3. Is the capability a reusable user-invoked workflow?
If yes, add a prompt.
Examples: prepare weekly review, triage incident, or plan vacation.
4. Does the workflow need all three?
Use all three. A prompt can define the process, resources can provide context, and tools can perform steps.
Examples by domain
Knowledge workspace
Resources
document content;
table export;
workspace policy;
published-site configuration.
Tools
search_workspace;
create_document;
update_table_cells;
publish_resource.
Prompts
prepare a weekly research brief;
review this document for unsupported claims;
create a launch plan.
Software development
Resources
repository files;
architecture documentation;
API schema;
issue description.
Tools
search code;
run tests;
create branch;
update issue;
open pull request.
Prompts
investigate a bug;
review a pull request;
prepare release notes.
CRM and sales
Resources
account record;
pricing policy;
call transcript;
territory plan.
Tools
search accounts;
update opportunity;
draft email;
schedule meeting.
Prompts
prepare account brief;
review pipeline risk;
plan renewal conversation.
Operations
Resources
runbook;
service topology;
incident timeline;
monitoring configuration.
Tools
query logs;
check service status;
create incident;
restart service.
Prompts
triage an incident;
prepare postmortem;
run readiness review.
One workflow using all three
Consider a user asking an AI application to prepare and publish a sourced market brief.
Prompt
The user invokes “Prepare market brief” with:
target market;
date range;
audience;
output length;
review owner.
Resources
The application includes:
approved market-research standard;
current product positioning;
existing competitor table;
last published brief.
Tools
The model calls:
web or workspace search;
read selected documents;
add evidence rows;
create or update the brief;
preview the document.
Approval
The publish tool is not automatically executed. The user reviews the preview and confirms publication.
This separation creates consistent workflow, relevant context, flexible reasoning, and controlled action.
Resources versus read-only tools
This is the most common design ambiguity.
Use a resource when:
the data has a stable identity or URI;
the application may browse or attach it;
reading does not require complex model-selected arguments;
the same item may be reused across workflows;
subscription or preview is useful.
Use a read-only tool when:
the operation is a query or computation;
arguments define filters or ranking;
the model should decide when to run it;
the output is generated rather than a stable item;
execution may be expensive or rate-limited.
Example: customer information
crm://accounts/acme is a resource representing one account.
search_accounts(industry, region, revenue) is a tool that finds accounts.
prepare_account_brief(account_id) is a prompt that guides a workflow.
Prompts versus skills or system instructions
These concepts overlap but are not identical.
MCP prompt
A server-exposed, discoverable, user-invoked template retrieved through prompts/get.
System instruction
Host-controlled instructions that define overall model behavior and may not be visible or selectable by the user.
Agent skill
A packaged set of instructions, references, scripts, or tool-use rules in a specific agent platform. A skill may use MCP resources and tools but is not automatically an MCP prompt.
Application workflow
Program logic that controls stages, state, retries, approvals, or UI. A prompt alone does not replace durable orchestration.
Use MCP prompts for portable entry points into domain workflows. Use application code for stateful control and safety.
Design guidelines for resources
Use stable, meaningful URIs
URIs should represent durable identity, not leak temporary storage details.
Provide accurate metadata
Names, titles, descriptions, MIME types, size, and modification information help clients present and select context.
Respect permissions before listing
Do not advertise resources the current connection cannot read.
Support previews where useful
Users should understand what context they are attaching.
Keep payloads manageable
Large resources may need pagination, sections, derived summaries, or search.
Distinguish source and generated content
Expose provenance and modification dates so the model and user can judge freshness.
Design guidelines for tools
One clear operation
A tool should have a specific job with predictable inputs and outputs.
Descriptions explain when, not only what
Tell the model when the tool is appropriate and when it is not.
Use strict schemas
Validate identifiers, enumerations, date formats, required fields, and bounded values.
Return structured results
Use structuredContent when consumers need stable fields, while retaining compatible human-readable content where appropriate.
Make side effects obvious
Names and descriptions should distinguish preview, draft, update, send, publish, and delete.
Prefer idempotency and recoverability
Repeated calls should not silently duplicate external actions. Return identifiers and links for verification.
Require confirmation by impact
Read-only search and public deletion should not share the same approval policy.
Design guidelines for prompts
Make the workflow outcome explicit
“Prepare account brief” is clearer than “Sales helper.”
Ask for necessary arguments
Require audience, scope, date range, destination, or other decision-changing input.
Show the underlying template
Users should know what instruction they are invoking.
Do not hide irreversible actions
A prompt may guide a workflow but should not imply that explicit tool approval is unnecessary.
Keep domain guidance current
Version prompts when policies, tools, or output contracts change.
Make outputs reviewable
Specify sources, destination, status, owner, and unresolved questions.
Security model by primitive
!Separate security chambers for resource, tool, and prompt risks
Resource risks
unauthorized data discovery;
sensitive content entering model context;
stale or malicious content;
prompt injection inside retrieved data;
overly broad resource listing.
Mitigations include permission filtering, clear provenance, source boundaries, content treatment rules, and minimal retrieval.
Tool risks
destructive or irreversible actions;
confused-deputy behavior;
credential misuse;
parameter injection;
duplicate side effects;
data exfiltration.
Mitigations include authentication, authorization, schema validation, approvals, idempotency, activity logs, and rate limits.
Prompt risks
misleading or hidden instructions;
outdated workflows;
arguments that change safety assumptions;
prompts that imply unauthorized actions.
Mitigations include transparency, versioning, validation, review, and separation from tool authorization.
Common mistakes
Exposing every read as a tool
This increases tool count and model-selection burden. Stable, browsable context may fit resources better.
Using resources to mutate state
A URI that secretly performs an update violates user expectations. Use a clearly named tool.
Treating a prompt as an autonomous agent
A prompt supplies messages. It does not inherently maintain state, retry, schedule, or enforce authorization.
Hiding side effects behind friendly names
“Share report” may send email, publish a page, or create a public link. Split or describe operations precisely.
Loading all resources into context
Resource discovery is not permission to send everything to the model. Retrieve only what the task needs.
Trusting server annotations automatically
Annotations are useful hints, not a replacement for trust and policy.
Duplicating the same concept across primitives
If one stable customer record is a resource, avoid also exposing several overlapping no-argument tools that return the same record unless there is a clear UX reason.
Frequently asked questions
What is the difference between MCP resources and tools?
Resources provide identifiable context that the application retrieves. Tools are schema-defined operations the model can request, including queries, computations, and state-changing actions.
What is an MCP prompt?
An MCP prompt is a reusable, parameterized instruction template exposed by a server and explicitly invoked by the user through a compatible client.
Can an MCP tool return a resource?
Yes. Tool results can return resource links or embed resource content. For example, a create-document tool can return a link to the newly created document.
Can resources have parameters?
Yes. Resource templates use URI templates with parameters to represent families of resources.
Are MCP resources always read-only?
They are designed as passive context sources and are generally read-oriented. Use tools for mutation or other actions.
Are MCP tools automatically executed?
The model may request a tool, but the client controls availability, authorization, approval, and execution.
Do all MCP servers need resources, tools, and prompts?
No. A server can implement only the capabilities its use case needs. Many action-oriented servers expose tools only.
Should a search operation be a resource or a tool?
Usually a tool, because search takes arguments and produces a dynamic result. Individual search results may be returned as resource links.
Are MCP prompts the same as prompt engineering?
No. Prompt engineering is the broader practice of designing model instructions. MCP prompts are a standardized server capability for discoverable, user-invoked templates.
What is the best way to combine all three?
Let the user invoke a prompt, let the application select relevant resources, let the model request tools, and let the client enforce permissions and approval.
Final checklist
Before exposing a capability, verify:
Stable context has a resource identity.
Parameterized data uses a resource template where appropriate.
Queries and computations are modeled as clear tools.
Side effects are explicit and classified.
Reusable workflows are discoverable prompts.
Tool and prompt arguments are validated.
Resource listing respects permissions.
Retrieved content is treated as potentially untrusted data.
High-impact tool calls require approval.
Results return identifiers, links, and structured fields.
The client can show activity and errors.
The full workflow remains understandable to the user.
Final summary
Remember the control model:
Resources: application-driven context.
Tools: model-controlled operations, governed by the client.
Prompts: user-controlled workflow templates.
Use each primitive for its intended role. Then combine them so the user chooses the workflow, the application supplies trustworthy context, and the model performs only the actions the client allows.