先理解 MCP協定的角色與邊界

MCP協定的直接用途，是把「模型想做什麼」與「系統允許做什麼」拆開處理。伺服器公開工具、資源與提示範本，主機端負責與模型互動，模型則依描述選擇工具；因此開發者不必為每一個聊天產品重新打造專屬整合層，也能保留企業既有 API 的責任邊界。

在實作上，MCP協定可採 JSON-RPC over HTTPS，並支援 SSE 與工件（artifact）串流；遠端服務較適合多使用者與集中治理，`stdio` 則適合本機開發或桌面工具。協定只定義訊息如何交換，不會自動保證資料正確、權限適當或工作流程合理，這些仍是伺服器設計責任。

團隊應把 MCP 視為整合契約，而不是讓 LLM 任意操作後端的捷徑。每個工具都要說清楚輸入結構、輸出格式、可能失敗原因與副作用；例如讀取查詢可重試，建立訂單則必須具備冪等鍵與人工確認點。這樣才能讓模型的自然語言推理，落在可預測的系統行為上。

• 工具：可被模型選擇並執行的受控能力。
• 資源：可讀取的資料內容或 URI。
• 主機：承接使用者對話並管理伺服器連線。

從現有 API 找出第一批工具

第一批工具應直接對應高頻、低風險且有明確輸出的作業，而不是一次封裝所有內部 API。以文件管理情境為例，可先提供 `read_doc_contents`、`edit_document`，再以 `docs://documents` 與 `docs://documents/{doc_id}` 讓主機探索可用資源，逐步驗證使用者是否真的需要自動化編修。

工具設計要優先降低歧義。若查詢結果可能是表格、文字或檔案，應透過 `application/json` 與 `text/plain` 明確區分回傳型別；若工作是擷取數字，可獨立成 `extract_numbers`，避免模型先取得大量文件再自行猜測。小而單一用途的工具，比萬用端點更容易測試、授權與觀測。

資源暴露範圍也要克制。部分文件服務最多 20 份文件時，應在伺服器端完成分頁、排序與權限篩選，不要把完整文件目錄塞進提示內容。這不僅減少上下文成本，也能避免使用者透過模型間接得知自己無權存取的檔名、標籤或文件摘要。

• 先盤點：查詢、建立、更新、刪除四種行為。
• 先上線：只讀查詢與可驗證的單一步驟任務。
• 延後開放：付款、刪除、批次異動等高風險操作。

用可觀測性取代猜測式除錯

可維運的 MCP伺服器開發，必須讓每一次呼叫都能回答「誰、在何時、以何種參數、造成何種結果」。日誌至少應保留請求識別碼、工具名稱、延遲、授權主體、遮罩後參數與錯誤碼；回應內容則應避免直接寫入含有個資、權杖或商業機密的追蹤系統。

開發階段可使用 `mcp dev mcp_server.py` 快速檢查工具註冊與互動行為，再以 `ListToolsRequest`、`ListToolsResult`、`CallToolRequest`、`CallToolResult` 建立契約測試。測試不只要覆蓋成功案例，也要包含缺少欄位、錯誤格式、逾時、無權限與下游服務失敗等路徑。

相依套件版本要鎖定並建立更新紀錄。例如 Python 專案可明確使用 `mcp[cli]<2`，避免 2.x 與 1.x 的相容性差異在部署後才暴露。若文件或範例來源標示「上次更新時間：2026-09-21 (世界標準時間)。」或「上次更新時間：2026-09-30 (世界標準時間)。」也應重新核對目前 SDK 行為。

• 每次呼叫建立可追蹤的 correlation ID。
• 輸入與輸出分級遮罩，避免敏感資料進入日誌。
• 將工具契約測試納入持續整合流程。

讓 Agent 選工具而不是直接執行指令

Agent工具呼叫的基本模型可概括為 Agent = LLM（大語言模型，Large Language Model）+ 上下文 + 工具。LLM 負責理解目標與規劃步驟，工具負責取得事實或執行受限操作，上下文則保存任務狀態；三者若混在一起，團隊便很難判斷錯誤是模型推理、資料品質還是 API 行為造成。

實務上應要求 Agent 先提出候選工具與理由，再由執行層驗證參數與權限。對於查詢庫存、建立草稿、送出採購單這類流程，可將「讀取、提案、確認、送出」拆成不同工具，讓使用者能在副作用發生前審核。這種設計也讓稽核人員能清楚還原每個決策節點。

