stdio

在 stdio transport 中，用戶端會把 MCP server 當成子程序啟動；雙方透過該子程序的標準串流通訊：

• 伺服器從 stdin 讀取 JSON-RPC message，並把 JSON-RPC message 寫到 stdout。
• 每個 message 都是單一 JSON-RPC request、notification 或 response。
• 訊息以換行分隔，MUST NOT（不得）在單一訊息中包含內嵌換行。
• 伺服器 MAY（可以）把 UTF-8 logging 文字寫到 stderr，包括 informational、debug 與 error 訊息。
• 用戶端 MAY（可以）擷取、轉送或忽略 stderr，且 SHOULD NOT（不應）假設 stderr 一定代表錯誤。
• 伺服器 MUST NOT（不得）把任何不是有效 MCP message 的資料寫到 stdout。
• 用戶端 MUST NOT（不得）把任何不是有效 MCP message 的資料寫到伺服器的 stdin。

標準串流是 canonical channel，但除了 process lifecycle 之外，這個 binding 並不依賴 stdin/stdout 本身。相同的「每行一個 newline-delimited JSON-RPC message」wire format 也可以直接用在 Unix domain socket、TCP 或其他可靠的雙向 byte stream。這類自訂 transport SHOULD（應該）重用 stdio framing。

送出訊息（Sending Messages）

用戶端將 JSON-RPC requests 與 notifications 一行一個寫入伺服器的 stdin。用戶端 MUST NOT（不得）寫入 JSON-RPC responses。

接收訊息（Receiving Messages）

用戶端從伺服器的 stdout 一行一個讀取訊息；所有 message 共用單一 channel，沒有 per-request stream。

伺服器會寫出三種訊息：

1. 對用戶端 request 的 responses，透過 JSON-RPC id 對應。
2. 與進行中 request 有關的 notifications，例如 notifications/progress 與 notifications/message。
3. 由有效 subscriptions/listen request 所產生的通知；用戶端 MUST（必須）以 _meta.io.modelcontextprotocol/subscriptionId 對應所屬訂閱。

伺服器 MUST NOT（不得）把 JSON-RPC requests 寫到 stdout。需要 server-to-client input 的互動會改由 InputRequiredResult 承載，依 MRTR 流程完成。

請求中繼資料（Request metadata）

stdio 的所有 request metadata 都直接放在 JSON-RPC message body 裡。協定版本、per-request capabilities 與選用的 client identity 位於 _meta.io.modelcontextprotocol/*；method name 與 arguments 則留在 JSON-RPC 原本的欄位。stdio 沒有額外的 header layer。

取消（Cancellation）

要取消進行中的 request，用戶端 MUST（必須）送出 notifications/cancelled，並指向該 request 的 ID。因為 stdio 所有訊息都共用單一雙向 channel，不存在可以針對單一 request 關閉的 stream。

伺服器 SHOULD（應該）盡快停止被取消的工作，並 MUST NOT（不得）再為該 request 送出後續訊息。

關閉（Shutdown）

用戶端 SHOULD（應該）依下列順序開始 shutdown：

1. 關閉 child process（伺服器）的 input stream。
2. 等待伺服器結束。
3. 若伺服器未在合理時間內退出，再使用作業系統適當機制強制終止。

在 POSIX 系統上通常會從 SIGTERM 升級到 SIGKILL；Windows 則可使用 TerminateProcess 或 Job Objects。

伺服器在 stdin 關閉或讀到 EOF 時 SHOULD（應該）迅速退出。這是主要且可攜的 graceful-shutdown signal。伺服器也 MAY（可以）主動關閉自己的 output stream 後退出。

非預期終止（Unexpected Termination）

若 server process 非預期退出，用戶端 SHOULD（應該）重新啟動它。由於 2026-07-28 的協定是 stateless，進行中的 requests 會直接失效，用戶端可對新的 process 重新嘗試。原本有效的 subscriptions/listen 也必須重新建立。

向後相容（Backward Compatibility）

同時支援 Modern 與需要 initialize handshake 的 Legacy MCP 用戶端，SHOULD（應該）在送出其他 request 前先用偏好的 modern version 呼叫 server/discover：

• 若收到 DiscoverResult，伺服器是 Modern；從 supportedVersions 選出雙方都支援的版本。
• 若收到已知的 Modern JSON-RPC error，例如 UnsupportedProtocolVersionError，表示伺服器仍是 Modern，只是不支援指定版本；應改用它列出的 supported 版本，不要 fallback 到 initialize。
• 若收到其他錯誤，或在合理 timeout 內沒有 response，則把伺服器視為 Legacy，fallback 到 initialize handshake。

Fallback MUST NOT（不得）只綁定單一 error code，因為 Legacy server 對 pre-initialize unknown request 的錯誤可能是 implementation-defined，常見例如 -32601、-32602，也可能完全不回覆。

只支援 Modern MCP 的用戶端不必做 probe，但仍 RECOMMENDED（建議）執行，因為部分 Legacy server 可能不驗證 request 是否在 initialize 之後才出現，導致 era-ambiguous method 被錯誤地用 Legacy semantics 處理。