MCP 訊息流程：一個請求走完全場

TL;DR

• Client 跟 Server 之間主要交換兩種訊息：ListTools（問有哪些工具）跟 CallTool（叫工具跑起來）。
• Tool 在 Server 端就是一份 schema 加一個 async function。
• 端到端一個請假請求會在 LLM ↔ App ↔ Client ↔ Server 之間來回多次，每個元件只做自己職責內的事。

兩種主要訊息

連上後，Client 跟 Server 主要交換兩種訊息。

ListToolsRequest / ListToolsResult

「你提供哪些工具？」 → 「我有這幾個，schema 在這。」

通常 App 啟動或第一次需要工具時就發一次，把回來的 tools 餵給 LLM 當 context。

CallToolRequest / CallToolResult

「幫我跑 request_leave，參數是 {from: '2026-05-13', to: '2026-05-14', reason: '個人事務'}。」 → 「跑完了，case id = LEAVE-1234。」

LLM 決定要用工具時，App 透過 Client 發出 CallToolRequest，Server 真的去打 HR API，把結果包成 CallToolResult 回來。

Server 端的 tool 長這樣

// MCP Server 端的工具定義（示意）
server.tool(
  "request_leave",
  {
    description: "送出請假申請",
    inputSchema: {
      from: { type: "string", format: "date" },
      to: { type: "string", format: "date" },
      reason: { type: "string" },
    },
  },
  async ({ from, to, reason }) => {
    const res = await hrApi.createLeave({ from, to, reason });
    return { caseId: res.id, status: res.status };
  },
);

兩件事：

• schema 餵給 ListTools 的回應，LLM 看的是這個。
• handler 是 CallTool 進來時真正執行的函式，可以打任何下游 API。

一個完整的請求走完全場

回到開頭的情境：「下週三、四想請假，幫我看餘額還夠不夠，順便確認我主管那兩天有沒有檔期可以批。」

把三方串起來看訊息怎麼跑：

每個元件都只做一件事：

• App 編排對話：何時叫工具、何時回使用者、要不要先讓人確認
• Client 處理傳輸：把 MCP 訊息序列化送出、解析回來
• Server 實作工具：接到 CallTool 就去做事，不管前面誰呼叫

接下來

概念講完了，接下來幾課會動手做：

• 從 stdio 還是 HTTP transport 起步（看你部署情境）
• 寫第一個 MCP Server（用 HR 工具當例子）
• 寫對應的 MCP Client 把它串起來
• 出問題時用 inspector 工具 debug

想看官方規格直接去 Model Context Protocol 官方介紹。