大多數(shù)MCP都設(shè)計錯了！

51CTO技術(shù)棧

發(fā)布于 2025-7-7 07:53

瀏覽

0收藏

編輯 | 云昭

出品 | 51CTO技術(shù)棧（微信號：blog51cto）

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

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

今天就分享一篇有關(guān) MCP 服務(wù)器真實構(gòu)建現(xiàn)狀的干貨。

一、大多數(shù)MCP服務(wù)器都是錯建的

前兩周，在逛 Reddit 時，發(fā)現(xiàn)了一個“火藥味”十足的炮轟現(xiàn)在 MCP 的帖子。

“大多數(shù) MCP 服務(wù)器都是錯建的。”一位昵稱為“incidentjustice”的網(wǎng)友稱。

大多數(shù)MCP都設(shè)計錯了！ -AI.x社區(qū) 圖片

太多初創(chuàng)公司在構(gòu)建 MCP 服務(wù)器時，只是簡單地把現(xiàn)有 API 包一包，就當(dāng)任務(wù)完成了。這完全是本末倒置。

這位網(wǎng)友對于這種質(zhì)量不合格的“急功近利”行為表示憤怒：

這些構(gòu)建者簡直不清楚 MCP 服務(wù)器該包含哪些內(nèi)容！MCP 不僅僅是一個協(xié)議封裝器，它是一份“設(shè)計契約”——規(guī)范了大模型該如何與你的系統(tǒng)交互。

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

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

很快，就有網(wǎng)友表示自己也越到了太多“雞肋”一樣的 MCP。他認(rèn)為，很多數(shù)據(jù)庫 MCP 就是這樣：大多數(shù)只是暴露了一個簡單的查詢工具，完全沒有上下文信息，也幫不了 Agent 去理解表結(jié)構(gòu)或數(shù)據(jù)關(guān)系。

大多數(shù)MCP都設(shè)計錯了！ -AI.x社區(qū) 圖片

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

大多數(shù)MCP都設(shè)計錯了！ -AI.x社區(qū) 圖片

二、MCP ≠ 描述 + API

一位經(jīng)常為各種場景構(gòu)建 MCP 服務(wù)器的開發(fā)者 Tiemensma 最近分析了這種現(xiàn)象，并指出：

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

我經(jīng)常看到的一個錯誤是：直接拿現(xiàn)有的 API，加點描述，然后就聲稱構(gòu)建了一個 MCP 服務(wù)器。這種方式在 Glama、Smithery 等網(wǎng)站上的 MCP 工具中很常見，但效果往往平平，甚至徹底失敗。
我做 MCP 服務(wù)器已經(jīng)有一段時間了，想分享一些我的經(jīng)驗。我們真的該停止把 MCP 當(dāng)作“帶有更好描述的 API”來看待了。因為模型與工具的交互方式，和傳統(tǒng) API 的設(shè)計初衷之間，差異實在太大。

問題的根源在于：

API 是為人類開發(fā)者設(shè)計的，而 MCP 是為 AI 模型設(shè)計的。

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

而就在這個調(diào)用發(fā)生的瞬間，存在一個巨大的機會，恰恰很多 MCP 服務(wù)器并沒有利用好：通過把工具的響應(yīng)設(shè)計為新的提示，來引導(dǎo)模型往正確方向走。

三、API 直轉(zhuǎn) MCP 的兩個常見坑

如果你讓大模型直接用 API 樣式的 MCP，就會造成兩個最直觀的坑——

1. Token 膨脹

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

2. 概念混淆

API 中的術(shù)語對開發(fā)者有意義，但對模型極為混亂。

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

“community_members” 和 “space_members” 有啥區(qū)別？

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

所以，Tiemensma 認(rèn)為：優(yōu)秀的 MCP 設(shè)計，是把每一次工具響應(yīng)都當(dāng)作“提示模型”的機會。

