編輯  | 云昭

出品 | 51CTO技術棧（微信號：blog51cto）

最近 MCP 大火，一個好現象是，各個社區不再討論“究竟什么是 MCP”、“MCP 與 A2A 區別是什么”這種概念性的問題了。也算是從炒作期開始正式進入實干期了。 

不過，話說回來，雖然很多廠家都宣稱自己的產品接入了 MCP，但市面上構建的 MCP 水平如何？真的靠譜嗎？

今天就分享一篇有關 MCP 服務器真實構建現狀的干貨。

一、大多數MCP服務器都是錯建的

前兩周，在逛 Reddit 時，發現了一個“火藥味”十足的炮轟現在 MCP 的帖子。

“大多數 MCP 服務器都是錯建的。”一位昵稱為“incidentjustice”的網友稱。

圖片

太多初創公司在構建 MCP 服務器時，只是簡單地把現有 API 包一包，就當任務完成了。這完全是本末倒置。

這位網友對于這種質量不合格的“急功近利”行為表示憤怒：

這些構建者簡直不清楚 MCP 服務器該包含哪些內容！MCP 不僅僅是一個協議封裝器，它是一份“設計契約”——規范了大模型該如何與你的系統交互。

如果你的服務器只是丟原始數據給 LLM，而不考慮上下文限制、切片、數據相關性，那它基本沒用。一個好的 MCP 服務器應當只暴露所需內容，并提供合適的過濾、搜索和摘要機制。

他具體指出問題所在，“這不是在講‘訪問權限’，而是在說‘可用的、具上下文感知的訪問’。”

很快，就有網友表示自己也越到了太多“雞肋”一樣的 MCP。他認為，很多數據庫 MCP 就是這樣：大多數只是暴露了一個簡單的查詢工具，完全沒有上下文信息，也幫不了 Agent 去理解表結構或數據關系。

圖片

不止，其實還有很多人持這樣的觀點。

圖片

二、MCP ≠ 描述 + API

一位經常為各種場景構建 MCP 服務器的開發者 Tiemensma 最近分析了這種現象，并指出：

這種做法的結果，最多是“勉強能用”，最壞的情況是根本跑不通。

我經常看到的一個錯誤是：直接拿現有的 API，加點描述，然后就聲稱構建了一個 MCP 服務器。這種方式在 Glama、Smithery 等網站上的 MCP 工具中很常見，但效果往往平平，甚至徹底失敗。

我做 MCP 服務器已經有一段時間了，想分享一些我的經驗。我們真的該停止把 MCP 當作“帶有更好描述的 API”來看待了。因為模型與工具的交互方式，和傳統 API 的設計初衷之間，差異實在太大。

問題的根源在于：

API 是為人類開發者設計的，而 MCP 是為 AI 模型設計的。

開發者可以查文檔、試錯、積累經驗記憶，逐步理解系統。而 AI 模型沒有長期記憶，它只能根據「當前的自然語言請求」瞬間判斷出該用哪個工具、怎么組合使用。

而就在這個調用發生的瞬間，存在一個巨大的機會，恰恰很多 MCP 服務器并沒有利用好：通過把工具的響應設計為新的提示，來引導模型往正確方向走。

三、API 直轉 MCP 的兩個常見坑

1. Token 膨脹

一個工具的 JSON schema 通常就要 50100 個 token，加上描述再來 200，多參數每個還要 2050。一個擁有 80 個端點的 API，只是定義 MCP 工具，就得用掉約 24,000 個 token。也就是說，模型還沒開始用，就被 token 限制卡住了。

2. 概念混淆

API 中的術語對開發者有意義，但對模型極為混亂。

比如： “resource” vs “entity” vs “object”？

“community_members” 和 “space_members” 有啥區別？

模型根本沒有這些概念上下文，結果就是一臉懵。

所以，Tiemensma 認為：優秀的 MCP 設計，是把每一次工具響應都當作“提示模型”的機會。

四、案例反思：MCP應該圍繞用戶意圖來設計，而非API端點

Tiemensma 此前做過一個 Agent 的項目，是用來輔助管理 Circle.so 社區的。“我當時開放了一半的 API 端點給它通過函數調用使用，但始終表現不穩定。最近我重新思考了一下，如果是現在，我會怎么重新設計。”

一個很典型的用例是：獲取用戶活躍度信息。舊的 API 式做法是：讓模型先調用 get_members，然后再對每個成員分別調用 get_member_activity、get_member_posts 等等。這種方式既笨重、又耗費大量 token，而且很容易出錯。

而意圖導向的設計則是：創建一個叫做 getSpaceActivity 的工具，由服務端完成所有操作，并返回一個簡潔而豐富的對象。

當你有了一個優秀的、以意圖為中心的工具后，接下來的問題就是：你如何描述它。模型需要知道何時使用它、如何使用它。我發現，在工具描述中加入簡單的 XML 標簽非常有效，能清晰地區分“用途”和“使用方法”：

<usecase>Retrieves member activity for a space, including posts, comments, and last active date. Useful for tracking activity of users.</usecase>
<instructions>Returns members sorted by total activity. Includes last 30 days by default.</instructions>

