Resource subscribe capability (MCP)¶

CONCEPT Cited by 1 source

Definition¶

The resource subscribe capability is the MCP-protocol edge that lets an MCP server push notifications/resources/updated events to connected clients whenever a registered resource's content changes. A server enables it by declaring capabilities: { resources: { subscribe: true } } on the McpServer constructor. Clients that receive the notification re-read the resource via resources/read and pick up the new content (Source: sources/2026-01-08-wix-mcp-resources-all-you-need-to-know).

Why it exists¶

MCP resources are read-only content that clients cache. Without a push edge, clients would need to poll each resource on a fixed cadence — wasteful for resources that rarely change, insufficient for resources that change faster than the poll interval. The subscribe capability converts cache invalidation from a client-side polling loop into a server-side notification, similar in shape to server-sent events or Redis keyspace notifications but scoped to the MCP session.

Canonical use cases¶

From Wix's tutorial:

Live logs — latest application events. The working example emits a new log every 20 seconds via setInterval and calls server.server.sendResourceUpdated({ uri }) on each new entry.
Metrics — real-time monitoring data.
Notifications — event streams.
Live feeds — data that changes frequently.

Canonical pattern pairing: patterns/subscribe-notify-for-updatable-resource.

Implementation details (TypeScript SDK)¶

Server side:

const server = new McpServer(
  { name: 'my-server', version: '1.0.0' },
  {
    capabilities: {
      resources: {
        subscribe: true,  // enable the capability
      },
    },
  },
);

// Later, when resource content changes:
server.server.sendResourceUpdated({ uri });

Production caveats surfaced by Wix¶

The @modelcontextprotocol/sdk v1.8.0 has three specific limitations around the subscribe capability, all verbatim from the Wix post:

The SDK does not implement the subscribe method. "Clients calling subscribe will get 'method not found' error." Server authors needing per-subscriber targeting must implement the method themselves.
Capability declaration alone enables fan-out. "Clients will receive notifications/resources/updated if you set capabilities.resources.subscribe: true." Even without an implemented subscribe method, the server can emit notifications and clients will receive them.
No subscriber targeting — all updates fan out to all clients. "Server doesn't track subscribers, so it sends ALL resource updates to ALL clients." Production implication: fan-out cost is O(clients) per update, and a client that subscribed to nothing still receives all notifications.

Server authors operating at non-trivial scale must implement the subscribe method themselves to filter notifications per subscriber — the SDK's default is the simplest possible fan-out.

Shape vs WebSocket / SSE / long-polling¶

The subscribe capability rides whatever transport the MCP client and server have established (typically stdio for local MCP servers, HTTP/SSE for remote). It is not a new transport — it is a protocol-level contract on top of existing bidirectional MCP transports. Clients responsible for re-read logic; servers responsible for emission.

Seen in¶

sources/2026-01-08-wix-mcp-resources-all-you-need-to-know — canonical wiki source for the MCP subscribe capability at the implementer altitude. Names the capability flag, the server- side emission API (sendResourceUpdated), the three SDK-v1.8.0 limitations, and the live-logs / live-metrics use-case taxonomy.