MCP Resources vs Tools: What's the Real Difference?

MCP Resources vs Tools: What's the Real Difference?

A Model Context Protocol server can expose three kinds of building blocks: tools, resources and prompts. Developers who reach for tools by default often blur the other two, and the mixup shows up as an agent that quietly writes data it should only read, or a host application that expects the model to fetch content it was never meant to touch. MCP resources vs tools comes down to a question the specification answers directly: who decides when the thing gets used.

MCP tools are actions the model decides to call: schema-defined functions, like booking a hotel or querying a database, that the AI invokes mid-conversation. MCP resources are read-only data the host application or user chooses to load, such as a file, a database schema or a configuration document, addressed by a URI rather than called by name. That control distinction, model-controlled versus application-controlled, is what the Model Context Protocol specification itself uses to define the two.

MCP Resources vs Tools: A Side-by-Side Comparison

The Model Context Protocol specification puts it plainly: tools "enable models to interact with external systems, such as querying databases, calling APIs, or performing computations," while resources "allow servers to share data that provides context to language models, such as files, database schemas, or application-specific information." Here is how the two compare on the points that matter when building a server.

Zuplo's October 2025 explainer of MCP Resources frames the same split in one line: "Unlike MCP Tools, which perform actions, Resources provide read-only access to structured data. Think of them as the 'files' your AI can read, while Tools are the 'functions' it can execute."

MCP Tools: what the model decides to call

Per the spec, tools in MCP are "designed to be model-controlled, meaning that the language model can discover and invoke tools automatically based on its contextual understanding and the user's prompts." A server that supports tools must declare the tools capability, and a client discovers what is available with a tools/list request that returns each tool's name, description and JSON Schema inputSchema. Invocation happens through tools/call, with the arguments validated against that schema.

The spec's own example is a get_weather tool that takes a location string and returns a text result. Because the model chooses when to call a tool, the spec is explicit that "there SHOULD always be a human in the loop with the ability to deny tool invocations," and it requires servers to validate all tool inputs, implement access controls and rate limit invocations. Tool results can carry structured JSON in a structuredContent field alongside plain text, and as of the 2025-06-18 revision a tool can return outputSchema so clients can validate what comes back.

MCP Resources: what the application chooses to load

Resources work the other way. The spec describes them as "application-driven, with host applications determining how to incorporate context based on their needs," whether that means a UI picker, a search box, or automatic inclusion based on the model's selection. A server that supports resources declares the resources capability, which can optionally include subscribe (clients can watch a specific resource for changes) and listChanged (the server announces when the resource list itself changes).

Each resource has a unique URI, an optional MIME type and either text or base64-encoded binary content. The spec lists https://, file:// and git:// as common schemes, and lets servers define their own. Resource templates let a server expose parameterized resources through URI templates, such as file:///{path}, so clients can construct valid URIs without a server listing every possible file in advance.

One production use of resources goes beyond plain file reading: Zuplo's guide points to OpenAI's Apps SDK, which uses embedded resources to serve static UI code, for example URIs like ui://widget/kanban-board.html, that ChatGPT fetches and renders inside an iframe when a tool call needs a custom interface. The resource stays read-only; the tool call that triggers it is what performs the action.

Where prompts fit in

Resources and tools aren't the whole picture. The spec defines a third primitive, prompts, which are "designed to be user-controlled," typically surfaced as slash commands the person picks explicitly rather than something the model decides to call. A dev.to piece on MCP's design, part of a six-part series by AWS Hero Guy Ernest, frames the three primitives as three separate control planes: tools are triggered by the model, prompts are triggered by the business user, and resources are pulled in by the host application. None of them decide when a resource is loaded except the app itself, which the piece calls "the one primitive in which two actors collaborate without either human being directly in the loop."

Verdict by use case

• The AI agent needs to act (send an email, run a query, execute code): use a tool. The model needs to decide, and the spec's human-in-the-loop confirmation applies.
• A user should explicitly pick what context loads (documentation, a schema, a config file, a log the user wants analyzed): use a resource, addressed by URI, read-only.
• A recurring, multi-step workflow a business user triggers by hand (a weekly report, an onboarding checklist): the dev.to series argues this is what prompts are for, not tools or resources.
• A server needs to render custom UI inside a host like ChatGPT: the Apps SDK pattern uses embedded resources for that, not a tool call.

What's new (as of 2026-09-27)

The stable spec revision remains 2025-06-18, but the latest spec draft, dated 2026-07-28, changes how resources and tools work at the transport level:

• It replaces the HTTP GET endpoint and resources/subscribe/resources/unsubscribe with a single subscriptions/listen stream. Clients opt in to specific notification types, including resourcesListChanged and resourceSubscriptions, and the server tags each notification with a subscriptionId (SEP-2575).
• It removes the initialize/notifications/initialized handshake, making MCP stateless: every request now carries its protocol version and client capabilities in _meta fields, and a new server/discover RPC lets clients query a server's supported versions and capabilities up front (SEP-2575).
• Servers "SHOULD return tools from tools/list in a deterministic order to enable client-side caching and improve LLM prompt cache hit rates," a minor change aimed at cutting repeated token cost.
• Responses from tools/list, resources/list, resources/read and resources/templates/list now require ttlMs and cacheScope fields via a new CacheableResult interface, giving clients an explicit freshness hint and a way to tell shared caches apart from private ones (SEP-2549).

Key takeaways

• MCP tools are model-controlled actions; MCP resources are application-controlled, read-only data addressed by a URI, per the official 2025-06-18 specification.
• Prompts are the third MCP primitive: user-controlled, typically exposed as slash commands the person picks directly.
• OpenAI's Apps SDK uses embedded resources with ui:// URIs to render custom interface components inside ChatGPT, a use of resources beyond plain file access.
• The 2026-07-28 spec draft replaces resources/subscribe with a single subscriptions/listen stream and drops the initialize handshake in favor of per-request _meta fields.
• Choose a tool when the model should decide to act, and a resource when the user or the host application should decide what context gets loaded.

FAQ

Can an MCP server expose both resources and tools?

Yes. The two capabilities, resources and tools, are declared and negotiated independently during the server's capability declaration, so a single server commonly supports both alongside prompts.

Are MCP resources read-only?

Yes. The specification is explicit that resources allow servers to "share data that provides context to language models" without performing an action, and Zuplo's guide summarizes the distinction as tools being the "functions" an AI executes and resources being the "files" it reads.

What is a resource template in MCP?

A resource template lets a server expose parameterized resources through a URI template, such as file:///{path}, so a client can construct a valid resource URI on demand instead of the server listing every possible resource up front. Template arguments can be auto-completed through the protocol's completion API.

Does Claude Desktop let users pick which resources to load?

According to Zuplo's Resources guide, applications like Claude Desktop let "users explicitly select which resources to include before starting a conversation," which is the application-controlled behavior the MCP spec's resources model is built around. Editors and IDE assistants such as Claude Code negotiate whichever resource and tool capabilities a connected MCP server declares.

Developers comparing how different servers implement tools, resources and prompts can browse the MCP servers directory on aiagentslisting.com.