Wiki · Concept · Last reviewed June 25, 2026

MCP Resource Subscriptions

MCP resource subscriptions are the optional Model Context Protocol mechanism that lets a client subscribe to updates for a specific resource URI and receive notifications when that resource changes.

Category: Concept Published: June 25, 2026 Modified: June 25, 2026 Last reviewed: June 25, 2026 Tags: MCP, Resource Subscriptions, Notifications, Context, Access Control

Definition

MCP resource subscriptions are a change-notification feature inside MCP Resources. The 2025-11-25 resources specification defines resources as URI-addressed context exposed by servers to clients. A server can also declare a resources capability with optional support for subscribe, which means a client can subscribe to notifications about changes to individual resources.

The subscription is not the same as reading the resource. A resource read returns content blocks, which may be text or encoded binary data. A resource update notification names the affected URI. A client that needs the new content still has to decide whether, when, and under what authority to read the resource again.

How It Works

The resources page shows the subscription flow with a resources/subscribe request containing a uri, such as a project file URI. When that resource changes, the server sends notifications/resources/updated with the resource URI in the notification parameters. The example uses ordinary JSON-RPC message envelopes.

Because subscriptions are optional, clients must not assume every MCP resource server supports them. The resources capability can support neither optional feature, only subscriptions, only list-change notifications, or both. A client should treat capability negotiation as the first boundary: if the server did not advertise subscription support, subscription behavior is not available under the protocol.

Subscriptions are most useful when the resource is dynamic: a log, generated report, changing schema, file, record, dashboard view, or application state snapshot. They are less useful when the resource is static or when the governance rule requires a fresh user decision before every read.

Update vs List Change

MCP distinguishes a resource-content update from a resource-list change. If a server declared listChanged, it should send notifications/resources/list_changed when the set of available resources changes. That notification means discovery changed. It does not mean a specific resource's content changed.

By contrast, notifications/resources/updated is tied to a subscribed URI. That distinction matters for caches and interfaces. A list-change notification may prompt the client to refresh the resource picker or call resources/list. An update notification may prompt the client to invalidate cached content, show that a visible resource changed, or reread the resource after policy checks.

Resource annotations can help display update risk but do not replace policy. The resources specification defines annotations such as intended audience, priority, and last-modified time. Those are hints for clients; they are not independent proof that a changed resource should enter model context automatically.

Governance Requirements

A governed MCP deployment should log the server, protocol version, resource URI, subscription request, user or agent principal, authorization decision, notification time, cache invalidation event, follow-up resources/read request, MIME type, content size, and whether the updated content entered model context. If the URI resolves through a custom scheme, the record should also identify the backing system.

Access control must be checked at read time, not only at subscription time. A user may be allowed to watch that a file changed but not allowed to read its new contents after permissions, ownership, tenant membership, or data classification changes. The resources specification's security considerations say servers should implement access controls for sensitive resources and check resource permissions before operations.

Failure Modes

Stale authority. A subscription created under one permission state keeps driving reads after the user's authority has changed.

Notification overtrust. A client treats an update notification as fresh content, when the protocol only identifies the changed URI.

Cache confusion. A model or host keeps using old resource content after an update notification because the cache boundary is unclear.

List-change collapse. A client treats resource-list changes and resource-content changes as the same event, hiding what actually happened.

Silent context refresh. Updated content is automatically reread into a model context window without renewed consent or audit detail.

Source Discipline

Claims about resources/subscribe, notifications/resources/updated, notifications/resources/list_changed, resource annotations, and resource security checks should cite the versioned MCP resources specification. Claims about lifecycle negotiation should cite the resources capability declaration and avoid assuming that a product with MCP support enables every optional feature.

Spiralist Reading

A resource subscription is a promise to notice.

That promise can support accountability: a client does not have to pretend a stale file is current, and a user can see that shared context changed. But it can also create a quiet path by which live institutional memory keeps refilling the model's view. Spiralism asks whether the update, the reread, the consent, and the answer all remain traceable as separate acts.

Open Questions

Sources

Return to Wiki