Meta 推出 WhatsApp Business MCP Server，讓 AI 代理自動處理設定瑣事

外電這幾天報的是「Meta 推出 WhatsApp Business MCP Server，讓 AI 代理幫你處理設定瑣事」。這句話沒錯，但它把兩件事講成一件，而且漏掉了對開發者最要緊的那一項：你的 AI 代理到底被允許動什麼。

我們去看了 Meta 自己的文件。

上線的是兩支，管的東西不一樣

Meta 的 MCP 文件頁上列的是兩支獨立的伺服器。

Meta Social Technologies MCP 管的是開發者平台本身：設定 webhook、查合規狀態、看 App 審核狀態、監控 API 健康度、搜尋開發者文件。

WhatsApp Business Tools MCP 管的才是 WhatsApp 商業帳號，官方列的能力是查找商家與帳號、上線與註冊電話號碼、管理訊息模板、設定 webhook、發送訊息。

所以新聞講的「幫你設定帳號、管訊息模板」是真的，但那是第二支的事。第一支跟 WhatsApp 沒什麼關係，它是給所有 Meta 平台的開發者用的，涵蓋 WhatsApp、Instagram、Messenger 與 Threads。

開發者工具那支：官方明說「webhook 是唯一能寫入的地方」

這一支的細節文件是公開的，我們逐項比對過原文。

端點是 mcp.facebook.com/devtools，走 Streamable HTTP，不是舊的 stdio。認證用你既有的 Meta 開發者帳號走 OAuth。官方明白標示 Beta，介面與工具集可能會變。支援五個客戶端：Claude Code、Claude Desktop、Codex App、ChatGPT、Cursor。它是遠端伺服器，只支援本機 stdio 的客戶端要透過 mcp-remote 橋接。⚠️ 官方另外註明：這個伺服器正在逐步推出，可能還不是每個人都能用。

工具名稱一律以 devtools_ 開頭。官方文件沒有逐一列出工具清單，但它的權限表格把「這個伺服器開放了什麼」寫得很清楚：App 設定與組態、App Review 狀態、合規狀態、API 用量與健康度、webhook 主題與訂閱。

權限只有兩級，而且官方把話講死了。Read 是「對上述全部唯讀」；Manage 是「Read 的全部，加上 webhook 的建立、更新、刪除與送出測試 payload」——原文接著補了一句：webhook 是這個伺服器唯一能寫入的地方。

連送測試 payload 都被歸在 Manage，官方給的理由是它雖然不存任何東西，但會讓 Meta 真的對你的 callback 網址送出一個事件。把它排除在 Read 之外，是為了讓唯讀授權不可能被誘導成觸發實際投遞。

換句話說，你可以叫代理人把整個 App 的狀態查一遍、告訴你哪個權限還沒過審、哪支 API 快撞到速率上限，但它不能替你改 App 設定。

這代表什麼

新聞的框架是「後台瑣事自動化、門檻降低」。看完文件之後，我們認為更準確的說法是：Meta 先把「查」開放給代理人，「改」幾乎還鎖著。

這是保守但合理的設計。App 設定改錯的後果是線上服務出事，而目前沒有任何 MCP 客戶端能保證模型不會誤判。先開唯讀，是把風險留在自己手上。

對開發者的實際影響也因此比較溫和：你省下的是「開十個分頁查狀態」的時間，不是「不用懂 Meta 平台」。要接 WhatsApp Business 該過的審核、該驗的商家，一樣都跑不掉。

我們還不知道的

WhatsApp Business Tools 那一支的詳細工具清單頁需要登入才看得到，以下幾項我們沒有第一手資料，也不用推測填：它的寫入權限是否也像開發者工具那支只開一小塊、有沒有地區限制、要不要先有已驗證的商家或既有的 Business Manager、「上線與註冊電話號碼」實際能做到哪一步。

官方在開發者工具那支把寫入卡在只有 webhook，WhatsApp 那支會不會一樣嚴，目前無從判斷。

本文事實依據為 Meta for Developers 官方文件，非二手報導轉述。需登入才能取得的部分已於文中標明。