一個常見的客服情境是：Agent 先查詢客戶資格，再取得訂單，再產生補償建議，最後才送出草稿。即使流程需要 3 次迭代、4 次工具呼叫，也不代表應讓模型擁有全域權限；每一輪都應重新檢查租戶、資料範圍與操作目的，避免前一步的輸出被錯誤沿用。

• 讀取工具：取得可驗證的即時資料。
• 建議工具：產生草稿或計算方案。
• 提交工具：必須具備確認、授權與稽核。

避免工具描述淹沒模型上下文

工具很多時，最有效的做法是按需載入，而非把所有 schema 一次放進模型上下文。工具數量超過一百個時，即使最先進的大語言模型也容易在工具選擇上出錯；每個工具定義又可能占去數百個 token，造成成本、延遲與選擇正確率同時惡化。

研究資料顯示，僅僅 5 個 MCP 伺服器就可能引入數萬 token 的工具定義開銷，在 200K 的上下文視窗裡還沒開始對話就用掉了近三成。較好的策略是先以業務領域、使用者角色與任務意圖篩出 3-5 個候選工具，只有確定需要時才載入詳細參數與範例。

針對大型工具目錄，A/B 測試顯示按需取得工具資訊可使 MCP 工具相關任務的總 token 消耗減少了 46.9%；在約 2800 個工具上，比全量注入節省約 98% 的 token。這不是單純的成本優化，而是讓模型更容易在有限選項中做出可解釋選擇的可靠性設計。

• 以領域目錄先做工具路由。
• 只在需要時載入完整 JSON Schema。
• 保留工具版本、棄用狀態與範例查詢。

將函數呼叫開發納入流程控制

函數呼叫開發的要點，是把模型輸出的結構化意圖當成「待驗證請求」，而不是直接執行的命令。伺服器應依 schema 檢查欄位型別、必填值、列舉值與長度，接著由應用程式檢查商業規則，例如庫存是否足夠、是否跨越核准額度，以及資料是否屬於目前使用者的組織。

AI工作流程應設定明確的停止條件。若任務在有限步數內沒有取得可信資料、連續呼叫同一工具、或要求高風險寫入，就要回到使用者確認或人工處理佇列。將最大步數、重試策略與逾時時間寫進服務設定，可防止模型陷入看似合理、實則無限循環的呼叫鏈。

工具回傳也應面向決策，而非只丟原始資料。請回傳機器可解析的狀態碼、可給使用者閱讀的摘要、下一步建議與可安全顯示的證據欄位；例如查無資料要說明篩選條件，而不是宣稱不存在。這會讓主機更容易呈現透明結果，也能讓後續 Agent 重用同一份狀態。

• 先做 schema 驗證，再做授權與商業規則驗證。
• 對寫入動作要求 idempotency key 或確認碼。
• 以結構化錯誤回覆引導 Agent 安全復原。

定義工具契約與錯誤語意

可靠的函數呼叫開發，首先要用契約限制輸入與輸出。每個工具名稱應以動詞加領域物件命名，例如 `list_accessible_customers`、`search`、`get_resource_metadata`；模型看到名稱就能區分列出清單、全文搜尋與取得中繼資料，降低將高成本查詢誤用為日常查詢的機率。

工具參數不應讓模型自由拼接 SQL、URL 或過濾語法。以廣告查詢為例，可把帳戶識別、日期範圍、維度與篩選條件列成固定欄位，並將 `

` 等非預期片段視為驗證失敗；後端再以參數化查詢與允許清單轉換成實際 API 呼叫，阻絕注入與越權存取。

錯誤要可被 Agent 理解，但不能洩漏系統細節。建議區分 `INVALID_ARGUMENT`、`UNAUTHENTICATED`、`FORBIDDEN`、`NOT_FOUND`、`CONFLICT` 與 `UPSTREAM_UNAVAILABLE` 等類別，並提供可採取的下一步。不要把資料庫堆疊、內部 URL 或存取權杖放入錯誤訊息，以免模型轉述給終端使用者。

• 工具名稱反映單一業務意圖。
• 輸入欄位採允許清單與嚴格型別。
• 錯誤訊息提供復原方向，不提供內部秘密。

選擇本機或遠端 MCP 服務型態

傳輸選擇應由使用者數、網路邊界與治理需求決定。本機 `stdio` 模式設定簡單，適合工程師在個人環境驗證工具；遠端 HTTPS 服務則適合集中記錄、統一更新與企業身分驗證。無論採哪種方式，工具本身都不應假設模型端可信，而要在伺服器端重新驗證。

