架構會議進行到下午三點，白板上已有三支 Agent。

• Incident Agent
• Release Risk Agent
• Change Review Agent

三個團隊都提出同一個需求：查 Deployment History。

平台工程師很快畫出一個 MCP Server，統一接到 Deployment API。以後 Agent 不必各自處理登入、權限、Audit Log 與 API 格式；第四個 Agent 若有相同需求，也能直接接上。

工程師把 Tool 叫作 get_deployment_history。

輸入是 service、時間範圍與 environment；輸出則是版本、部署時間與結果。架構圖一下乾淨很多。

第一個接入的是 Incident Agent。

SRE 問它：「payment-service 昨晚十一點開始大量 Timeout，最近有沒有相關變更？」

Tool 找到四筆部署。Agent 回答：異常前半小時，payment-service 本身沒有部署。

這個答案正確，但 SRE 沒有採用。

真正出問題的是上游 auth-gateway：它在二十分鐘前剛換了版本。

SRE 要的不是某個服務的部署紀錄，而是故障前後有哪些變更可能相關。這件事需要服務關係、異常開始時間與可疑範圍；單純多一個 Deployment History Tool 還不夠。

同一份資料，三個人各自要拿來做不同的事

幾天後，Release Risk Agent 也接進來。

它不是要找最近的部署，而是要判斷下一版 Firmware Service 的部署風險：過去有沒有相似的版本變更、設定與依賴關係，最後造成失敗？

Change Review Agent 又不同。它關心的是某個 Change Window 裡，是否有其他團隊同時修改相依服務，可能造成衝突。

三個團隊都說自己要 Deployment History；但各自的下一步不同。

資料來源相同，並不代表工作相同。

平台若只看到 API 重複，就會把 Tool 持續做大：加 Dependency、版本、相似度、自訂欄位與各種 Filter。最後它幾乎什麼都查得到，但每個 Agent 還是得在自己的 Prompt 或 Workflow 裡決定「這次到底怎麼查才算對」。

底層整合少了一份，工作判斷仍然有三份。

MCP 解決的是接法，不是工作定義

這不表示 MCP 沒有價值。

登入、權限、Audit、Rate Limit、API Client 都應該共用。這些是基礎設施；每個 Agent 各自重做一次，只會增加維護與風險。

但一支 Tool 被標準化後，還有另一個問題：它的輸入和輸出，是否已經代表一份共同的工作？

例如 Incident 團隊說的「近期變更」，可能是故障前一小時、連同上游兩層服務的部署；Change Review 團隊說的同一個詞，可能是變更窗口內尚未完成的項目。

欄位名稱相同，意思卻不同。

此時，最合理的共用單位只是 Deployment Connector。它負責安全、可追溯地拿到資料。各團隊的查詢規則與判斷邏輯，仍留在各自的工作流程裡。

先讓第二個使用者跑一次

平台團隊後來新增一個很小的檢查：有人提議把某段邏輯抽成 Shared Tool 時，不再只確認是不是查同一個 API，而是拿第二個使用者的真實案例一起跑。

只看四件事：

• 兩邊的輸入是否真的是同一件事。
• 輸出是否用來推動同一類下一步。
• 同一筆資料的解讀是否一致。
• 查不到資料時，兩邊的意思是否相同。

Incident 團隊後來整理出 find_changes_related_to_incident。它輸入的是服務情境與事故時間，輸出是候選變更、關聯理由與證據。

Release Risk Agent 不適合用它；Problem Management Workflow 卻適合。兩邊都要根據事故時間與服務關係，找出值得往下查的 Change；連「找不到相關變更」的解讀也一致。

這一層才成為共用能力。

下一次架構 Review，圖上仍然有 MCP Server，接的 API 也更多了。只是上面的 Tool 少了很多。

三個 Agent 確實都會查 Deployment 資料；只是後來才確認，他們並沒有在做同一份工作。