Subscriptions & Live Data

Static resource reads are straightforward — the client asks, the server responds. But enterprise data changes constantly. A dashboard dataset that was accurate five minutes ago may already be stale. MCP addresses this with resource subscriptions: a client subscribes to a resource URI, and the server sends notifications when the underlying data changes. The client can then re-read the resource to get the updated content, or use the notification payload directly if the server includes the delta.

The subscription lifecycle has four phases. First, the client calls resources/subscribe with a URI to express interest. Second, the server tracks the subscription and begins monitoring the underlying data source. Third, when data changes, the server emits a notifications/resources/updated notification with the affected URI. Fourth, the client calls resources/read to fetch the current state. This pull-on-notify pattern keeps the protocol simple — the server does not need to stream full payloads on every change, and the client controls when it actually fetches updated data.

Under the hood, servers implement change detection in whatever way suits the data source. File-based resources use filesystem watchers (inotify, FSEvents). Database resources poll with change-tracking queries or listen on database notification channels (PostgreSQL LISTEN/NOTIFY, MySQL binlog). API-backed resources use webhooks or polling intervals. The MCP protocol does not prescribe the detection mechanism — it only standardizes how notifications flow to the client.