MCP Tools vs Resources vs Prompts: Which Primitive to Use (2026)

Use a tool when the AI model should decide to take an action or fetch something. Use a resource when the app or user should pick data to add as context. Use a prompt when the user should choose a ready-made template, such as a slash command. The deciding question is who controls when the feature is used.

Checked against: the server features overview, plus the tools, resources and prompts pages of the 2026-07-28 MCP specification, read on 28 October 2026.

These are the three building blocks, called primitives, that an MCP server can offer. A single server can offer any mix of them. This page compares them so you can design a server, or judge one you are about to install.

At a glance

The control column comes straight from the server features overview, which lists "Prompts: User-controlled," "Resources: Application-controlled" and "Tools: Model-controlled."

Where tools fit best

The tools page says tools "enable models to interact with external systems, such as querying databases, calling APIs, or performing computations." The model can "discover and invoke tools automatically based on its contextual understanding and the user's prompts."

Tools are the right choice when:

• The task changes something, such as creating an invoice or updating a CRM record.
• The model needs to decide, mid-conversation, that it needs fresh data.
• The input is structured and you want it validated against a schema.
• You want typed output. A tool can declare an outputSchema and return a matching structuredContent value.

Tools also carry optional annotations that describe behavior, such as whether a tool is read-only. The spec warns that clients "MUST consider tool annotations to be untrusted unless they come from trusted servers." Learn more in MCP tools explained.

Where resources fit best

The resources page says resources "allow servers to share data that provides context to language models, such as files, database schemas, or application-specific information." Each one has a URI.

Resources are "application-driven." The spec gives examples: a tree or list picker, search and filter, or "automatic context inclusion, based on heuristics or the AI model's selection."

Resources fit when:

• The data is something a person would point at, like a document, a table schema or a log file.
• You want the user or app to control what enters the context window.
• The data has a natural address. Resource templates use URI templates (RFC 6570) for parameterized data, such as file:///{path}.
• Clients should be told when data changes. In 2026-07-28 a client asks for updates through a subscriptions/listen stream.

The 2026-07-28 spec also added ttlMs and cacheScope fields on list and read results, so clients can cache resources. See MCP resources explained.

Where prompts fit best

The prompts page says prompts are "user-controlled," exposed "with the intention of the user being able to explicitly select them for use." It clarifies that this "refers to who decides when the prompt is used, not who authors its content. Prompt content is defined by the server."

Prompts fit when:

• You have a repeatable workflow, like "summarize this week's tickets" or "draft a release note."
• You want to package expert instructions so every user gets the same quality.
• The workflow takes a few named arguments, such as a date range or project name.

A prompt returns messages. Those messages can include text, images or embedded resources, so a prompt can pull a resource into the conversation. See MCP prompts explained.

Pricing

All three are part of the open MCP specification, so none of them costs anything to use. What you pay for is the server and client you run. A small cost point to note: every tool definition the client loads takes up space in the model's context window, so long lists of tools can raise token use. The spec now says servers "SHOULD return tools from tools/list in a deterministic order" to help prompt caching, per the 2026-07-28 changelog.

Security and admin controls

Each primitive has its own rules in the spec.

• Tools. The spec says "there SHOULD always be a human in the loop with the ability to deny tool invocations." Apps should show which tools are exposed, flag when they run and ask for confirmation. Servers "MUST" validate inputs, apply access controls, rate limit calls and sanitize outputs.
• Resources. Servers "MUST validate all resource URIs" and "MUST sanitize file paths to prevent directory traversal attacks." Access controls "SHOULD" protect sensitive resources.
• Prompts. Implementations "MUST carefully validate all prompt inputs and outputs to prevent injection attacks or unauthorized access to resources."

For admins, tools deserve the closest review because they act. Resources and prompts mostly raise data exposure and prompt injection questions. Our MCP security hub covers both.

Which to choose

Pick a tool if the model should decide when to act, the action has side effects, or you need validated, structured input and output.

Pick a resource if the content is data with an address, the user or app should choose what to include, and nothing should change when it is read.

Pick a prompt if a person starts the workflow on purpose and you want a consistent, reusable set of instructions.

Combine them if the job has parts. A "weekly report" server might offer a prompt the user picks, resources for last week's data and a tool to post the result. Check your AI app's docs first, because client support for resources and prompts varies more than support for tools.

Next step

When you design a server, map each feature to the primitive whose control model fits. eSEOspace does this in every MCP development project. Browse more MCP comparisons or take the MCP course lesson on tools, resources and prompts.

Frequently asked questions