後台真的會被 MCP 取代嗎？從 MCP Apps 到 WebMCP 的實測與思考

最近常看到一種說法：

我的直覺是不會。

後台有很多操作牽涉到金流、權限和批次修改，只在對話框裡打一句「幫我退款」就讓它跑，我不太放心。

沒有畫面讓人看著確認，信心不夠。

不過為了確認自己不是在抗拒新東西，我翻了一些文章和大公司的動作，看看後台能不能直接變成 MCP-first。

網路上的三種說法

看下來大致可以分成三派：

1. Dashboard 會消失

這派的文章標題都很直截了當，像是 Goodbye dashboards、Voice + MCP 會殺死 dashboard。Yext 的部落格也有一篇文章提到，之後的產品會圍繞著資料打轉，UI 反而沒那麼重要。

大公司也真的開始把「去 UI」當賣點，Salesforce 在 TDX 2026 推出 Headless 360，把平台能力包成 API、MCP tool 和 CLI，宣傳主打不需要瀏覽器。

但這些大多是廠商部落格或個人評論，我沒找到「後台真的被 MCP 取代」的採用數據。

2. MCP 疊在後台上

這派比較務實，沒有要拿掉原本的 UI，而是把 MCP 當成另一個操作後台資料的入口：

• WorkOS 推出的 management MCP server 就是很典型的手法，你在 MCP 裡拿到的操作權限，直接對齊你登入 Dashboard 的權限。
• 不少開源專案的做法是在既有後台裡開一個 /api/mcp 端點，底層寫入依然走原本的 API route。
• 不過 Growthrocks 也提醒，只是在既有產品外層包一個 MCP server，不代表你的產品就是「MCP-first」。

3. UI 改由 agent 按需產生

純文字對話不好用，那就讓 agent 邊聊邊把 UI 生出來，這也是現在各家在推的方向，ChatGPT 有 Apps in ChatGPT，Gemini 有 dynamic view，Claude 也能在畫面上生成 UI 甚至流程圖。

「MCP 沒有畫面」這個論點已經不成立

我原本反對後台 MCP 化的理由是：

MCP 沒有辦法顯示 UI。

但這個理由在 2026 年 1 月就不成立了。

MCP Apps（SEP-1865）是 MCP 的第一個官方 extension（見官方 blog），讓 MCP server 不只回傳文字，也能回傳可以互動的 UI。MCP server 現在可以直接用 ui:// 宣告互動介面，由 Host 用 sandboxed iframe 渲染出來。它是從 MCP-UI 和 OpenAI Apps SDK 演變來的。

也就是說，MCP 現在也能在聊天視窗裡顯示表格和確認按鈕。

所以問題變成：

MCP Apps 為什麼取代不了後台？

一個跑了幾年的後台，累積了很多業務邏輯和流程，不是 agent 臨時生一張卡片就補得上的：

• 完整的上下文：改一筆訂單之前，你會順便看到相關的退款、備註和歷史紀錄，agent 產生的卡片只會顯示它覺得相關的部分。
• 大量操作和比對：篩選、排序、一次改 200 筆，在對話框裡叫 agent 一筆一筆列給你看，會很痛苦。
• 權限、稽核和責任歸屬：出問題時，是誰、在什麼時間、在哪個畫面按了確認？對話框臨時產生的卡片很難歸因。
• 可發現性：後台的側欄和選單會讓你看到有哪些功能，聊天框只會等你開口問，如果要接觸一個新的業務範圍，不熟悉後臺的人不一定能夠成功問對問題，甚至用錯了功能也有可能。

WebMCP 是什麼？跟 MCP 差在哪？

WebMCP 是一個 web API 提案，讓網頁透過 document.modelContext 把自己的功能註冊成 tool，agent 在瀏覽器裡就能直接呼叫。後台留著給人用，同時開一個入口讓 agent 進來用，就是它想解決的問題。

MCP 跑在 server 端，WebMCP 的 tool 則跑在頁面自己的 JavaScript 裡，沿用使用者當下在頁面上的登入 session。

官方 explainer 把 human-in-the-loop 列為目標，也明確寫了不取代人用的介面。

Chrome 在 When to use WebMCP and MCP 這篇文章裡把兩者的分工講得很清楚：

套到後台上，分工大概是：

• 背景、批次、跨系統的工作，交給 MCP server
• 需要人看著、確認的操作，用 WebMCP 讓 agent 在後台畫面裡把表單填好，最後由人按送出

現在能用 WebMCP 了嗎？

還不行，chromestatus 上 WebMCP 的狀態還是 Proposed：

• origin trial 原本是 Chrome 149–156，已經延長到 162
• 正式上線的版本還沒確定，blink-dev 上也還沒有 Intent to Ship
• 照 Chromium Dash 的排程推算，Chrome 162 穩定版要到 2027-02-02。

