WordPress MCP 目前到底能做什麼？很多介紹會讓人以為，只要裝上官方 MCP Adapter，Claude、Codex 或 Cursor 就能直接新增文章、上傳圖片、更新外掛，甚至接管整個 WordPress 後台。實際情況沒有這麼一步到位。
截至 2026 年 8 月，WordPress 已經把 AI Agent 需要的底層架構準備好，但原生提供的操作仍然偏保守。WordPress 7.0 核心只有 3 個唯讀 Ability；其他寫入或管理操作，要由外掛另外註冊。這篇就從官方英文文件出發，講清楚哪些已經可以用、哪些還只是未來方向。
先講我的結論：WordPress MCP 現在比較像一個安全、可擴充的 AI 操作入口，不是完整的 WordPress 遙控器。
WordPress MCP 是什麼？先分清楚兩個元件
官方架構分成兩層。第一層是從 WordPress 6.9 進入核心的 Abilities API，第二層才是獨立安裝的 WordPress MCP Adapter。
Abilities API：把網站功能整理成 AI 看得懂的能力
Ability 可以理解成一個有名稱、有說明、有輸入格式、有輸出格式，也有權限檢查的 WordPress 動作。例如「讀取網站資訊」、「取得商品庫存」或「建立一篇草稿」。外掛開發者透過 wp_register_ability() 註冊後，WordPress 就知道這個功能怎麼呼叫。
MCP Adapter：把 Ability 翻譯成 AI Agent 能使用的 MCP
MCP Adapter 不負責憑空生出網站管理功能。它的工作是把已註冊的 Ability 轉成 MCP 的 Tool、Resource 或 Prompt，讓 Claude Code、Codex、Cursor、VS Code 等 MCP Client 可以發現並執行。
所以真正決定「AI 能操作什麼」的，不是 MCP 這三個字，而是你的 WordPress 核心與外掛總共註冊了哪些 Ability。
截至本文更新時間，官方 MCP Adapter 最新穩定版是 v0.6.1，需求為 WordPress 6.9 以上。若你曾下載 v0.6.0 的 Release ZIP，官方建議升級到 v0.6.1；從 Composer 或原始碼安裝的 v0.6.0 不受那個封裝問題影響。
WordPress 7.0 核心目前支援哪些 MCP 操作？
依照 WordPress 官方的 WP-CLI Ability 文件，標準 WordPress 7.0 網站目前有 3 個核心 Ability，而且全部都是唯讀。
| 核心 Ability | 能做什麼 | 是否修改網站 |
|---|---|---|
core/get-site-info | 讀取網站名稱、網址、網站說明、管理員信箱、字元編碼、語言與 WordPress 版本 | 否，唯讀 |
core/get-user-info | 取得目前已登入使用者的基本資料，讓工具知道目前是用哪個身分操作 | 否，唯讀 |
core/get-environment-info | 讀取執行環境、PHP 版本、資料庫伺服器資訊與 WordPress 版本，適合相容性檢查 | 否，唯讀 |
這三項可以讓 AI 回答「這是哪一個站」、「目前 WordPress 與 PHP 版本是多少」、「我用什麼使用者身分連線」。但它們還不能讀取文章列表，更不能新增、修改或刪除文章。
這也是我覺得最容易被誤會的地方：Abilities API 已進入 WordPress 核心，不等於完整的後台管理功能已經全部開放給 AI。
官方 MCP Adapter 預設提供的 3 個工具
安裝 MCP Adapter 後，預設 MCP Server 會先向 AI Client 提供 3 個入口。官方稱它為 layered discovery，也就是先找能力、再看規格、最後執行。
| MCP 工具 | 用途 | 我會怎麼理解 |
|---|---|---|
mcp-adapter-discover-abilities | 列出目前允許透過 MCP 公開的 Ability | 先看這個網站會什麼 |
mcp-adapter-get-ability-info | 取得某個 Ability 的完整輸入、輸出與權限規格 | 確認參數要怎麼傳 |
mcp-adapter-execute-ability | 帶入參數並執行指定 Ability | 正式呼叫網站功能 |
這樣設計的好處，是網站即使有幾十個或幾百個 Ability，AI 一開始也不用把全部工具規格塞進 Context Window。它只在需要時查詢細節，對大型網站比較省 Token，也比較不容易選錯工具。這項設計可在官方的 Default MCP Server 文件中看到。
現在還不能原生操作哪些 WordPress 功能？
如果只有 WordPress 7.0 核心加官方 MCP Adapter，下面這些常見需求都不是目前內建的 MCP 操作：
- 列出、搜尋、新增、修改、發布或刪除文章與頁面
- 上傳圖片、設定精選圖片或管理媒體庫
- 建立分類、標籤或自訂分類法
- 讀取與管理留言
- 新增、修改或刪除使用者
- 安裝、啟用、停用或更新外掛與佈景主題
- 修改網站設定、固定網址或選單
- 管理 WooCommerce 商品、庫存與訂單
- 更新 Rank Math、Yoast SEO 或 ACF 欄位
不是 MCP 做不到，而是官方核心目前沒有把這些動作註冊成可用 Ability。開發者可以自己做，也可以等待各外掛作者陸續支援。
外掛註冊 Ability 後，MCP 可以擴充到哪些操作？
Ability 是開放架構。只要外掛有定義輸入、輸出、執行函式與權限，就能把原本的 WordPress 功能交給 MCP Client 使用。
| 擴充方向 | 可能提供的 Ability | 實際應用 |
|---|---|---|
| 內容管理 | 查詢文章、建立草稿、更新內容、排程發布 | 讓 AI 協助寫文與維護舊文章 |
| 媒體管理 | 上傳圖片、讀取媒體、設定 alt 與精選圖片 | 完成文章加封面的工作流 |
| SEO | 更新 SEO 標題、描述、Schema 與轉址 | 建立可重複的 SEO 維護流程 |
| WooCommerce | 讀取商品、更新庫存、建立報表 | 讓 AI 助理處理電商資料 |
| 網站維運 | 清快取、讀取版本、執行安全檢查 | 協助維護人員排查問題 |
| 自訂外掛 | CRM、預約、表單、會員或公司內部流程 | 把企業專屬流程變成 AI 可呼叫工具 |
我現在透過 AI 助手管理 WordPress所做的文章、媒體、SEO 與快取流程，很多是建立在 REST API 與自訂外掛上。未來可以再包成 Ability，讓 MCP 負責工具發現與呼叫，但後面的 WordPress 商業邏輯仍然要有人實作。
WordPress MCP 和 REST API 有什麼差別？
REST API 已經是 WordPress 很成熟的整合方式，MCP 並不是拿來把它整套淘汰。兩者比較像不同層級的入口。
| 比較項目 | WordPress MCP | WordPress REST API |
|---|---|---|
| 設計對象 | AI Agent、MCP Client | 網站、App、外部系統與各種程式 |
| 操作模型 | 以「能力／動作」為中心 | 以「資源／Endpoint」為中心 |
| 功能發現 | AI 可以先 discover，再讀取 Schema | 通常要先閱讀 API 文件或知道路由 |
| 內建涵蓋範圍 | WordPress 7.0 核心目前很少 | 文章、頁面、媒體、分類、留言、使用者等相對完整 |
| 權限 | MCP 傳輸驗證加上每個 Ability 的 permission callback | WordPress 使用者權限與 Endpoint permission callback |
| 成熟度 | 正在快速發展，外掛支援仍在累積 | 成熟、文件與實作案例多 |
| 適合情境 | 讓 AI 動態理解並執行網站能力 | 穩定的系統串接、批次作業與完整 CRUD |
如果你現在就要穩定地新增文章、更新分類、上傳媒體，我仍會先用 REST API。相關認證方式可以參考我的 WordPress REST API 應用程式密碼教學。MCP 的價值則是讓 AI 不必事先背下每條 API 路由，而是自己發現可用動作。
怎麼查看自己的 WordPress 目前有哪些 Ability？
有主機與 WP-CLI 權限時，最快的方法是直接執行：
wp ability list查看單一 Ability 的 Schema 與權限資訊：
wp ability get core/get-site-info實際執行並只取回網站名稱與版本：
wp ability run core/get-site-info \
--input='{"fields":["name","version"]}' \
--user=admin安裝 MCP Adapter 後，也可以用下面的指令查看 MCP Server：
wp mcp-adapter list預設 HTTP 入口是：
https://example.com/wp-json/mcp/mcp-adapter-default-server如果你還分不清 MCP、Skills 與 Agent 的角色，可以先看 AI Skills、MCP、Agent 完整比較，會比較容易理解這整套架構。
WordPress MCP 的安全性要注意什麼？
官方 MCP Adapter 的 Ability 預設不是公開狀態，必須設定 meta.public 或 meta.mcp.public 才會被預設伺服器發現。執行時還會檢查登入身分與 Ability 自己的權限 callback。
- 建立 AI 專用 WordPress 帳號，不要直接使用主要管理員
- 只給工作需要的最低權限
- 讀取與寫入 Ability 分開設計
- 新增文章預設先存草稿，不要直接發布
- 刪除、更新外掛、修改設定等高風險操作應增加人工確認
- 正式站導入前，先在測試站驗證輸入、輸出與錯誤處理
- 保留操作紀錄，知道哪個帳號在什麼時間執行哪個 Ability
MCP 讓 AI 更容易操作網站，也代表權限設計不能偷懶。真正的風險往往不是模型突然失控，而是開發者把一個權限過大的功能公開給它。
WordPress 7.1 可能新增哪些核心能力？
WordPress Core 團隊已提出 7.1 擴充計畫，預計先加入 core/read-settings、core/read-content 與 core/read-users 三個唯讀能力。這會讓標準 WordPress 網站開始具備讀取設定、文章與使用者的基礎。
不過截至本文更新時間，這仍是 WordPress 7.1 的合併提案，不能當成 WordPress 7.0 已經支援的功能。至於文章寫入、媒體、留言、外掛、佈景主題與分類管理，官方也把它們列為後續可能發展的方向。
我的看法：現在適合導入 WordPress MCP 嗎？
如果你期待裝完外掛就能叫 AI 全自動經營網站，我會建議先不要把預期拉太高。官方基礎已經可以用，但內容與管理能力仍要靠外掛補上。
如果你是 WordPress 外掛開發者，現在反而是很好的投入時間。把既有 PHP、REST API 或後台功能整理成 Ability，未來就能同時接 MCP、WordPress 後台的 Client-side Abilities，甚至其他 Agent 工作流。這和我在 WordPress 7.0 AI 功能整理提到的方向是一致的：WordPress 正在建立一個不被單一 AI 廠商綁住的開放層。
對企業網站來說，我目前會採取 REST API 與 MCP 並行。REST API 負責成熟、穩定的資料操作；MCP 負責讓 AI 發現能力、理解參數與組合工作流程。這樣比較務實，也不需要為了追新技術把原本能用的系統全部重做。
常見問題 FAQ
WordPress 7.0 已經內建 MCP 嗎？
WordPress 7.0 內建的是 Abilities API，不是完整 MCP Server。要讓 Claude、Codex 或 Cursor 透過 MCP 連線，仍需安裝官方 MCP Adapter 或由其他外掛整合這個套件。
安裝官方 MCP Adapter 後，AI 可以直接新增文章嗎？
不行。WordPress 7.0 核心目前只有網站資訊、使用者資訊與環境資訊三個唯讀 Ability。必須另有外掛註冊建立文章的 Ability，AI 才能新增草稿或發布文章。
WordPress MCP 可以取代 REST API 嗎？
目前不適合完全取代。REST API 對文章、媒體、分類、留言與使用者等資源的支援更成熟；MCP 比較擅長讓 AI 動態發現網站能力。實務上可以讓兩者並行。
WordPress MCP 連線一定要使用管理員帳號嗎？
不需要，也不建議。應建立專用帳號並給最低必要權限。每個 Ability 還需要自己的 permission callback，避免普通內容操作帳號取得外掛更新或網站設定等高風險權限。
WordPress 7.1 會支援讀取文章嗎？
官方已提出加入 core/read-content、core/read-settings 與 core/read-users 的計畫，但截至 2026 年 8 月仍屬 WordPress 7.1 合併提案，正式版本與實際功能仍要以發布結果為準。
