MCP解決了工具調(diào)用，但工具選擇仍是難題

過去大半年，我一直在搭建智能體工作流，同一個問題反復(fù)出現(xiàn)：我的智能體能調(diào)用的工具太多，卻幾乎無法判斷該用哪個。

MCP解決了訪問問題。它統(tǒng)一了智能體調(diào)用工具的方式、客戶端連接的方式、服務(wù)器自我描述的方式。這是實(shí)實(shí)在在的進(jìn)步，催生了一波實(shí)用的服務(wù)器——瀏覽器自動化、文件系統(tǒng)、搜索、數(shù)據(jù)庫，應(yīng)有盡有。

但訪問不等于選擇。當(dāng)我讓Claude Code"幫我搭建一個帶認(rèn)證的實(shí)時聊天應(yīng)用"時，它不需要全球所有MCP服務(wù)器的清單。它需要的是：選哪個數(shù)據(jù)庫、哪個實(shí)時傳輸協(xié)議、哪個認(rèn)證提供商，以及這四個選擇之間版本是否兼容。這是另一個問題，也是我開發(fā)ToolCairn的原因。

問題的形態(tài)

如果你基于MCP搭建過任何嚴(yán)肅的項(xiàng)目，大概率遇到過以下情況：

工具過載。智能體連接了30多個服務(wù)器，大多數(shù)對當(dāng)前任務(wù)都是噪音。表面積變成了上下文窗口問題。

選錯包。模型自動補(bǔ)全到流行但錯誤的庫。（requests vs httpx，socket.io vs 原生WebSocket，next-auth vs better-auth。）

版本漂移。單獨(dú)看每個選擇都沒問題，合在一起卻安裝失敗。或者安裝成功，運(yùn)行時因?qū)Φ纫蕾嚊_突崩潰。

沒有"為什么"。目錄列表告訴你某個工具存在，卻不告訴你為什么智能體應(yīng)該為這個特定任務(wù)選擇它、它與什么搭配得好、信任信號是什么。

這些問題并不罕見。任何非平凡的智能體項(xiàng)目在第一周就會碰到。

我做了什么

ToolCairn是一個MCP服務(wù)器。安裝方式和其他MCP服務(wù)器一樣：

claude mcp add toolcairn -- npx @neurynae/toolcairn-mcp

連接后，智能體獲得一套精簡聚焦的工具集：

classify_prompt——判斷請求是單工具需求、多層棧構(gòu)建、對比查詢，還是無關(guān)內(nèi)容。

search_tools / search_tools_respond——為特定需求找到合適工具，請求模糊時啟動澄清循環(huán)。

refine_requirement + get_stack——針對"幫我搭個SaaS分析儀表盤"這類任務(wù)，分解為子需求，返回跨工具兼容的連貫技術(shù)棧。

compare_tools——用戶問"X vs Y"時進(jìn)行正面比較。

check_compatibility——跨選擇的版本感知對等依賴評估。

check_issue——智能體再試三次之前，先查已知bug。

report_outcome——用戶實(shí)際使用推薦后閉環(huán)反饋，讓圖譜學(xué)習(xí)。

底層推薦來自一個跨35個以上開源倉庫索引的工具圖譜——npm、PyPI、Cargo、Maven、Go、Composer、RubyGems、NuGet、Homebrew等。當(dāng)前圖譜涵蓋數(shù)千個工具，附帶使用場景、倉庫元數(shù)據(jù)、版本數(shù)據(jù)——不是扁平的目錄列表。

一個具體例子

提示詞："幫我搭個帶認(rèn)證的實(shí)時聊天應(yīng)用"