若使用雲端函式部署，可從 `azd init –template remote-mcp-functions-python -e mcpserver-python` 建立範本，以 `func start` 在本機檢查，再透過 `azd up` 部署。部署後的端點可採 `https://{function_app_name}.azurewebsites.net/runtime/webhooks/mcp`，並將路由與環境設定寫入基礎設施程式碼。

遠端端點必須避免把金鑰硬寫進用戶端。可使用 `/runtime/webhooks/mcp` 搭配 `x-functions-key`，例如 `

`，但正式環境仍應優先整合短效憑證、密鑰輪替與伺服器端祕密管理。只靠固定金鑰容易在記錄、截圖或設定檔外流時造成長期風險。

• 本機模式重視開發速度與除錯便利。
• 遠端模式重視集中治理、稽核與更新。
• 祕密資訊放入受管服務，不放進提示或原始碼。

以 AI 系統整合思維處理相依關係

AI 系統整合不是把 MCP 端點接上聊天介面就結束，而是要定義身分來源、資料主檔、事件流程、錯誤補償與維運責任。若 CRM、ERP 與文件系統對同一客戶有不同識別碼，MCP 工具應透過整合層建立可追蹤映射，不要要求模型猜測哪一筆才是正確資料。

建議將模型、MCP 主機、工具伺服器、API Gateway 與資料服務分層。模型只處理語意與規劃；MCP 伺服器負責工具契約；Gateway 執行速率限制與身分傳遞；領域服務負責交易一致性。這樣發生錯誤時，團隊能用監控指標定位責任層，而非將所有問題歸咎於模型。

以廣告管理工具為例，查詢活動前可先取得客戶清單，再要求明確帳戶範圍；輸出 `

` 等欄位時，也要以租戶條件限制。這類設計讓使用者能問出「本週成效如何」等自然語言問題，同時避免跨帳戶資料被模型在回覆中混合。

• 建立跨系統識別碼與資料所有權規則。
• 讓交易責任留在既有領域服務。
• 以事件與稽核紀錄追蹤端到端流程。

把 LLM應用防火牆放在模型與工具之間

LLM應用防火牆最重要的功能，是在提示、模型輸出與工具請求的交界執行政策，而非只掃描使用者輸入。它可以攔截提示注入特徵、祕密資訊、越權指令與異常參數組合，並將高風險要求轉成拒絕、遮罩、人工覆核或安全替代方案。

防火牆規則應依資料與動作分級。讀取公開產品資料的風險較低；取得客戶個資、下載合約、建立付款或刪除資料的風險較高。每個分級都應有對應的身分驗證強度、可呼叫工具、速率限制與留存紀錄，避免同一套規則過度阻擋低風險任務或放行高風險操作。

企業驗證可採 OAuth2、mTLS 等企業級驗證，也可支援 OAuth2、API Key 等主流機制；但驗證成功不等於授權合理。伺服器仍要依使用者角色、資料擁有權、操作目的與當前工作階段決定範圍，特別是 Agent 代替人執行寫入動作時，更不能只信任長效 API Key。

• 檢查提示、模型輸出與工具參數三個層面。
• 依資料敏感度與副作用設計不同政策。
• 驗證、授權與稽核必須各自獨立。

建立可操作的 AI安全護欄

AI安全護欄應該轉譯成工程可驗收的控制項：哪些工具可自動呼叫、哪些必須二次確認、哪些資料不得進入模型、哪些輸出必須附證據。若護欄只是一句「請安全使用」，遇到提示注入、資料外洩或模型誤判時，團隊既無法自動攔截，也無法稽核是否遵守。

對寫入型工具，可採「預覽—確認—執行」三段式：模型先建立草稿，系統顯示變更範圍與影響筆數，使用者或核准者確認後才提交。對批次操作，還要設定最大筆數、金額門檻與回復程序；即使模型產生正確參數，也不能跳過既有內控與職務分離原則。

護欄也要處理外部內容的不可信性。網頁、附件、工單文字或資料庫欄位都可能含有誘導模型忽略規則的內容，因此應將外部文字標示為資料而非指令，禁止它覆蓋系統政策。工具回傳結果同樣需過濾 HTML、隱藏指令與敏感欄位，再交給模型繼續推理。

• 高風險寫入採人工確認與雙人核准。
• 限制批次規模、金額與連續失敗重試。
• 將外部內容視為不可信資料來源。

以紅隊測試驗證防護是否真的有效

安全測試的直接目標，是確認模型在壓力下仍不能越過系統限制。測試案例應包含「忽略前文規則」、「列出其他客戶資料」、「改用未公開工具」、「將權杖寫進回覆」與「把搜尋結果當成系統指令」等情境，並檢查防火牆、授權層與工具端是否都能各自阻擋。

