把 WordPress 接成 MCP server：讓 AI agent 幫我走完全程的紀錄

By shortie資訊科技

這次想做一件「把 AI 拉進工作流程」的事：讓 Codex 這個 AI agent 直接讀寫我的 WordPress 網站。發文章、改分類、看健康檢查，都不用開後台，也不用自己敲一長串命令。

有趣的是，整段設定幾乎都是 agent 自己完成的。我只做了兩件事：把網站交給它，以及在它要寫入之前點頭確認。下面把過程去識別化後記下來，你的網站也可以照著做。

先看重點

  • 網站端：安裝 Easy MCP AI 外掛，WordPress 就變成一個 MCP server。
  • 認證方式：OAuth，支援動態註冊用戶端（DCR）與 PKCE，不用手動建 client，也不用手動換 token。
  • 最容易踩的坑：Codex 設定裡的網址，必須和伺服器公布的 resource 網址一字不差。固定網址（permalink）帶 /index.php/ 的網站，少了這段就會出現 resource mismatch。
  • 我的分工：把網站交給 agent、在瀏覽器按一次同意、寫入或刪除前先確認。其他都交給 agent。

環境

項目這次用的
網站WordPress，固定網址格式為 /index.php/%year%/...
MCP 外掛Easy MCP AI（WordPress.org 外掛目錄上的免費外掛）
AI agentCodex CLI 0.164.0
作業系統macOS

整個流程一覽

步驟agent 做了什麼我做了什麼
1. 探測端點試了幾條路徑，找到 MCP 端點—
2. 判斷認證方式從 401 回應判斷要走 OAuth—
3. 授權啟動 OAuth 流程，取得 token在瀏覽器按同意
4. 驗證列工具、讀文章、跑健康檢查—
5. 寫進設定把端點寫進 Codex 設定檔—
6. 排除錯誤比對網址，找出 resource mismatch 的原因—
7. 確認持久化重新啟動後確認不用再授權—

第一步：agent 自己找端點

我沒有先把網址查好交給它。agent 直接對網站試了幾條路徑，很快就找到 MCP 端點：

https://example.com/index.php/wp-json/easy-mcp-ai/v1/mcp

easy-mcp-ai 是網站上 Easy MCP AI 外掛提供的路徑。網址中間要不要有 /index.php/，取決於網站的固定網址設定：一般設定是 /wp-json/...；像我這種固定網址帶 /index.php/ 的網站，REST API 也要加上這一段。這次 Codex 和伺服器協商的 MCP 協定版本是 2025-11-25。光是這一步，就省掉了我最怕的「翻文件、對版本」。

第二步：遇到 401，判斷要走 OAuth

第一次連線就收到 401 Unauthorized，回應標頭帶著 WWW-Authenticate: Bearer，裡面指出去哪裡讀取這個資源的授權資訊。以前我得自己查這是哪一種認證。agent 直接讀懂了：這是 OAuth，而且伺服器支援動態註冊用戶端（DCR）與 PKCE（S256），所以可以走瀏覽器授權，不必手動建 client、手動換 token。

第三步：在瀏覽器按一次同意

agent 啟動授權流程，我在瀏覽器登入 WordPress、選好權限範圍，按下同意。Codex 預設會把 token 存進作業系統的金鑰圈（macOS 上就是 Keychain），不會寫進一般的文字檔。

第四步：用三件事驗證真的連上了

拿到權限後，agent 立刻做了三個測試：

  1. 列出所有工具：這次授權範圍內共有 137 個，涵蓋文章、分類、標籤、媒體、選單、健康檢查等。工具數量會隨你授權的範圍不同而改變。
  2. 讀一篇舊文章：確認讀取正常。
  3. 跑一次網站健康檢查：確認能拿到即時狀態。

三項都通過，才算 agent 真的「握住」了網站，而不是只停在理論上連得上。

第五步：寫進設定，下次直接用

agent 把端點寫進 Codex 的設定檔 ~/.codex/config.toml：

