What it does
The `notifications/resources/updated` notification is emitted by the server to a client whenever the contents or metadata of a subscribed resource have changed. The server fires this notification only after a client has called `resources/subscribe` for a specific URI and the server has confirmed the subscription. Triggers include file system writes, database row updates, in-memory state flips, or any backend event that causes the resource's byte content, MIME type, or embedded data to differ from the last version the client observed. The notification carries the URI of the changed resource but does not inline the new contents. Upon receiving this notification, the client is expected to issue a fresh `resources/read` call for the same URI to retrieve the updated payload. The notification is therefore a cache-invalidation signal rather than a data-delivery mechanism. Clients that ignore the notification risk operating on stale data until they read the resource again. Both the server and client must have declared the `resources` capability with `subscribe: true` during the `initialize` handshake for this flow to be valid. If either side omits that flag, the server must not send this notification and the client must not rely on receiving it. Ordering is best-effort: rapid successive mutations may be coalesced into a single notification, so clients should treat each notification as "at least one change occurred" rather than "exactly one change occurred."
When to use
When watched resource bytes change.
When NOT to use
For non-subscribers.
Notes
Capability gating is mandatory
Both the server's and client's `initialize` response must include `capabilities.resources.subscribe: true`. A server that emits this notification without that mutual agreement violates the protocol. Clients should defensively ignore unexpected notifications, but correct servers must never send them to unsubscribed or capability-lacking clients.
Notification does not carry new content
The payload contains only the changed URI, not the updated resource body. This is intentional: it keeps notifications lightweight and lets the client decide whether a fresh read is worth the round-trip. Always follow the notification with a `resources/read` if your application needs the latest data; never assume content is unchanged between reads.
Coalescing and race conditions
Servers are permitted to coalesce multiple rapid mutations into a single notification. A client that receives one notification, issues a `resources/read`, and then receives a second notification before the read response arrives must handle both: discard the in-flight read result and re-issue the read, or accept that the result may already reflect the second mutation. Design your update handler to be idempotent.
Unsubscribing stops delivery
Once a client calls `resources/unsubscribe` for a URI, the server must stop delivering this notification for that URI. Clients that are torn down without explicitly unsubscribing (e.g., transport disconnect) cause the server to clean up subscriptions as part of session teardown. SDK implementations vary: some automatically re-subscribe after reconnect, others require the caller to re-issue `resources/subscribe` manually after a new session is established.
Parameters
| Name | Type | Purpose |
|---|---|---|
| uri | string | URI of the changed resource. |
Examples
Log updated
{ "method": "notifications/resources/updated", "params": { "uri": "file:///log.txt" } }