關鍵在于，把每一個響應都當成是一次提示模型的機會。模型不會記住 API 的流程，因此你必須每次都用響應來“提醒”它。一個好的響應，不僅僅是返回數據，還應該引導模型進行下一步合理操作，比如：

“已找到 25 位活躍成員。可使用 bulkMessage() 工具與他們聯系。”

這在錯誤響應中尤為關鍵。一個典型案例是 Supabase 的 MCP。我曾在 Claude 4 Opus 上使用過，它有時候會“幻想”出一個 project_id。當模型使用一個虛構的 project_id 調用工具時，MCP 返回：

{"error": "Unauthorized"}

這個響應技術上沒錯，但完全沒幫助。它讓模型誤以為自己沒有權限，從而直接“卡死”。

注意：錯誤信息，就是當下的文檔，它必須具備“教育性”。更好的響應應該是：

{"error": "Project ID 'proj_abc123' not found or you lack permissions. To see available projects, use the listProjects() tool."}

這會告訴模型為什么出錯，以及接下來該怎么做。

這樣的機制還能減少初始 prompt 的冗余。如果模型在 90% 的情況下都能正確調用工具，而在出錯時也能靠好錯誤提示迅速糾正，就沒必要在最初的描述中窮舉每一個邊緣情況。

五、轉變思路：不要站在“開發者”的角度設計 MCP

其實，相信很多開發者最初做 MCP 工具時都會犯了這個錯：習慣用 API 的最佳實踐去設計，因為這樣做非常符合程序員的審美：模塊化、干凈、職責分離……

可事實證明：AI 根本不是按這種方式“思考”的。以下才是對模型真正重要的事：

1. 以“用戶意圖”為核心，不是“API 操作”

別再以系統結構來定義工具，要從“用戶想完成什么事”出發。

2. 每個響應都引導下一步

模型是無狀態的，響應不能只說“操作成功”，而是要告訴模型“接下來做什么”。

這里注意：不僅是錯誤提示，每一次返回都可以嵌入“下一步指令”。

例如，在搜索結果中返回：

“Found 5 results. Use getDetails() for full information.”

這樣模型就知道怎么繼續，不用你再解釋一堆流程。

3. 信息要有，但不能啰嗦

模型不能看文檔，所以你要把該講的講清楚。但 token 是有限的，必須“聰明壓縮”信息，比如用分頁、簡明描述等方式。

PS：這里有一個反直覺的經驗：描述不是越詳細越好。

真正有效的 MCP 描述，往往是結構化描述 + 高質量的錯誤提示引導。這樣做的目標，不是“覆蓋一切”，而是“90% 情況下能走對”。

推薦下面兩段式的描述結構：

<usecase>
這個工具是做什么的、什么時候該用它
</usecase>

<instructions>
具體該怎么用
</instructions>

這樣模型可以先判斷這個工具是否相關，然后再讀細節。

與其預先寫一大段字段和格式要求，不如只給出必要信息，其它靠錯誤提示動態引導。

例如：

如果模型漏填 ID，你可以返回這樣的錯誤："No ID provided for update. Use searchRecords() to find record IDs."

比起事前講一堆規則，這種方式更有效，也省 token。

4. 一個小技巧：做 MCP 工具時的合并策略

既不要把每個 API 端點都做成一個 MCP 工具（太碎），也不要所有操作塞進一個大工具（太復雜）。而應該：

（1）按“用戶意圖”來歸類。比如發送消息、查詢成員、獲取活躍度等。

（2）分開那些風險高的操作（如刪除、更新）——可以要求審批或限制模型調用。

六、網友：好了，現在又多了一個 MCP 需要維護！

以上，就是這些 MCP 服務器的構建方法。可以看出，現在許多 MCP 的構建水分還是很大的。有歸有，但實際使用還有很大的問題要處理。

一位 Reddit 網友表示：

我現在的掙扎點是，我是不是要預判所有針對自定義數據集的使用場景？直接包裝 API 很簡單，但現在還要維護數據庫、API、前端和 MCP，這會不會太復雜了？

即便是只維護 MCP 服務器，也有網友表示很繁瑣：

MCP 協議為啥不允許對整個服務器進行描述？現在只支持 per-tool 的描述。比如多個工具都要接收 file path，那路徑格式描述每個工具都得寫一遍，太低效了。

如果 MCP 工具的使用思路不夠直觀，即便底層做得再好，LLM 也很難用起來。除了逐個工具的描述外，能不能有一段全局的指引或 prompt？

不過有一點可以確定，MCP server 的構建已經日益流行。大家應該摒棄 API 包裝器的思維，而需要將其視為一種“全新應用形態”來設計。

畢竟，它應該是為一個有能力的、多模態的大模型或“智能體”來構建的接口，否則就很容易成為流于形式、徒有其表的噱頭了。

本篇文章到此結束，剩下的內容交由評論區的各位大佬發表看法了。周末愉快～

參考鏈接：

https://useai.substack.com/p/mcp-tool-design-from-apis-to-ai-first

https://www.reddit.com/r/mcp/comments/1lhws59/most_mcp_servers_are_built_wrong/