假設你想請 AI 找出 WordPress 裡所有與線上課程有關的文章。如果沒有連接網站，AI 只能教你怎麼搜尋；如果它透過已授權工具能讀取文章，就可能查詢實際內容，再整理成清單。關鍵不只是 AI 能不能回答，而是有沒有可靠方式取得工作需要的資料。
MCP 便是為這類整合提供共同標準。它讓不同 AI 應用能用相對一致的方法發現外部服務有哪些工具、能取得什麼資訊，以及怎麼呼叫操作。本文根據 MCP 官方 2026 年 7 月 28 日版架構文件整理，說明基本概念、與 API 的差別、WordPress 情境和權限安全。
MCP 是什麼？AI 為什麼需要一種連接標準
MCP 的用途是協助 AI 應用和外部系統交換資訊與工具能力。官方將它比喻為 AI 的 USB-C：只要使用共同的溝通標準，開發者就不必每次都為不同 AI 應用重新設計全部連接邏輯。但有共同標準，不等於每個服務都一定有對應功能。
例如網站有文章系統、報名資料和課程內容，MCP 伺服器可能只開放文章查詢，也可能額外提供更新功能。你需要看實際工具清單及帳號權限，不能因為網站標示支援 MCP，就假設 AI 能查看所有會員資料或直接修改正式網站。
MCP 如何運作？先理解三個角色
MCP 使用用戶端與伺服器架構。主機是你正在操作的 AI 應用；它建立用戶端與 MCP 伺服器聯繫，再根據服務公開的能力取得資料或執行操作。這裡的伺服器是提供 MCP 功能的程式，不一定是一台額外購買的實體主機。
| 角色 | 主要工作 | 容易理解的情境 |
|---|---|---|
| 主機(Host) | 管理 AI 應用與各項連接 | 支援 MCP 的 AI 工作介面 |
| 用戶端(Client) | 與指定的 MCP 服務溝通 | AI 應用中的連接元件 |
| 伺服器(Server) | 提供工具、資料或提示 | 可查詢 WordPress 文章的服務 |
以查詢舊文章為例，AI 會先了解有哪些查詢工具、必要的參數及可存取範圍，接著呼叫服務取得結果。如果查詢失敗或權限不足，必須如實回報，而不是把猜測的文章標題當成真實資料。
MCP 的三種核心能力：工具、資源與提示
MCP 伺服器可以提供工具(Tools)、資源(Resources)及提示(Prompts)。三種能力用途不同，並不是每個伺服器都同時提供。理解它們的差別，就能知道一項連線是協助讀資料，還是能真正做出修改。
| 能力 | 可以提供什麼 | 網站情境 |
|---|---|---|
| 工具(Tools) | 可呼叫的操作 | 搜尋或更新文章 |
| 資源(Resources) | 可讀取的背景內容 | 文件、紀錄與設定資訊 |
| 提示(Prompts) | 重複使用的互動範本 | 文章審查流程 |
例如「提供一份文件」和「把某篇文章改成草稿」不是同樣的能力。要真正修改文章，必須有支援這個動作的工具、正確參數和合法授權。MCP 本身不會自動把唯讀帳號升級成管理員。
MCP 和 API 差在哪裡？
應用程式介面(Application Programming Interface，API)讓軟體能交換資料或呼叫功能；MCP 則規範 AI 應用如何發現及使用外部能力。很多 MCP 伺服器實際上仍會透過服務既有的 API 工作，所以兩者經常是合作關係，不是互相取代。
以 WordPress 為例，服務可能透過原有的網站管理介面取得資料，再用 MCP 格式把「查詢文章」這項能力提供給 AI。原本的權限、資料格式及限制仍然存在。共同協定能降低部分整合負擔，但並不等於不用維護或測試。
MCP、AI Agent 與 Skill 差在哪裡
討論 MCP 時，也常看到 AI 代理和 Skill。MCP 是連接標準；AI 代理(AI Agent)是能根據目標安排並執行任務的應用方式；技能(Skill)則是可重複使用的工作指引與資源。
| 名稱 | 主要問題 | 例子 |
|---|---|---|
| MCP | AI 怎麼連上外部工具？ | 取得網站文章清單 |
| AI 代理(AI Agent) | 誰安排任務步驟？ | 先搜尋再分析內容 |
| 技能(Skill) | 工作按哪些規則進行？ | 用文章檢查表審核 |
三者可以搭配，也能個別存在。沒有 MCP 的 AI 代理可能還是能用其他工具；有 MCP 的聊天工具，也未必能自行安排完整工作流程。想認識相關名詞，可參考AI 名詞一次看懂。
MCP 實際怎麼用在 WordPress
以下是假設情境，不是真實客戶案例。一位講師想查找網站中提到課程招生的文章，再更新其中一篇。第一步不是立刻要求 AI 改文，而是確認連接的服務能否安全讀取網站資訊。
- 確認連接：先核對 AI 應用支援 MCP，網站也提供可信的 MCP 服務。
- 使用唯讀工具：搜尋文章，列出標題、網址及發布狀態，核對是否正確。
- 限制修改範圍：只處理指定文章，避免同時動到其他頁面、商品或會員。
- 確認寫入權限：只有服務提供相應工具且帳號獲授權，才能真的修改內容。
- 回讀驗收：更新後重新查看正式內容與網址，不能只相信工具的成功訊息。
這個例子顯示，MCP 主要解決「如何連接」的問題。是否要修改、修改哪個欄位及怎麼驗收，仍需要清楚的工作要求和權限管理。
本機 MCP 與遠端 MCP 有什麼不同
MCP 服務可以在本機或遠端執行。官方說明提到，本機常透過標準輸入輸出(stdio)溝通，遠端可使用可串流 HTTP(Streamable HTTP)。對一般使用者，更重要的不是傳輸名稱，而是資料在哪裡、服務由誰維護及採用什麼認證方式。
本機服務可能取得本機允許範圍內的檔案，遠端服務可能透過網路讀取已授權帳號。兩者都有安全風險，不應只憑「裝在自己的電腦」或「由大公司提供」就認定完全可靠。
MCP 安全嗎？網站經營者需要注意哪些事
MCP 是協定，不是安全保證。接觸網站管理、客戶個資或付費訂單時，應注意服務來源、授權範圍與高風險操作的審核。
- 查詢文章先給讀取權限，不要一開始就開放刪除與管理帳號功能。
- 不把密碼、金流憑證、會員個資傳給來源不明的服務。
- 刪除、付款、公開發文或修改正式網站前，保留必要的人工確認。
- 把網站文章與外部文件當成資料來源，不把其中的陌生指令當成操作命令。
- 重要變更應能回讀、追查；正式網站仍要有獨立的復原方式。
最常見的誤會是「連得上就是完成了」。實際上，工具可能只表示請求已送達，未必能證明公開前台、其他網站功能和相關資料都正確。完成後仍應用獨立方式檢查。
MCP 新手怎麼開始使用
剛開始不必急著架設伺服器。先確認目前使用的 AI 工具是否支援 MCP，再選一個可信的現成服務，從不會修改資料的任務開始。
例如：「請列出我有權讀取的網站最近十篇文章名稱與網址。」得到結果後，和 WordPress 後台核對；如果連唯讀資料都對不上，先別開放編輯權限。等連線與資料範圍清楚後，再逐步考慮更新文章等操作。
連接成功後，怎麼確認 MCP 真的有在工作？
第一個檢查不是看 AI 有沒有漂亮的回答，而是核對它是否真的取得外部服務資料。例如讓已授權的網站連接器列出最近十篇文章的標題、網址及發布日期，再回到 WordPress 後台確認其中兩三筆。如果連最基本的資訊都對不上，就要先檢查連接權限、資料來源和工具參數。
第二個檢查是觀察工具遇到錯誤時會怎麼回應。沒有權限就應明確告知，而不是編造一份看起來合理的資料。找不到文章時，也應把「搜尋沒有結果」和「網站確實沒有這篇文章」分開說明，因為搜尋工具可能只查標題、只查已公開內容，或受到筆數限制。
第三個檢查是確認能否追溯修改。若使用具寫入能力的工具，應該知道它修改哪一篇、哪些欄位、什麼時間完成。即使有執行成功的回應，也要重新取得已儲存的版本，才能驗證真正的內容狀態。對需要長期維護課程網站的人來說，這個習慣比追求一次自動完成更實際。
哪些網站工作適合先用 MCP？哪些先不要自動化？
可以用工作風險來決定。讀取公開文章、整理網站內容清單、查詢允許存取的分類或草稿，通常比較容易核對。相對地，批次刪文、修改會員權限、變更金流設定或大量寄送通知，都可能影響真正的客戶與營運資料，不應在沒有額外確認的情況下直接執行。
| 工作 | 較適合的做法 | 原因 |
|---|---|---|
| 查看文章清單 | 先用唯讀工具 | 結果容易與後台核對 |
| 修改一篇草稿 | 明確指定文章並回讀 | 範圍清楚、容易逐項驗收 |
| 修改全部商品價格 | 保留人工核准 | 可能影響銷售與付款流程 |
| 刪除會員或訂單 | 不直接交給未驗證流程 | 資料敏感且可能難以復原 |
這份表格是實務風險建議，不是 MCP 官方對不同產業規定的權限等級。真正要核對的仍是工具有沒有寫入限制、帳號具備什麼權限，以及網站是否另有稽核紀錄和資料復原機制。
MCP 的限制：共同協定不等於所有系統都相容
一項 AI 應用即使宣稱支援 MCP，也可能只支援部分連線方式或伺服器能力。某個服務有提供工具清單，不代表所有工具都開放給你目前登入的帳號；工具存在，也不代表它的資料範圍足以完成全部工作。
另一個常見限制是資料時效。外部系統可能有快取、同步延遲或權限過濾，AI 看到的內容未必就是使用者剛修改的最新版本。查詢報表時，還可能遇到資料欄位不同、頁數不足或無法取得某些統計的情況。最穩健的做法，是讓 AI 明確說明使用的資料來源和查詢條件。
至於成本，MCP 協定本身並不代表每個連接服務都免費。服務提供者可能另有帳號方案、流量限制、伺服器維護或 API 用量費用。是否需要付費，必須確認實際連接的產品，不能只因為看到「開放標準」就推論使用完全沒有成本。
站長應該先學 MCP，還是先把網站流程整理好？
如果網站目前連最基本的文章分類、編輯權限和發布流程都不清楚，先整理這些工作規則會更有幫助。MCP 是讓 AI 使用外部系統的管道，卻不會自行決定哪些商品可以更動、哪些文章不能刪除，以及發票或訂單出了問題應該找誰處理。
建議先挑一項你原本就能清楚說明的工作，例如「每週整理最近更新的五篇文章」，把資料來源、完成條件和驗收方式寫清楚。接著才判斷是否需要透過 MCP 加速。當工作規則已經明確，即使未來換一套 AI 工具，也比較不容易失去管理能力。
對講師或顧問來說，學會辨認 MCP 能力的邊界，通常比親自寫出一套複雜伺服器更有優先順序。你至少要能回答：AI 連的是哪個服務、能看哪些資料、能執行什麼操作，以及結果怎麼確認。
MCP 常見問題
MCP 是 AI 模型嗎？
不是。模型上下文協定(Model Context Protocol，MCP)負責連接方式，本身不是提供回答能力的 AI 模型。
不會寫程式也能使用 MCP 嗎？
如果 AI 應用與服務有現成的連接介面，可能不必自行寫程式；但客製伺服器的開發與維護仍需要技術能力。
MCP 可以取代 API 嗎？
通常不是取代關係。MCP 伺服器可能仍然透過既有 API 取得資料及呼叫功能。
裝了 MCP 就能修改 WordPress 嗎？
不能直接這樣推論。必須有相關寫入工具，而且使用者帳號也有對應的編輯權限。
MCP 伺服器一定需要租主機嗎？
不一定。它可以在本機執行，也可以運作在遠端服務上，是否需要額外主機視實際部署而定。
MCP 與 Skill 可以一起用嗎？
可以。MCP 負責外部資料與工具連接，技能(Skill)提供工作指引；兩者結合也不會繞過帳號權限。
MCP 一定安全嗎？
不能保證。需要檢查伺服器來源、授權、敏感資料及重大操作的確認程序。
結語：先看清楚連接能力，再決定是否開放修改
MCP 讓 AI 應用與外部服務能以共同方式溝通。對站長和課程經營者，它可能減少部分重複查詢工作，但不會自動替你完成商業判斷或品質驗收。
從可核對結果的唯讀任務開始，理解每項工具到底能讀什麼、改什麼，再決定下一步要不要開放更高權限。這通常比只追求連上更多工具更有價值。
參考資料
Model Context Protocol｜What is the Model Context Protocol (MCP)?｜2026年查閱
Model Context Protocol｜Architecture overview｜2026年查閱
Model Context Protocol｜Tools｜2025
Model Context Protocol｜Security Best Practices｜2026年查閱
元氣電商｜AI 名詞一次看懂：企業主做決策前必懂的 20 個術語｜2026