內部 MCP Server — 讓 AI 直接、安全地操作我們的 API

我把 Sales 每次幫客戶建置表單時重複的手工流程,變成一個 AI 能直接呼叫的工具層——而且它會隨著 API 成長自己長大,不需要我每次回去手動維護。

這不是一個「我學會了 MCP」的玩具專案。它是我在團隊裡發現一個重複性痛點後,自己提出、設計、落地的內部工具,最後縮短了 Sales 幫客戶建置表單的時間。

我看到的問題

我們的產品讓客戶把紙本／Word／Excel 的表單,轉成線上可填寫的流程。每接一個客戶,Sales 都要依照客戶需求,把表單的欄位、結構、選項一個一個建起來。

麻煩在於:它既重複、又不夠重複到可以寫死。每個客戶的表單都不一樣,不能做固定範本一鍵套用;但「把一份規格轉成系統裡的表單設定」這個動作本身,每次都長得很像。真正被浪費的不是「思考」,而是「把已經想清楚的東西手工輸入進系統」這段。

後端 API 其實已經能做這些操作,只是散落在一堆 endpoint 裡,要人去讀 Swagger、組對的 payload、按對的順序呼叫。對 Sales 門檻太高;對工程師又太瑣碎。我判斷這是一個系統性的缺口,值得做成工具,而不是每次手動處理。

為什麼選擇做成 MCP Server

我大可以寫個內部小腳本或表單產生器。但我選擇做成 MCP Server:我們團隊已經在用 AI 工具輔助開發,如果把 API 包成 MCP tools,AI 就能直接、結構化地操作這些 API——Sales 只要用自然語言描述客戶要什麼樣的表單,AI 就能呼叫對的工具、帶對的參數把它建出來。我要解決的不只是「省下手工輸入」,而是「讓不會讀 API 的人,也能安全地驅動 API」。

這背後是一個取捨:MCP 當時還很新,參考資料少,踩坑成本高。但我評估它正好對上我們「AI-augmented 開發」的方向,而且一旦建起來,價值會比一個一次性腳本長很多。

三個關鍵設計決策

這一節是這個專案真正的重點。每個決策我都列出「問題／取捨／我的選擇」——因為對我來說,作品的價值不在「我用了什麼技術」,而在「我為什麼這樣選」。

1. 從 stdio 改成 SSE 傳輸

問題 最早的版本用 stdio,Server 必須跑在使用者本機、跟 client 綁在同一個 process。這代表每個要用的人都得在自己電腦上把環境裝起來——這對非工程的 Sales 不可行。

取捨 stdio 設定簡單、適合本機開發;SSE 要多處理連線與部署,但能讓 Server 獨立部署成服務,多個 client 透過網路連進來。

我的選擇 改成 SSE。目標使用者不是工程師,而是 Sales——如果只能在本機跑,它就永遠只是我自己的玩具。傳輸層的選擇不是技術偏好,而是直接決定了「這個工具到底有沒有人能用」。

2. 用 agent 把 Swagger 自動轉成 tools,而不是手寫

問題 API 不少 endpoint,而且持續增加。手寫每個 tool 定義,不只一開始累,更糟的是每次後端改了 API 我就得回來手動同步,工具很快會跟現實脫節、變成負債。

取捨 手寫 tools 一開始最直接、最可控;用 agent 從 Swagger 自動生成則前期要花力氣建 pipeline,但之後幾乎零維護。

我的選擇 建一個 agent pipeline 讀 Swagger spec、自動生成對應 tool 定義。API 一旦更新,工具層可以跟著重新生成,而不是靠我記得去改。這是我最在意的一個決定——它把「一次性成果」變成「會自己跟上的系統」,也是這個工具沒有在我做完之後就腐爛掉的原因。

3. 用 Zod 做輸入驗證

問題 AI 生成的工具呼叫不保證永遠正確——可能少帶欄位、型別錯誤、把參數組壞。壞掉的 payload 直接打到 API,輕則難 debug,重則建出錯誤的表單資料。

取捨 不驗證、直接信任 AI 的輸出最省事;加一層驗證要多寫 schema,但能在「打到 API 之前」就把錯誤擋下。

我的選擇 在每個 tool 的邊界用 Zod 定義 schema 驗證,讓 AI 的輸出在進入系統前一定先通過型別與結構檢查——錯誤被即時擋下並給出明確訊息,而不是變成難追的線上問題。對一個要交給非工程同事使用的工具,可靠性比功能多寡更重要:它必須讓人敢用、且錯了也安全。

成果

• 縮短了 Sales 幫客戶建置表單的時間——原本需要人工讀 API、逐欄建置,變成用自然語言描述、由 AI 驅動工具完成。
• 工具層會自己跟上 API——從 Swagger 自動生成,後端更新後不需要我手動維護一堆 tool 定義。
• 降低了錯誤成本——Zod 驗證讓壞掉的呼叫在邊界就被擋下,而不是流進系統。

技術:MCP(stdio → SSE)、Swagger / OpenAPI、Zod、TypeScript、AI agent pipeline

這個專案對我的意義:它同時證明了三件我希望別人記住的事——我會主動發現系統性痛點、我會做技術決策上的取捨、我能把 AI 整合進真實的商業流程而不只是寫 prompt。