MCP 不只是一組工具：用 mcp-use 把 Server、React View 與 Inspector 串成可執行的 AI 應用

我觀察到，Model Context Protocol（MCP）最容易被低估的地方，是大家常把它理解成「讓模型多幾個函式可以呼叫」。這個理解沒有錯，但只說到協定的入口，還沒有碰到真正的產品問題：工具被呼叫之後，結果要怎麼呈現？輸入輸出如何維持一致？開發者怎麼測試與除錯？如果最後要交付給使用者的不是一段 JSON，而是一個能互動的 AI 應用，單靠幾個散落的 server function 很快就會失去秩序。

這也是我認為 mcp-use 值得關注的原因。它不是單純的 MCP client 或 server 範例，而是以 TypeScript 為核心，嘗試把 MCP Server、型別驗證、React Views、瀏覽器 Inspector 與代理導向的開發流程放在同一個框架裡。換句話說，它處理的不是「能不能呼叫工具」這一題，而是「如何把 MCP 工具做成可以開發、測試、觀察與交付的應用」。

先講結論：它解的是 MCP 應用的整合成本

mcp-use 的官方 README 將定位放在 TypeScript MCP framework，並同時強調 MCP servers、ChatGPT plugins、Claude connectors、MCP Apps 與 Native Views。從這個定位可以看出，它瞄準的是應用層，而不是重新發明 MCP 協定本身。

我認為它的價值可以拆成四層：

Server 層：用 MCPServer 宣告服務名稱、版本與工具。
Schema 層：以 Zod 描述輸入與結構化輸出，讓工具契約靠近程式碼。
View 層：讓工具可以綁定 React View，把結果變成可互動的介面。
檢查與交付層：透過 Inspector、CLI 與開發伺服器觀察工具，降低整合時的黑盒感。

這四層不代表所有專案都必須一次用完。反而應該把它看成一條由小到大的導入路徑：先建立一個可呼叫的工具，再補上結構化資料與 View，最後才處理部署、權限、觀測性與模型端整合。

為什麼「型別」在 MCP 應用中特別重要？

傳統 API 也會定義 schema，但在 MCP 情境裡，工具描述本身會影響模型如何選擇與組合工具。輸入欄位名稱、描述、輸出結構與安全提示，不只是給前端看的文件，也可能成為模型規劃下一步時的上下文。

mcp-use 的 quickstart 使用 Zod 建立輸入與輸出 schema，再把它們交給 server.tool。例如天氣工具可以把 city 定義為字串，把輸出固定成城市、溫度與天氣狀況。這種做法的重點不在於範例本身，而在於讓工具的三種契約靠在一起：

開發者在 TypeScript 中能得到型別提示。
MCP client 能取得較清楚的工具定義。
React View 可以依照結構化結果渲染，而不是從一段自然語言中猜資料。

這會直接影響維護成本。當工具數量增加時，最怕的是 server 回傳格式悄悄改變，UI 仍假設舊欄位存在，最後只在模型實際操作時才爆出錯誤。把 schema 放在工具定義旁邊，不會消除所有錯誤，但能讓錯誤更早出現、更容易被定位。

從第一個工具開始：可驗證的快速上手

官方 README 提供的初始化入口是：

npx -y create-mcp-use-app@latest

建立專案後，依 README 的流程執行：

npm run dev

開發伺服器啟動後，可以打開：

http://localhost:3000/mcp/inspector

這個流程值得注意，因為它不是只產生一個空白專案。官方說明指出，scaffold 會準備 server、TypeScript 設定、開發腳本、Inspector 與 React view pipeline。對第一次接觸 MCP 的團隊來說，這比複製一段 server 程式碼更實用：你能在同一個本機環境裡建立工具、啟動服務，接著直接觀察 MCP endpoint。

最小的 server 大致包含三個部分：建立 MCPServer、用 schema 描述工具，以及在 handler 中回傳 MCP 內容與 structuredContent。以官方天氣範例來看，工具除了文字輸出，也會回傳結構化的 weather object。這個差異很關鍵：文字適合讓模型閱讀，結構化結果則適合被 View、其他程式碼或後續工具繼續使用。

React View 讓工具結果不必停在文字

當工具宣告 view: { name: "weather-card" } 後，mcp-use 可以把同名目錄中的 React 元件接到這個工具。官方範例透過 useToolContext 取得狀態、輸入與工具輸出，再用 useCallTool 重新呼叫工具。畫面可以呈現城市、溫度與狀態，也能提供 Refresh 按鈕。

我認為這裡最值得借鑑的不是「天氣卡片」本身，而是互動邊界的設計：

工具負責取得資料與定義資料契約。
View 負責把狀態轉換成使用者看得懂的介面。
呼叫工具的動作仍然透過明確的 hook 完成，而不是在 UI 裡偷偷複製一套 API 邏輯。

對企業知識庫、資料查詢、工作流程審批或內部營運助手而言，這個模型很自然。例如查詢報表的工具可以回傳結構化的摘要與明細，View 再提供篩選、重新查詢或下一步操作。模型負責理解意圖，工具負責執行，View 負責把結果變成可操作的工作介面。

但也要保持清醒：React View 不是自動生成完整產品。你仍要處理 loading、error、空資料、權限、重複提交、失敗重試與不同 client 的相容性。框架幫你把連線方式整理好，產品品質仍取決於你如何設計狀態與錯誤邊界。

