LINE MCP 是什麼?兩種串接方向比較與實作教學

Chatbotta 創易聊 · · 更新於

搜尋「LINE MCP」會找到兩種看起來很像、其實方向相反的東西:一種是讓你的 AI agent 去發 LINE 訊息, 另一種是讓 LINE 上的客服 AI 去呼叫你的工具。選錯方向,會發現做出來的東西根本不能回覆顧客。 這篇文章先把兩個方向講清楚,再分別說明怎麼做。

先搞懂 MCP:AI 使用工具的共通規格

MCP(Model Context Protocol)是一個開放協定,讓 AI 應用以標準化的方式連接外部工具與資料來源。 把「查訂單」「查庫存」做成一個 MCP server 之後,任何支援 MCP 的 AI 應用都能使用,不用為每個平台重寫一次整合。

一個 MCP 連線有兩端:使用工具的 AI(client)與提供工具的 server。 「LINE MCP」的兩個方向,差別就在 LINE 站在哪一端。

LINE MCP 的兩個方向

方向一:AI agent → LINE 方向二:LINE 顧客對話 → MCP 工具
代表做法 LINE 官方 line-bot-mcp-server Chatbotta 外部工具(MCP)
LINE 的角色 被呼叫的工具(發送訊息) 顧客與 AI 對話的通道
誰在用工具 你自己的 AI agent(Claude Desktop、Cursor 等) 面對顧客的客服 AI
能做什麼 推播文字或 Flex 訊息、查詢用戶資料、管理圖文選單 顧客發問時查訂單、改預約、讀內部資料,再回覆顧客
接收顧客訊息 不會 會,webhook 與對話狀態由平台處理
適合 內部自動化、由 agent 主動發通知 對外客服、讓顧客自助查詢與操作

方向一:用 LINE 官方 MCP server 讓 agent 發訊息

LINE 在 GitHub 上提供了 line-bot-mcp-server, 把 Messaging API 包成 MCP 工具。裝好之後,你可以直接對 agent 說「把這份摘要傳到我的 LINE」,由 agent 呼叫工具發送。

  1. 到 LINE Developers Console 建立 Messaging API channel,發行 Channel Access Token(尚未申請官方帳號可先看 LINE 官方帳號認證教學)
  2. 在支援 MCP 的 agent(例如 Claude Desktop、Cursor)的 MCP 設定檔加入這個 server
  3. 重新啟動 agent,確認工具清單中出現推播訊息等工具
{
  "mcpServers": {
    "line-bot": {
      "command": "npx",
      "args": ["@line/line-bot-mcp-server"],
      "env": {
        "CHANNEL_ACCESS_TOKEN": "你的 Channel Access Token",
        "DESTINATION_USER_ID": "預設接收者的 userId"
      }
    }
  }
}
⚠️ 這個專案目前由 LINE 以預覽版形式提供,功能與支援範圍可能調整,實際設定請以官方 README 為準。由 agent 推播的訊息同樣會計入官方帳號的訊息則數,費用計算可參考 LINE 官方帳號收費方案。

要注意它的定位是「發送端」:server 以 stdio 在你的電腦上執行,不接 webhook,所以顧客回覆了什麼,agent 並不知道。 如果你的目標是讓顧客在 LINE 上發問、由 AI 回答,需要的是方向二。

方向二:讓 LINE 上的客服 AI 呼叫 MCP 工具

這個方向要處理的事情比較多:接收 LINE webhook、管理每位顧客的對話狀態、讓 AI 判斷何時該用哪個工具、控制哪些工具可以在真實顧客面前使用、答不了時轉真人。 自己從頭做是一個完整的專案;用 Chatbotta 的外部工具(MCP),這些由平台處理,你只需要準備工具本身。

步驟一:準備一個可以用網址連線的 MCP server

把你要開放的能力(例如訂單查詢)做成 MCP server 並部署到可公開連線的網址。Chatbotta 以網址連線, 優先使用 Streamable HTTP,伺服器不支援時自動改用 SSE;不支援 stdio,只能在本機執行的 server 需要先以 HTTP 對外提供。

還沒有 MCP server?資料量不大的話,可以先把資料放在 Google 試算表,用流程裡的「寫入 Google 試算表」步驟讀取,之後再視需要改成 MCP。

步驟二:串接 LINE 官方帳號

在 Chatbotta 建立專案並貼上 Channel Access Token,平台會自動把頻道的 webhook 指向自己,訊息開始進到統一的對話層。 詳細步驟見連接 LINE 官方帳號。

步驟三:新增外部工具(MCP 連接器)

在專案的「設定」→「小助手與工具」按「新增外部工具」,填入以下欄位:

