訊息模式

本頁定義核心協定的訊息模式（Message Patterns）：用戶端與伺服器如何把 JSON-RPC 的請求、回應與通知組合成完整互動。所有傳輸機制都承載相同的訊息模式；各傳輸之間的差異，只在於訊息如何分框與傳遞。

每一次互動都由用戶端開始：

• 用戶端送出 JSON-RPC 請求（requests）與通知（notifications）。
• 伺服器對每一個請求回覆 JSON-RPC 回應（response）；回應可以是結果或錯誤，並且在最終回應之前，可以先送出與該請求相關的通知。

伺服器 MUST NOT（不得）主動發起 JSON-RPC 請求；用戶端也不會送出 JSON-RPC 回應。

請求與回應

最基本的模式是：用戶端送出請求，伺服器以結果或錯誤作答。請求仍在處理期間，伺服器 MAY（可以）送出與該請求相關的通知，例如 notifications/progress 或 notifications/message。

1. 用戶端送出 request。
2. 伺服器可選擇送出零個或多個 request-scoped notification。
3. 伺服器送出最終 response。

多回合請求（MRTR）

如果伺服器為了完成請求，需要向用戶端取得額外輸入（例如 Sampling、Elicitation 或 Roots），伺服器不再反向建立 JSON-RPC 請求，而是回傳 InputRequiredResult。用戶端取得所需資訊後，再以新的 JSON-RPC id 重送原始請求，並附上對應的 inputResponses。

1. 用戶端送出初始 request。
2. 伺服器回傳 InputRequiredResult，指出需要的額外輸入。
3. 用戶端收集輸入並重送原始 request。
4. 伺服器回傳最終 response。

完整規則請見多回合請求。

訂閱與通知

若用戶端希望持續接收清單變更或資源更新等事件，它會送出 subscriptions/listen。這個請求會建立長時間存活的通知串流，伺服器只送出用戶端明確要求的通知種類。

1. 用戶端送出 subscriptions/listen。
2. 伺服器先送出 notifications/subscriptions/acknowledged。
3. 串流維持開啟，伺服器持續送出帶有 subscriptionId 的通知。
4. 底層通道若中斷，用戶端重新送出訂閱請求建立新的串流。

完整規則請見訂閱。

新增訊息模式

核心協定的所有功能都建立在這些模式之上。未來若某個協定版本新增新的訊息模式，模式本身仍以 JSON-RPC 請求、回應與通知來表達，因此不需要為每一種傳輸重新定義協定語意。