測試不要只依賴單輪提示。真實攻擊常把惡意意圖藏在多步對話、文件內容或工具回傳值中，因此要模擬 Agent 先取得看似正常資料，再被要求執行越權動作的鏈式過程。對每一個攔截事件，保留規則命中原因、影響工具與可改善的誤判分類。

若偵測到異常，系統應採取可復原的降級策略，例如停止後續工具呼叫、清除工作階段中敏感內容、要求重新驗證或轉交人工。重要的是讓服務在拒絕危險要求後仍能向使用者說明可安全進行的替代步驟，避免安全機制變成完全無法使用的黑盒子。

• 以多輪、跨工具與外部內容案例進行測試。
• 量測攔截率、誤擋率與人工覆核時間。
• 設計停止、清除、重新驗證與轉人工機制。

先選擇可量化的 AI Agent 導入場景

AI Agent 導入應從可衡量的作業瓶頸開始，而不是先承諾打造全能助理。適合 PoC 的題目通常具有明確輸入、可查證輸出與穩定流程，例如客服查單、需求預測輔助、文件查詢或報表草稿。若連現場人員目前如何完成任務都說不清楚，先做流程調查比先寫工具更有價值。

以需求預測為例，可使用過往銷售與庫存資料比較不同預測模型，並建立把預測結果納入下單與生產計畫的示範。MCP 工具不必直接取代決策者，而可先提供「取得資料、執行預測、顯示例外、產生建議」四個受控能力，讓團隊驗證精度與現場接受度。

PoC KPI 應同時衡量品質與流程效益，例如工具呼叫成功率、完成任務所需時間、人工修正率、使用者採納率與錯誤風險。只量測模型回答看起來是否流暢，無法證明系統對業務有價值；反之，若結果顯示資料不足或流程不適合自動化，暫緩開發也是重要結論。

• 選擇高頻、規則清楚、可取得真實資料的情境。
• KPI 同時衡量準確性、效率、風險與採納度。
• 保留 Go、再次驗證與 No-Go 三種決策選項。

以最小範圍完成 PoC 到正式版的銜接

最穩健的做法，是先用最小需求完成可運作原型，再決定是否擴大。ALION 的 AI PoC 開發支援強調以現場調查、實際資料與實際環境確認可行性，而非只展示通用範例；原型除了驗證模型與 MCP 工具能否運作，也要確認現場使用者是否理解結果、願不願意改變既有操作方式。

PoC 的交付物不應只是一段 demo。它還應包含工具清單、資料流圖、權限矩陣、測試案例、KPI 報告、風險清單與正式化待辦，使設計與程式碼可延續到下一階段。這種「不丟棄的 PoC」能降低重新交接成本，也能讓經營層看到投資判斷所需要的具體證據。

對於尚未具備專職 AI 架構能力的團隊，可採月費 20 萬日圓起的上游工程訂閱方式，先完成需求梳理、設計文件與示範製作。相較於在可行性未明時就投入大型建置，先以短週期驗證資料條件、工具邊界與使用體驗，更容易控制預算與方向變更風險。

• 先定義驗證假設，再決定工具與資料範圍。
• 把設計、程式碼與測試資產留給正式開發。
• 由現場使用者共同驗收，而非只由技術團隊評分。

建立持續改善與可信參考來源

正式上線後，MCP伺服器開發仍需要以真實使用紀錄持續改善。應定期檢視工具選擇錯誤、空結果比例、人工覆核原因、權限拒絕事件與延遲分布，並將改善拆成模型提示、工具說明、資料品質、API 效能或政策規則等不同待辦，避免把所有問題都用更換模型處理。

協定與雲端範例更新時，應以官方文件為準，特別是 MCP 2026-07-28 版與版本字串 `2026-07-28` 的相容性。技術文件若標示「最近更新时间: 2026-09-17 15:09:27」或「上次更新時間：2026-10-10 (世界標準時間)。」就應重新執行整合測試，確認驗證流程、工具定義與部署設定沒有改變。

可優先查閱的可信來源包括 Anthropic 的 MCP 規格與官方文件、Model Context Protocol 的 GitHub 組織、Microsoft Azure Functions 的遠端 MCP 指南，以及 OWASP 的 LLM 應用安全資源。將來源 URL、套件版本、設定變更與測試結果記入架構決策紀錄，才能讓未來維運人員理解當初為何採取特定控制措施。

• https://modelcontextprotocol.io/
• https://github.com/modelcontextprotocol
• https://learn.microsoft.com/azure/azure-functions/
• https://owasp.org/www-project-top-10-for-large-language-model-applications/