Powiadamianie klientów o aktualizacjach

Resources change: a file is edited, a record updates. MCP lets a server notify clients so they don't keep reading stale content. 🔔

An update signal is a notification: a JSON-RPC message with no id and no reply. The server tells the client something happened and moves on.

A client opts in by calling resources/subscribe for a specific URI. Only then does the server bother sending updates about that resource.

When a watched resource changes, the server sends resources/updated carrying the URI. It says what changed, but not the new content itself.

The pattern is two steps: the server notifies, then the client decides to re-read. This keeps payloads tiny and lets the client control timing.

Sometimes the whole catalog shifts as resources appear or vanish. The server sends a list_changed notification so the client refreshes its listing.

These features are negotiated up front. A server advertises subscribe and listChanged support during initialize, so both sides know what's possible.

When a client no longer cares, it calls resources/unsubscribe for that URI. The server then stops sending updates, saving needless traffic.

Send an update only when content actually changes. Noisy, needless notifications waste the client's effort and can trigger pointless re-reads.

To know when to notify, your server watches the source, such as a file watcher or a database trigger, then emits an updated signal in response.

Update notifications turn a resource into something live. The model stays in sync with reality without polling, keeping its context honest. 🎯

What does a resources/updated notification include?

You learned how clients subscribe, receive updated and list_changed notifications, and re-read on demand, keeping dynamic resources fresh and live. Course complete! 🚀