CrewForm 讓 Agent 直接變 MCP 工具

說真的，這功能很實用。CrewForm 讓已發布的 agent 直接變成 MCP 工具。Claude Desktop 和 Cursor 都能直接呼叫。只要一份設定檔，不用再自己包一層 API。

這件事的重點，不是多了一個按鈕。重點是，agent 還是照原本的模型、system prompt、知識庫和工具跑。MCP 只是把它包成外部 app 能叫的 tool。講白了，就是把內部 agent 變成可插拔元件。

對開發者來說，這很省事。你不用為每個 agent 寫一套 wrapper。你只要發布，然後把設定貼進 client。這種做法很對味，因為 AI 編排最煩的，常常不是模型本身，是那些接線工作。

CrewForm 到底改了什麼

CrewForm 原本就支援 MCP client。也就是說，它自己的 agents 可以去呼叫外部工具。像是 GitHub、Brave Search、Postgres 這些都能接。這次更新則是反過來，讓 CrewForm 也能當 MCP server。

這個方向很關鍵。以前是 agent 去找工具。現在是外部 client 直接把 agent 當工具叫。兩邊都通了之後，整個系統就比較像一個通用編排層，而不是單一產品功能。

技術上，這次實作很小。作者提到核心檔案是 mcpServer.ts，大約 300 行。它掛在 POST /mcp。而且和 A2A、AG-UI 這些 protocol handler 放在同一個服務裡。這種設計很務實，沒有再拆一個獨立服務出來。

• Protocol 用 JSON-RPC 2.0 over HTTP
• 工具發現靠 tools/list
• 工具執行靠 tools/call
• Transport 用 streamable HTTP
• 發布開關是 is_mcp_published

我覺得這裡最聰明的地方，是沒有自創格式。它老老實實走 MCP 現有方法。這樣相容性高，client 端也比較不會卡住。

Agent 怎麼變成 Tool

當 MCP client 發出 tools/list，CrewForm 會去 workspace 裡找已發布的 agents。每個 agent 都會變成一個 tool entry。裡面有名稱、簡短描述，還有 input schema。這個 schema 很單純，只吃一個 message 欄位。

名稱正規化也很重要。MCP tool 名稱要小寫、只能用英數和底線，長度不能超過 64 字元。像 Blog Content Writer v2 會變成 blog_content_writer_v2。這看起來只是格式整理，但實務上很有用。因為 client 自動探索工具時，不會被奇怪命名搞死。

當 client 呼叫 tools/call，CrewForm 會找到對應 agent，建立 task record，然後交給既有的 runner 執行。也就是說，UI 用的執行路徑，和 MCP 用的是同一條。

這點很值得講。MCP 呼叫不是單純轉 prompt。agent 還是帶著自己的 model、system prompt、工具權限和知識庫跑。這代表你不是把能力縮水後再外包出去，而是把完整 agent 暴露成一個標準化入口。

• 每個已發布 agent 對應一個 MCP tool
• 任務會寫進 tasks 資料表
• 執行來源標記為 mcp
• 輪詢 timeout 是 120,000 ms
• 完成後回 JSON-RPC response

這對團隊很友善。像 code reviewer、研究助理、內容生成器，都能保留自己的規則。外部 client 看到的只是工具清單。背後怎麼做，交給 agent 自己。

驗證、傳輸，還有 HTTP 為什麼合理

驗證部分，CrewForm 沿用既有 API key 系統。MCP client 送 Bearer token，後端去資料庫找加密後的 key，然後對應到 workspace。只有那個 workspace 裡已發布的 agents 會被曝光。

這個邊界很實際。不是一把 key 開全部。它只開你有權限的 workspace。對多團隊共用平台的人來說，這種分層很重要，因為沒人想把內部 agent 全部攤平給外部 client 看。

“The Protocol is not the product.” — Anthropic

傳輸層的選擇也很務實。MCP 支援 stdio、SSE、streamable HTTP。CrewForm 選 HTTP，原因很簡單。它原本的 runner 就是 HTTP 架構，而且這種方式比較好放在 proxy、load balancer 和 CDN 後面。

這也符合現在 client 的走向。Claude Desktop 和 Cursor 都支援 HTTP 型 MCP 流程。使用者不用自己架 local bridge，也不用維持一個長跑 socket process。這對落地很重要，因為部署越簡單，團隊越願意試。

講白了，HTTP 很無聊，但很穩。它容易除錯，也容易接現有基礎設施。對企業內部系統來說，這通常比「很酷的傳輸方式」更有價值。

