Skip to content

CONCEPT Cited by 1 source

MCP tool vs resource

Definition

MCP tool vs resource is the decision rule inside the Model Context Protocol for whether to expose a capability as a tool (invocable action with side effects) or a resource (addressable read-only content). Both surfaces are part of the MCP spec; choosing the wrong one silently loses caching, discovery, and update-notification properties that clients expect (Source: sources/2026-01-08-wix-mcp-resources-all-you-need-to-know).

The decision rule

Wix Engineering's 2026-01-08 tutorial canonicalises the rule:

Tools are meant to be used when something needs to be done: actions, mutations, side effects, calculations.

Resources are supposed to return data: docs, configs, logs.

Use resources when:

  • Content is read-only (no side effects)
  • Content can be cached
  • Content might be updated — client can subscribe to updates
  • Both user and AI agent might need to access content

(Source: sources/2026-01-08-wix-mcp-resources-all-you-need-to-know).

What each primitive actually gives you

Capability MCP tool MCP resource
Invocable with params ✅ ❌ (URI-addressed, variable-parameterised via templates)
Returns fresh output per call ✅ ⚠️ returns same content unless resource has updated
Client-side cacheable by default ❌ ✅
Discoverable without invocation ⚠️ tool schema only ✅ resources/list + metadata
Human-viewable (user can read directly) ❌ typically agent-scoped ✅ intended for both user + agent
Supports update notifications ❌ ✅ via notifications/resources/updated
Universal client discovery ✅ all agents know tools ⚠️ varies — some clients don't auto-discover resources
Side effects permitted ✅ ❌ must be read-only

Why this matters

The two surfaces have different economic properties at agent scale:

  • Tools consume context window per registration. Every tool's schema sits in context on every turn — a well-documented cost in the Datadog, Dropbox, and Cloudflare MCP ingests (see systems/model-context-protocol).
  • Resources separate the metadata surface from the content surface. The client lists resources lazily; content is only loaded when needed. A server exposing 500 resources is not the same context-window cost as a server exposing 500 tools — a reason to prefer resources for read-only content at scale.
  • Resources layer cleanly with update notifications. Live logs, metrics feeds, notification streams map naturally onto the subscribe: true + notifications/resources/updated protocol edge (concepts/resource-subscribe-capability; patterns/subscribe-notify-for-updatable-resource). Doing the same with tools requires the client to poll.

Discovery-gap workaround

Not every MCP client discovers resources directly. The canonical workaround — exposed as patterns/expose-resource-as-tool-for-agent-discoverability — is to register a companion tool that returns a resource_link or resource content type. The resource still exists as a first- class resource; the tool is the discovery handle for clients that don't implement resources/list in their agent loop. Every MCP- aware agent flow lists tools, so the resource becomes reachable everywhere.

Seen in

Last updated · 476 distilled / 1,218 read