更新をクライアントに通知する

リソースは変化します。ファイルが編集されたり、レコードが更新されたりします。MCPを使うと、サーバーからクライアントに通知できるため、古いコンテンツを読み続けずに済みます。🔔

更新シグナルは通知です。これはidも返信も持たないJSON-RPCメッセージです。サーバーは何かが起きたことをクライアントに伝え、そのまま処理を続けます。

クライアントは、特定のURIに対してresources/subscribeを呼び出すことで購読を開始します。それ以降に限り、サーバーはそのリソースの更新を送信します。

監視中のリソースが変更されると、サーバーはURIを含むresources/updatedを送信します。これは何が変更されたかを示しますが、新しいコンテンツ自体は含みません。

流れは2段階です。サーバーが通知し、その後でクライアントが再読み込みするかどうかを判断します。これによりペイロードを小さく保ち、タイミングをクライアント側で制御できます。

リソースが追加されたり消えたりして、カタログ全体が変わることもあります。その場合、サーバーはlist_changed通知を送信し、クライアントは一覧を更新します。

これらの機能は最初にネゴシエーションされます。サーバーはinitialize中にsubscribeとlistChangedのサポートを通知するため、双方が利用可能な機能を把握できます。

クライアントが不要になったら、そのURIに対してresources/unsubscribeを呼び出します。するとサーバーは更新の送信を停止し、不要な通信を節約します。

更新はコンテンツが実際に変更された場合にのみ送信してください。不要で過剰な通知はクライアントの処理を無駄にし、意味のない再読み込みを引き起こす可能性があります。

通知のタイミングを把握するため、サーバーで変更元を監視します。たとえばファイルウォッチャーやデータベーストリガーを使い、その反応として更新シグナルを送信します。

更新通知によって、リソースはライブなものになります。ポーリングを行わなくてもモデルは現実の状態と同期し、コンテキストの正確さを保てます。🎯

クライアントが購読し、updated通知とlist_changed通知を受け取り、必要に応じて再読み込みすることで、動的なリソースを最新のライブな状態に保つ方法を学びました。コース完了です！🚀