使用體驗才是成敗關鍵

後端改動雖然小，但產品體驗才是重點。CrewForm 在 agent 詳細頁加了 MCP Publish 切換。打開後，agent 就會出現在工具清單裡。關掉後，就消失。

他們也在 Settings > MCP Servers 加了一個產生 API key 的按鈕。Key 前綴是 cf_mcp_，只顯示一次，讓你複製到 client 設定檔。這種設計很懂痛點，因為最煩的往往不是核心功能，而是那 10% 的設定細節。

更方便的是，它還會幫你產生 MCP config snippet。你不用自己手寫 JSON。這件事看似小，卻很影響採用率。很多工具死在設定文件，不是死在功能本身。

• 每個 agent 都能單獨發布
• Key 可一鍵產生
• Client 設定可自動產生
• 支援 claude_desktop_config.json
• 啟用後要重啟 MCP client

對開發者來說，這就是 demo 跟真實工具的差別。五分鐘能接起來，大家才會想玩。要是卡半天，最後就只會躺在 GitHub 上吃灰。

文章裡舉的例子也很直白。你可以做一個 Code Reviewer agent，用 GPT-4o、一個 code-quality prompt，外加 GitHub 工具。發布之後，Claude 就能直接把 review 任務丟給它。

跟其他 agent 整合方式比起來

現在能暴露 agent 的方式很多。大致上有兩種。第一種是自訂 API wrapper。第二種是 app-specific plugin。前者彈性高，但你要自己維護 schema 和 endpoint。後者接起來快，但可攜性差。

CrewForm 這次走 MCP，剛好卡在中間。它用的是大家都能理解的標準。這不會讓 agent 變神，但會少掉很多 glue code。對團隊來說，少寫一堆接口黏土，通常就是好事。

如果直接比，差異很清楚。下面這幾種做法，各有代價。你會發現，MCP 的價值不在炫技，而在標準化。

• 自訂 REST wrapper：每個 agent 都要自己包一次
• App-specific plugin：接單一產品很快，但搬不走
• CrewForm MCP publish：一份 agent 定義，多個 client 可用
• 直接 prompt forwarding：最省事，但會丟掉 agent runtime

這次更新還透露出一個方向。CrewForm 現在同時扮演 MCP client、MCP server、A2A 協調者、AG-UI 前端串流端。這代表同一套 runtime 可以往不同方向輸出。

如果你在做內部 AI 基礎設施，這種架構很香。今天先讓 agent 去呼叫別人，明天再讓別人呼叫它，後天再讓 agent 跟 agent 對話。你不用重寫核心邏輯。

這背後的產業脈絡

MCP 會紅，不是沒原因。它解決的是一個老問題：AI app 怎麼用一致方式找工具、叫工具、回傳結果。對開發者來說，標準一出來，整個整合成本就會掉很多。

這也解釋了為什麼 Claude Desktop、Cursor 這類產品很快跟上。它們不是只想做聊天介面，而是想變成工作流入口。當工具呼叫變標準化，client 端就能把外部能力接進來，像 IDE、知識庫、內部服務都能串。

從平台角度看，CrewForm 這次不是只加一個功能。它是在說，agent 不是只能在自己的 UI 裡跑。它可以被別的 app 叫，也可以去叫別的工具。這種雙向能力，對企業內部整合很重要。

如果你關心這個領域，接下來要看的是權限和觀測。當一家公司開始發布十幾個 agent 時，誰能叫、誰不能叫、叫了什麼、輸入了什麼，都會變成管理問題。這些東西比 demo 更無聊，但更重要。

下一步該看什麼

我覺得最值得注意的，不是 toggle，也不是 config snippet。是這種模式讓 agent 平台可以用同一個 runtime，對外變成工具，對內維持原本能力。這會讓很多內部系統少掉重工。

如果 CrewForm 接下來把權限控管、audit log、使用統計做完整，這套玩法就會更像正式基礎設施，而不是單次整合。對台灣團隊來說，這很值得試。尤其是已經有內部 agent 的公司。

我的建議很直接。先挑一個 agent，先發布一次，先接到 Claude Desktop 或 Cursor。你會很快知道，哪些步驟是必要的，哪些只是多餘的包裝。這種實測，比看規格書有用多了。

接下來真正的問題不是「能不能接」。而是「哪個 agent 值得公開」，還有「你要怎麼管它」。這才是 MCP 進到實戰後，大家一定會碰到的題目。