你如果有嘗試過, 把整包 API 原封不動轉成 MCP 使用，你應該能體會我接下來要講的事情…

我其實是個記憶力很差的人 XD, 因此我很習慣把事情簡化或理解後才放到腦袋裡處理後續步驟, 間接的讓我不斷有訓練抽象化的機會 (因為不先抽象化思考, 整件事我腦袋根本裝不下)。因此我對於資訊不對等的現象很敏感, 只要有這種不好的設計我都能用反射動作就抓出問題來。

什麼叫做 “資訊不對等” ? 簡單的說，當我的意圖明明很簡單 ( ex: 我只要把兩罐可樂 這商品放進購物車 )，設計不當的 API 卻會要求溝通一大堆資訊 ( ex: 加入購物車的 API / Payload 需要帶上 100k json payload, 或是上百個參數之類的介面設計 )，這就是資訊不對等 ( “實際需要傳輸” 的資訊量 遠大於 “我想做這件事的意圖” 本身的資訊量 )

直接把現成的 API 當作 MCP, 很容易就會碰到這種問題。API 設計的目標應該是系統整合，本來就必須交代非常多系統層級的細節；但是 MCP 是跟 AI (另一種 “人”) 溝通的介面，理論上跟人或是 AI 溝通，不需要知道那麼多 context 以外的系統資訊…，當這種狀況發生時，AI 無法精確的生成這些額外的資訊時 (尤其是這些額外的資訊，通常都需要非常精準，例如要提供某個已存在的 ID，或是授權的 TOKEN)，所以 AI 的幻覺會被放大，最終的結果就是:

“這個 MCP 好難用，寫得好爛…”

我這次在整合 TestKit, 就踩過這個地雷… 我實驗用的 “安德魯小舖” API，算是設計的很漂亮的結構，沒有資訊不對等的現象，但是我在內部實際驗證的 API 就沒那麼幸運了，不論 API Spec 寫的再仔細，範例給的再完整，終究還是會碰到 AI 產錯參數的現象…

即使解決了，每次呼叫的 request / response 體積過大，沒呼叫幾次就把 context window 塞爆了, 迫使 AI 壓縮前面的內容，結果又變成忘了前面做了啥，後面的程序又掛掉…

最後我的解決方式是: 設計一個 MCP (就是我文內提到的 Text2Call), 讓 MCP 跟 Agent 溝通的訊息維持在 “抽象” 層級的資訊就好, 保持 “資訊對等” 的狀態。

而 MCP 內部，我另外用 LLM 做一次性的翻譯，就算資訊爆炸，也控制在一次往返的範圍內，同時我也把一些 NFR ( Non Function Requirement ), 例如文章內提到的 OAuth2 這類的機制，以及 Session Management, Session Logging 等需求, 直接寫程式處理掉，不要依賴 LLM 來做

最後結果就是，MCP 只需要暴露這幾個 Tools:

• QuickStart
• ListOperations
• CreateSession
• RunStep

而最關鍵的 RunStep, 只收兩個字串: action / context, 只回應 result 字串, 其餘都在 MCP 內部靠我寫好的 prompt 跟 LLM 來翻譯, 跟處理其他機械化的任務

經過這些處理，整個 TestKit 才真正變的可行, 也才有我文章寫的這些效果能真正發揮出來。

這些技巧，其實就是 Context Management 的核心，也是我常說你必須要理解你任務處理的流程，按照這些流程 ( workflow ) 才能設計出對的 Tools ，在這過程中來處理進出 Context Windows 的各種資訊

這只是 MCP 設計的重要觀念跟技巧之一，有興趣的人可以先想通這些問題，再去看一次我的文章，我相信你會恍然大悟我為何要這樣安排整套系統機制。

另外，如果你對這些 MCP 的設計技巧有興趣，我在今年的 .NET Conf 有一場演講, 講題是:

Designing for Agents: MCP-First Design Concepts

聊的就是這些技巧。有興趣的請記得報名~ 文章連結，跟活動官網 & 報名連結，我放在留言~

#NETConf2025 #MCP