MCP 伺服器不該把 API 一比一搬上去：意圖導向的工具設計怎麼做
很多團隊把現有 API 一鍵包成 MCP 就以為完工，這其實是最大的設計誤區。AI 代理不像工程師會處理分頁、關聯查詢，它需要意圖導向的工具。這篇談 1:1 包裝的三個代價、三原語對應法，以及零售品牌怎麼把資料層設計成 AI 用得順的樣子。
一個很常見的畫面是這樣：團隊拿現有的一份 API 文件，用工具一鍵生成對應的 MCP 包裝，覺得「AI 接口做好了」，就收工。幾週後 AI 代理上線，回應卻變慢、成本增加，答案也不穩定。問題不在 AI 不夠聰明，在於這份接口，是照著給工程師用的邏輯搬過去的，而 AI 代理的運作方式跟工程師完全不同。
把 API 一比一包成 MCP，是導入 AI 代理時最容易犯、也最傷的設計誤區。這篇想把「為什麼不該這樣做」與「該怎麼做」講清楚，對象是要決定資料怎麼對 AI 開放的品牌決策者，不需要你會寫程式。
把整個後台開給 AI，然後呢
我們看過一些品牌，出於「先接起來再說」的心態，把整個後台十幾張資料表原封不動開給 AI 代理，想像它會像一個超級工程師，自己搞懂訂單表怎麼關聯到會員表、庫存表怎麼分頁。
結果通常令人沮喪。AI 花大量算力在猜測資料結構、反覆嘗試錯誤的組合，一個「查這位客人適合推什麼」的簡單問題，繞了十幾步還答不準。它不是笨，是我們給它的工具，本來就是給另一種使用者用的。工程師有處理複雜分頁、多次關聯查詢的先驗知識，AI 代理不該被要求靠猜測補齊這些，它需要的是被設計過的、對得上業務意圖的工具。
一比一包裝，要付出的三種代價
把 API 原封不動搬成 MCP，代價分三個層次，愈往下愈貴。
- 準確度的代價。AI 代理面對一堆零碎的原始端點，得自己拼裝執行順序，很容易呼叫錯、漏掉步驟。不要讓它猜「先建用戶、再給權限、再發信」的順序，直接給它一個「建立客戶並完成通知」的完整動作。
- 成本的代價。大型語言模型讀資料是要花錢的。如果一個工具回傳五十個欄位的原始資料，模型其實只需要其中三個，多出來的不只浪費費用，還會塞爆模型的上下文，讓它的推理變差。業界把這種現象叫「上下文污染」，資訊太多太雜，模型反而抓不到重點。
- 資安的代價。把完整後台攤開給 AI，等於把每一張表、每一個能改資料的動作都暴露出去。開放的表面積愈大，誤動作與被攻擊的風險就愈高。這一層的完整討論，留到系列第三篇。
這三個代價，Gartner 點名的成本失控與風險控管不足，正是它預測四成 agentic AI 專案會被取消的兩大主因。若工具設計沒有先收斂，成本與風險通常會在上線後被放大。
意圖導向：把工具設計成 AI 聽得懂的動作
正確的做法，是圍繞「使用者意圖」來組工具，而不是照搬底層端點。這其實回到 Anthropic 當初提出 MCP 的用意：把整合的複雜度收斂在一處，讓 AI 拿到的是乾淨、好用的能力。差別可以用一個對照講清楚。
| 設計方式 | AI 收到的工具長相 |
|---|---|
| 一比一包裝 | 建立用戶、查詢權限、寫入紀錄、發送信件等一堆零碎端點 |
| 意圖導向 | 一個「建立客戶並完成開通」的完整動作，內部細節藏起來 |
意圖導向有三個要點：
- 把常見任務需要的多次呼叫，在伺服器端合併成單一動作，複雜的編排邏輯藏在裡面，不要丟給模型自己編。
- 用自然語言命名工具與參數，像「尋找產品」「總結這份文件」，因為底層是語言模型，它靠自然語言理解功能。
- 用嚴謹的結構描述框住每個工具的輸入與輸出，把模糊空間壓到最小，模型才不會亂填、不會幻覺。
MCP 伺服器該被當成替 AI 代理量身準備的專屬工具箱，把原本給人看的後台照相複製一份並不合用。認證、分頁、格式轉換這些髒活，在伺服器端處理掉，只把清楚、高階、對得上意圖的能力開放出來。
三原語對應法：既有 API 怎麼重構
如果要把現有系統整理成 MCP，官方定義的三種原語提供了一套乾淨的對應邏輯。
| 底層 API 性質 | 對應的 MCP 原語 |
|---|---|
| 唯讀查詢（GET） | Resources 資源，讓 AI 讀取上下文 |
| 會改變狀態的動作（POST、PUT、DELETE） | Tools 工具，讓 AI 執行具體操作 |
| 重複的多步驟任務 | Prompts 提示，把常見任務的指令與操作引導打包成可重用模板 |
這套對應的好處，是它強迫你在重構時先分清楚「哪些是讓 AI 讀的、哪些是讓 AI 做的、哪些是固定流程」。順帶要提的是，MCP 採用 JSON-RPC 2.0 作為訊息格式，並在協定層定義資源、工具與提示等互動方式，因此比單純開放零散 API 更適合被 AI 代理理解與選用。
還有一個常被忽略的原則：最小權限。MCP 不該把完整底層 API 全開，只開放 AI 完成特定任務所需的最小功能集。這件事同時省成本、降風險，是意圖導向設計的自然結果。
CDMP 本來就是一層意圖導向的資料
講到這裡，零售品牌的落點就清楚了。你手上真正該對 AI 開放的，不是十幾張原始資料表，而是被整理成業務意圖的資料層。
舉例來說，比起把會員表、訂單表、瀏覽紀錄表全部攤開讓 AI 自己算，一個更好的做法，是直接提供「找出七天內高回購意圖的會員」這種對得上業務問題的能力。這正是 CDMP 在做的事：它把跨通路資料歸戶成單一會員身份，算出購買機率訊號、貼上行為脈絡標籤，對外開放的是「高轉換名單」「高流失風險客群」這類意圖，而不是一堆需要 AI 現場拼裝的原始欄位。
這個思路，跟我們在破解 CDP 的 AI 神話裡談的一致：一鍵報表看起來很快，真正難的是把資料先整理到「拿出來就能用」。也呼應我們在從 CDP、CRM 到 AI Skill裡拆過的設計邏輯，好的資料能力是先定義問題、檢查品質、框好邊界，才輪到 AI 上場。品牌最後要投資的，是能把資料、執行與成效回收接起來的系統，而不是一個把後台照搬給 AI 的接口。
資料對 AI 開放前，先做這幾件設計功課
台灣品牌在規劃 AI 代理接口時，以下幾件事建議在動工前就想清楚，順序會直接影響成本與成效。
- 先盤點高頻業務問題，再設計工具。把「行銷、客服最常問 AI 的十個問題」列出來，照這些意圖設計對外能力，而不是照資料表結構（預期效果：AI 接上直接可用，少繞路；建議週期：兩週訪談內部單位收斂清單）。
- 一個工具只回必要欄位。明確定義每個工具該回什麼、不回什麼，把上下文污染與費用壓下來（預期效果：回應更快、成本更低、答案更準；建議週期：隨每個工具設計時就定好）。
- 把多步驟流程在後端合併。像「查會員近期訂單並建議下一步溝通」這種常見任務，包成單一動作（預期效果：減少 AI 呼叫錯誤與往返；建議週期：每季固化二到三個高頻流程）。
- 從最小權限開始開放。先開唯讀、低風險的資料，會改動資料的動作逐一評估再開（預期效果：降低誤動作與資安曝險；建議週期：與 IT、資安一起排優先序）。
這幾步的共同精神只有一句：把複雜留在你這邊，把簡單留給 AI。
結語
一鍵把 API 包成 MCP，技術上五分鐘就能做完，但那五分鐘省下的功，會在後面的帳單、錯誤率與資安風險上加倍還回來。真正決定 AI 代理好不好用的，是有沒有人先蹲下來，把資料與工具照著業務意圖重新設計一遍。工具替 AI 想好了，AI 才替你把事做好。
常見問題
Q1：為什麼不能直接把現有 API 包成 MCP 就好？ 因為 API 是給工程師與程式用的，端點零碎、需要先驗知識才能正確串接。AI 代理沒有這種知識，直接面對一堆原始端點會呼叫錯、拼裝慢、還把上下文塞爆。正確做法是圍繞業務意圖重新設計工具，把複雜編排藏在伺服器端。
Q2：什麼叫「意圖導向」的工具設計？ 就是照「使用者想完成什麼」來設計工具，而不是照底層資料表。例如提供一個「建立客戶並完成開通」的完整動作，或「找出高回購意圖會員」的能力，而不是讓 AI 自己把好幾個零碎端點按順序組起來。工具名稱與參數盡量用自然語言。
Q3：把資料開放給 AI，為什麼會影響成本？ 因為語言模型讀取資料要花費用（以 token 計）。若工具回傳五十個欄位但模型只需三個，多出來的既浪費錢，又會造成「上下文污染」，讓模型抓不到重點、推理變差。一個工具只回必要欄位，是省錢也是提升準確度的關鍵。
Q4：MCP 的三原語 Resources、Tools、Prompts 差在哪？ Resources 對應唯讀查詢，讓 AI 讀取上下文；Tools 對應會改變狀態的動作，讓 AI 執行操作；Prompts 把重複的多步驟流程打包成可重用模板。重構既有 API 時，可用這套邏輯先分清楚哪些給 AI 讀、哪些給 AI 做、哪些是固定流程。
Q5：零售品牌沒有工程團隊，這些設計做得起來嗎？ 重點不是自己寫程式，而是先想清楚「該對 AI 開放什麼意圖」。把高頻業務問題盤點出來、決定每個能力回什麼資料、從最小權限開始，這些是業務與資料策略的功課。實際串接可交給平台或技術夥伴，但意圖要由懂業務的人來定義。
Q6：意圖導向設計會不會讓系統變得不夠彈性？ 短期看似少了「什麼都能問」的自由，但換來的是更準、更省、更安全。AI 代理需要的是清楚的護欄，不是無邊界的存取。真正該保留彈性的是意圖清單本身，可以隨業務需求持續增修，而不是把整個後台永遠攤開。