[mcp_servers.wordpress]
url = "https://example.com/index.php/wp-json/easy-mcp-ai/v1/mcp"
oauth_resource = "https://example.com/index.php/wp-json/easy-mcp-ai/v1/mcp"

url 是 MCP 端點；oauth_resource 是申請 token 時告訴授權伺服器「這個 token 要給哪個資源用」。截至本文撰寫時，OpenAI 的 Codex 官方文件還沒有列出 oauth_resource，但 Codex CLI 0.164.0 已經支援這個設定。

第六步：踩到 resource mismatch，agent 自己找出原因

這是整個過程最有價值的一段。一開始 agent 用的網址沒有 /index.php/，授權時就被拒絕，錯誤是 resource mismatch。

原因在於 MCP 的授權規範：

  • 伺服器會在自己的「受保護資源中繼資料」（RFC 9728）裡公布它的正式網址。這個網站公布的是帶 /index.php/ 的網址。
  • 用戶端申請 token 時，要用 resource 參數（RFC 8707）說明 token 給誰用，而且這個值必須和伺服器公布的正式網址一致。
  • 兩邊差了 /index.php/ 這一段，伺服器就判定不符，拒絕發 token。

換作是我自己，大概要對著 RFC 研究半天。agent 把「設定裡的網址」和「伺服器公布的 resource」並排比對，問題一目了然：url 和 oauth_resource 都改成帶 /index.php/ 的正式網址，就通了。這種「看起來是小事，其實牽涉兩個端點要對得上」的問題，正是 agent 最拿手的。

第七步：確認重開後不用再授權

重新啟動 Codex 之後，不用再走一次瀏覽器授權：token 還在金鑰圈裡，到期時會用 refresh token 自動更新。到這裡，整條路才算真的接穩了。

人到底做了什麼？

整段下來，我只做了三件小事：把網站交給 agent、在瀏覽器按一次同意、在它寫入或刪除前先確認。探測、判斷認證方式、試錯、找出問題、寫設定、驗證，全是 agent 做的。

這正是我想強調的：agent 的價值不在幫你執行一個指令，而在它能自己把一整條不確定、會出錯的設定路徑走完。

照著做：五個步驟

把 example.com 換成你自己的網址：

  1. 安裝外掛：在 WordPress 後台安裝並啟用 Easy MCP AI。
  2. 確認端點網址：一般是 https://example.com/wp-json/easy-mcp-ai/v1/mcp；固定網址帶 /index.php/ 的網站，要用 https://example.com/index.php/wp-json/easy-mcp-ai/v1/mcp。拿不準的話，看外掛後台顯示的 MCP 網址，或讓 agent 去探測。
  3. 加入 Codex：執行 codex mcp add wordpress --url <端點網址>。如果遇到 resource mismatch，就在 ~/.codex/config.toml 補上 oauth_resource，值和 url 相同。
  4. 授權：執行 codex mcp login wordpress，在瀏覽器登入 WordPress、選擇權限範圍並同意。
  5. 驗證：重新啟動 Codex，確認不用再授權，而且列得出工具。

安全與使用習慣

  • 不要公開敏感資訊：OAuth token、client ID、金鑰圈的雜湊值、主機 IP 這類東西，絕對不要貼進文章或留言。本文的網址與識別資訊都已去識別化。
  • 權限只給需要的：授權時只勾選會用到的範圍，外掛、佈景主題、使用者管理這類高風險權限，用到再開。
  • 我對 agent 的鐵律：寫入與刪除前先確認。讀取可以放手，改東西要先點頭。
  • 取消或重新授權：想取消連線，執行 codex mcp remove wordpress；想清除 token，執行 codex mcp logout wordpress；想重新授權，執行 codex mcp login wordpress。也可以到 WordPress 後台的 Easy MCP AI 撤銷授權。

一句話總結：把不確定的設定工作交給 AI agent，它會探、會判斷、會試、會修。你負責決定方向和把關，它負責把路走完。

參考資料

本文由作者及其 AI 助理協作完成。

發佈留言