CONCEPT Cited by 1 source

MCP resource¶

Definition¶

An MCP resource is a read-only, addressable, client-cacheable, optionally-subscribable piece of content exposed by a Model Context Protocol server. Each resource carries six pieces of metadata: a unique name, a URI (per RFC 3986), a human- and LLM-readable description, a MIME type, optional annotations (concepts/resource-annotations), and a handler function that returns the actual content (Source: sources/2026-01-08-wix-mcp-resources-all-you-need-to-know).

Three shapes¶

MCP resources come in three concrete shapes per the Wix tutorial:

Static resource — returns identical content for all callers. Use case: documentation, configuration files, enum lookup tables, filesystem content that rarely changes. Registered once with a fixed URI.
Template resource — parameterises the URI with {placeholder} syntax per RFC 6570 URI templates. The handler receives extracted variables as a second argument and returns content that varies by parameter.
Updating resource — declares a subscribe: true capability on the server and emits notifications/resources/updated events when content changes. Clients re-read the resource on notification (concepts/resource-subscribe-capability; patterns/subscribe-notify-for-updatable-resource).

Why it exists as a distinct primitive from tools¶

MCP tools are the action / mutation / side-effect surface of MCP. MCP resources are the read-only data-return surface. The decision rule on when to use which is canonicalised under concepts/mcp-tool-vs-resource. Verbatim from Wix's post: "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."

Resources vs tools¶

The split matters because:

Resources are cacheable. Clients can retain resource content across tool invocations and re-fetch only on update notifications. Tools produce fresh output per call.
Resources are human-viewable. A client can render a resource directly to a user — docs, logs, config — without an LLM in the loop. Tool results are typically scoped to the agent session.
Resources can be discovered without invocation. A client can list resources via resources/list, show them in a UI, and only fetch when the user or agent requests. Tools require invocation to produce any output.
Resources avoid the context-window cost of inlining content into every tool response. Return a resource link from a tool and the client can hydrate the content on demand, once.

Discovery gap¶

Not all MCP clients implement direct resource discovery. Verbatim from Wix: "Not all AI agents know how to discover and use resources directly. However, all agents understand tools." The production workaround canonicalised as patterns/expose-resource-as-tool-for-agent-discoverability: register a companion tool that returns a resource_link or resource content type, making the resource discoverable through tool listing in every MCP-aware agent flow.

URI-scheme design¶

Per RFC 3986, any URI scheme is permitted. In practice, the JavaScript URL constructor used under the hood in @modelcontextprotocol/sdk has custom handling for known schemes that breaks resource resolution — specifically file:// has a trailing slash appended, turning file://example.txt into file://example.txt/ and yielding "Resource not found" errors. Recommended practice: use custom schemes (doc://, log://, git://, resource://) that sidestep the JS URL constructor's built-in handlers (Source: sources/2026-01-08-wix-mcp-resources-all-you-need-to-know).

Seen in¶

sources/2026-01-08-wix-mcp-resources-all-you-need-to-know — canonical tutorial-altitude retrospective covering the three resource shapes, the six metadata fields, the resource-link vs embedded-resource trade-off, and the JavaScript URL constructor file:// gotcha. First wiki source to canonicalise MCP resources as a distinct primitive from MCP tools.