所以要在瀏覽器原生用到 WebMCP，最快也是 2027 年的事。

Cloudflare 的 WebMCP 開關

Cloudflare 在 2026-08-06 推出了 WebMCP developer preview，在 dashboard 的 Agent Readiness 打開開關，就會在你網站的每個頁面插入 /.webmcp/bridge.js。

但它不是 polyfill，背後還是要 Chrome 原生支援 WebMCP，沒開 flag 的 Chrome 上根本沒有 modelContext。ContextBolt 的實測也發現，它的 Site MCP Server 這組工具，只是把你網站上原本就有的 /mcp 接進頁面。

作者的形容很貼切：「a socket, not an appliance」。

想在原生不支援的瀏覽器上用，要靠 @w3c/webmcp-polyfill 或 MCP-B。

實測 Cloudflare dashboard 自己有 WebMCP 嗎？

Cloudflare 幫別人的網站做 WebMCP，那它自己的 dashboard 呢？

2026 年 10 月，我用 Claude in Chrome 在 Chrome 156 上打開 dashboard 實測看看：

await document.modelContext.getTools()

結果：

• 我的 Chrome 版本是 156，document.modelContext 存在，API 是可以用的
• 帳號列表、帳號首頁、網域首頁、Analytics 頁面，註冊的 tool 都是 0 個
• 頁面上沒有 toolname 這種 declarative 宣告，也沒有 origin trial token
• dashboard 載入的 229 支 JS 裡，沒有任何一支出現 registerTool 或 modelContext

也就是說，截至 2026 年 10 月，Cloudflare dashboard 本身還沒有 WebMCP 化。

但 agent 其實已經在查後台的數據了

有趣的是，2026 年 10 月我請 agent 調查公司網站的流量變化，它確實從 Cloudflare dashboard 查到了數據。

我回頭翻 tool call 紀錄，才知道它是怎麼做的：

1. 用 Claude in Chrome 的 javascript_tool，在已登入的 dashboard 分頁裡執行 JavaScript
2. 列出頁面載入的資源，發現 dashboard 前端會打 dash.cloudflare.com/api/v4/graphql
3. 攔下 dashboard 自己送出的查詢，照著格式自己組 query
4. 直接 POST，請求會自動帶上登入 cookie，不用另外申請 API token

await fetch('/api/v4/graphql', {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({ query, variables }),
}).then((r) => r.json())

它查的是 httpRequestsAdaptiveGroups，依 cache status、狀態碼、userAgent 分組。

這不是什麼內部 API，而是 Cloudflare 公開文件裡的 GraphQL Analytics API。差別只在入口，官方用法是打 api.cloudflare.com 並帶 API token，agent 則是走 dashboard 的路徑，借用使用者的登入身分。

所以提供 API 讓 Agent 使用這也是一個方法，但是：

• 很脆弱：agent 得自己翻 network 請求、從 dashboard 的查詢反推格式，哪天前端改版就可能壞掉
• 權限控管：整個登入身分都交給 agent，網站沒辦法限制它能查什麼、能改什麼
• 沒有確認步驟：網站沒辦法要求「這個操作要使用者按確認」

如果 dashboard 支援 WebMCP，Cloudflare 就能自己註冊像 query_traffic(zone, range, groupBy) 這樣的 tool，輸入格式是網站定的穩定約定，哪些操作開放、哪些要使用者確認，也由網站決定。

小結

後台會不會被 MCP 取代？

不是因為 MCP 沒有畫面，MCP Apps 已經可以讓 Agent 生成 UI。而是因為後台是人確認 agent 做了什麼的地方，它的上下文、批次操作、權限和稽核，都不是臨時生成的卡片能取代的。

比較值得問的問題是：

背景工作交給 MCP server，需要人確認的操作留在後台，用 WebMCP 把門正式開出來，而不是讓 agent 繼續從 network 請求裡找後門。

之後還會再寫另外一篇，探討使用者操作的網頁會不會 MCP 化？或是 AI 會不會取代既有的網頁流程？

在 AI 爆發之後，有些人會說會不會 web 已經死亡，用 AI 來購物會不會是一個趨勢？這會是跟後臺不一樣的出發點，但也是很值得探討的議題。

Reference

• Goodbye dashboards: How MCP Servers are changing work
• Headless SaaS and MCP: The Apps That Win Will Compete on Data, Not UI
• Salesforce Headless 360
• WorkOS MCP
• MCP-first apps
• SEP-1865: MCP Apps
• WebMCP explainer
• When to use WebMCP and MCP
• WebMCP on chromestatus
• Give any website a WebMCP interface
• Cloudflare WebMCP: 115 Bytes and Two Tools
• Cloudflare GraphQL Analytics API