四、案例反思：MCP應(yīng)該圍繞用戶意圖來設(shè)計，而非API端點

Tiemensma 此前做過一個 Agent 的項目，是用來輔助管理 Circle.so 社區(qū)的。“我當(dāng)時開放了一半的 API 端點給它通過函數(shù)調(diào)用使用，但始終表現(xiàn)不穩(wěn)定。最近我重新思考了一下，如果是現(xiàn)在，我會怎么重新設(shè)計。”

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

而意圖導(dǎo)向的設(shè)計則是：創(chuàng)建一個叫做 ??getSpaceActivity?? 的工具，由服務(wù)端完成所有操作，并返回一個簡潔而豐富的對象。

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

復(fù)制

<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>

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

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

這在錯誤響應(yīng)中尤為關(guān)鍵。一個典型案例是 Supabase 的 MCP。我曾在 Claude 4 Opus 上使用過，它有時候會“幻想”出一個 ??project_id??。當(dāng)模型使用一個虛構(gòu)的 ??project_id?? 調(diào)用工具時，MCP 返回：

復(fù)制

{"error": "Unauthorized"}

這個響應(yīng)技術(shù)上沒錯，但完全沒幫助。它讓模型誤以為自己沒有權(quán)限，從而直接“卡死”。

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

復(fù)制

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

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

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

五、轉(zhuǎn)變思路：不要站在“開發(fā)者”的角度設(shè)計 MCP

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

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

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

別再以系統(tǒng)結(jié)構(gòu)來定義工具，要從“用戶想完成什么事”出發(fā)。

2. 每個響應(yīng)都引導(dǎo)下一步

模型是無狀態(tài)的，響應(yīng)不能只說“操作成功”，而是要告訴模型“接下來做什么”。

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

例如，在搜索結(jié)果中返回：

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

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

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

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

PS：這里有一個反直覺的經(jīng)驗：描述不是越詳細(xì)越好。

真正有效的 MCP 描述，往往是結(jié)構(gòu)化描述 + 高質(zhì)量的錯誤提示引導(dǎo)。這樣做的目標(biāo)，不是“覆蓋一切”，而是“90% 情況下能走對”。

推薦下面兩段式的描述結(jié)構(gòu)：

復(fù)制

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

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

這樣模型可以先判斷這個工具是否相關(guān)，然后再讀細(xì)節(jié)。

此外，Tiemensma 還給出了一個寫描述的 90/10 原則：把復(fù)雜留給錯誤提示。

與其預(yù)先寫一大段字段和格式要求，不如只給出必要信息，其它靠錯誤提示動態(tài)引導(dǎo)。

例如：

如果模型漏填 ID，你可以返回這樣的錯誤："No ID provided for update. Use searchRecords() to find record IDs."
比起事前講一堆規(guī)則，這種方式更有效，也省 token。

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

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

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

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

六、網(wǎng)友：好了，現(xiàn)在又多了一個 MCP 需要維護！

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

一位 Reddit 網(wǎng)友表示：

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

即便是只維護 MCP 服務(wù)器，也有網(wǎng)友表示很繁瑣：

MCP 協(xié)議為啥不允許對整個服務(wù)器進行描述？現(xiàn)在只支持 per-tool 的描述。比如多個工具都要接收 file path，那路徑格式描述每個工具都得寫一遍，太低效了。
如果 MCP 工具的使用思路不夠直觀，即便底層做得再好，LLM 也很難用起來。除了逐個工具的描述外，能不能有一段全局的指引或 prompt？

不過有一點可以確定，MCP server 的構(gòu)建已經(jīng)日益流行。大家應(yīng)該摒棄 API 包裝器的思維，而需要將其視為一種“全新應(yīng)用形態(tài)”來設(shè)計。

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

本篇文章到此結(jié)束，剩下的內(nèi)容交由評論區(qū)的各位大佬發(fā)表看法了。周末愉快～