Inspector 的意義：從「模型說它做了」回到可觀察

AI 應用最麻煩的除錯情境之一，是模型描述自己做了什麼，但開發者看不到真正送出的參數、工具回應與 UI 狀態。mcp-use 把 Inspector 放在快速上手路徑中，我認為這是一個正確選擇。

在本機開啟 Inspector 後，開發者可以先不依賴完整的 ChatGPT 或 Claude 產品整合，直接檢查 MCP endpoint 是否能被連線、工具是否出現、輸入是否符合 schema、回應是否包含預期的 structured content。這種測試順序可以把問題切開：

如果 Inspector 都連不上，先查 server、路由或網路。
如果工具出現但輸入失敗，查 schema 與參數描述。
如果工具成功但 View 不對，查 structured content 與前端狀態。
如果本機正常、外部 client 失敗，再查 client 能力與部署設定。

這比直接把所有變數丟進模型對話，再從一段自然語言輸出猜問題在哪裡，可靠得多。對準備進入正式環境的團隊，我會把 Inspector 視為開發階段的基本驗證入口，而不是可有可無的展示功能。

mcp-use 適合哪些專案？

第一類是需要把內部資料或動作暴露給 AI agent 的 TypeScript 團隊。例如 CRM 查詢、工單操作、文件搜尋、資料庫讀取與流程觸發。這些場景通常不只需要一個 function，還需要清楚的 schema、錯誤處理與可觀察性。

第二類是希望在對話之外提供互動式 AI 介面的產品。若使用者需要看表格、卡片、狀態進度或重新執行某個動作，Native Views 的方向會比單純回傳 Markdown 更接近產品需求。

第三類是正在評估 MCP Apps、ChatGPT 或 Claude connector 整合的前端團隊。mcp-use 的 scaffold、文件與 Inspector 能縮短概念驗證時間，讓團隊先驗證「工具契約與 UI 是否合理」，再投入完整平台整合。

相對地，如果你的需求只是寫一個極簡、長期穩定的 MCP server，而且團隊不使用 TypeScript 或 React，那麼直接採用更貼近語言生態的 SDK，可能更簡單。框架提供越多整合能力，代表你也要理解更多慣例與版本邊界。

導入前不可忽略的限制

第一，MCP 並不等於安全策略。 工具可以讀資料、寫資料，甚至觸發破壞性動作。schema 裡的 readOnlyHint、destructiveHint 與 openWorldHint 能提供提示，但不能取代伺服器端授權、使用者確認、審計紀錄與最小權限。任何會改變狀態的工具，都應該在 handler 和後端服務再次驗證權限。

第二，模型可理解不代表模型一定會正確使用。 工具名稱、描述與欄位說明要清楚，但還是要用真實任務測試錯誤選擇、缺少參數、過度呼叫與重複提交。尤其是多工具環境，命名衝突與模糊描述會讓問題變得難以追蹤。

第三，互動 View 增加了測試面積。 你不只要測 server，還要測 View 在 pending、error、空結果與資料格式變更時的行為。如果同一個 MCP app 會被多種 client 開啟，也要確認各 client 對 View、資源與連線生命週期的支援程度。

第四，版本遷移要有計畫。 README 已提供從 v1 遷移到 v2 的官方入口，這提醒我們不要只看目前能不能跑。正式導入前應鎖定版本、閱讀 migration guide、保留可重現的安裝設定，並把 server schema 與整合測試放進 CI。

我會怎麼開始一個小型試點？

我不會一開始就把整個企業資料層搬進 MCP。比較穩妥的做法是選一個唯讀、資料邊界清楚、失敗成本低的任務，例如查詢團隊文件或讀取一份測試報表。

第一步，用 scaffold 建立專案，確認本機 server 與 Inspector 都能運作。第二步，只加入一個工具，為輸入與輸出寫明確 schema，並設計幾個正常與異常案例。第三步，先用 Inspector 驗證工具，再接到目標 client。第四步，若文字結果確實不足以支援任務，再加一個簡單 View，而不是預先建立複雜的前端系統。第五步，把權限、日誌、逾時、重試與敏感資料遮罩補上，最後才討論部署。

這個順序的核心是把「協定連線問題」、「工具契約問題」、「介面問題」與「產品治理問題」分開驗證。mcp-use 可以降低前兩者的起步成本，但不應讓團隊誤以為後兩者會自動消失。

結語：MCP 應該被當成應用介面，而不是模型外掛

如果只把 MCP 當作工具清單，最後很容易得到一堆模型偶爾能呼叫、卻沒有人敢交付的 function。mcp-use 提供的方向，是把 MCP 往應用框架推進：用 TypeScript 與 schema 管理契約，用 React View 呈現互動結果，再用 Inspector 把開發與除錯變成可重複的流程。

我會把它定位成「適合快速建立可觀察 MCP 應用的 TypeScript 框架」，而不是所有 MCP 專案的唯一答案。對 AI Chain 讀者而言，真正值得帶走的判斷標準也許是：你的 MCP 專案是否需要結構化工具契約？是否需要把結果交給互動介面？是否需要在接上模型之前先看見完整的工具行為？如果答案是肯定的，mcp-use 就值得拿一個小型、低風險的任務來試驗。

參考資料