欄位 說明
名稱 給自己辨識用,例如「訂單查詢」
伺服器網址 MCP server 的網址,例如 https://mcp.example.com/mcp
用途說明 寫給 AI 看的,AI 依此判斷何時該使用這個工具,例如「查詢訂單狀態與出貨進度」
驗證方式 不需驗證、API Token/Bearer Token、OAuth,或每位客人各自授權

選擇 OAuth 時,平台會依 MCP 規範自動向伺服器註冊用戶端並開啟瀏覽器授權;伺服器不支援自動註冊的話,可以改為手動填入用戶端 ID、用戶端密鑰、授權網址與權杖網址。 Token 與密鑰都會加密保存。

步驟四:把工具授權給客服 AI

連線成功後,工具預設只開放給小助手(Copilot),方便你在設計階段查資料、拉流程。 要讓面對真實顧客的機器人使用,需要另外開啟「開放給機器人回覆客人時使用」,並在工具清單的「機器人」欄逐一勾選允許的工具——沒有勾選的工具不會出現在顧客對話中。 建議先只開放查詢類工具,會寫入資料的工具確認行為後再開。

步驟五:需要辨識顧客身分時,使用每位顧客各自授權

「查我的訂單」「幫我改期」這類操作,必須確定對方是誰。選擇「每位客人各自授權」後,顧客第一次用到相關工具時, AI 會在對話中送出授權連結,顧客在來源系統自己的頁面完成授權,之後 AI 就能代表他操作。 授權資料加密保存並綁定來源系統;工具需要的欄位顧客沒說齊時,AI 會先在對話裡追問,不會用猜的送出。

步驟六:測試並發布

  1. 打開右側的「測試」問一輪「我的訂單到哪了」這類問題,確認 AI 有呼叫到正確的工具
  2. 故意問工具答不了的問題,確認會轉真人而不是亂答
  3. 發布後用手機實測。同一套外部工具在 Messenger、Instagram 私訊與網站聊天上也直接可用,不需要重新設定

該選哪一個方向?

  • 想讓自己的 agent 發通知、傳摘要到 LINE:用 LINE 官方的 line-bot-mcp-server
  • 想讓顧客在 LINE 上問問題,由 AI 查你的系統後回答:用 Chatbotta 的外部工具(MCP)
  • 兩種都要:可以並用。前者只發送訊息、不佔用 webhook,兩者不會衝突
  • 問題大多是營業時間、價格、規則這類固定資訊:不需要寫工具,用 AI 知識庫就夠了

想看 MCP 外部工具的完整規格與授權機制,參考 LINE MCP 整合功能介紹; 還在評估要不要自己開發 LINE 機器人,可以先看 LINE 機器人平台比較。

常見問題

Q: LINE MCP 是什麼?

A: LINE MCP 泛指把 LINE 官方帳號和 MCP(Model Context Protocol)接在一起的做法,實際上有兩個方向:一是 LINE 官方的 line-bot-mcp-server,讓 AI agent 透過 MCP 發送 LINE 訊息;二是讓 LINE 上的客服 AI 在對話中呼叫 MCP 工具查資料、辦事情。兩者方向相反,解決的問題也不同。

Q: LINE 官方的 line-bot-mcp-server 可以拿來做客服機器人嗎?

A: 不適合。它提供的是推播訊息、查詢用戶資料、管理圖文選單等「發送端」工具,並不接收顧客傳來的訊息,也沒有對話狀態或轉真人機制。要做能回覆顧客的客服機器人,需要接 Messaging API 的 webhook,或使用已經處理好 webhook 的平台。

Q: Chatbotta 可以直接掛上 line-bot-mcp-server 嗎?

A: 不行,也沒有必要。line-bot-mcp-server 以 stdio 在本機執行,而 Chatbotta 的外部工具是以網址連到遠端 MCP server(Streamable HTTP 或 SSE)。Chatbotta 本身已經負責 LINE 訊息的收發,你要掛上來的是自己的業務工具,例如訂單查詢或預約系統。

Q: 同一個 LINE 官方帳號可以兩種都用嗎?

A: 可以。line-bot-mcp-server 只用 Channel Access Token 主動發送訊息,不會佔用 webhook;Chatbotta 則會把頻道的 webhook 指向平台來接收顧客訊息。要注意的是,由 agent 主動推播的訊息會計入 LINE 官方帳號的訊息則數。

Q: 自己的 MCP server 要符合什麼條件才能掛到 Chatbotta?

A: 需要是能以網址連線的遠端 MCP server,支援 Streamable HTTP(建議)或 SSE。驗證方式可以是不需驗證、API Token/Bearer Token 或 OAuth;若工具需要辨識是哪一位顧客,可使用每位顧客各自授權的模式。