MCP 伺服器去哪找？實測 Awesome MCP Servers 的收錄規則

用 AI 摘要這篇文章：

ChatGPT Claude Perplexity Google Grok

打開搜尋引擎找 MCP server，很快就會撞見它：punkpeye 維護的 awesome-mcp-servers。Anthropic 在 2024 年 11 月 25 日公開 MCP（Model Context Protocol，模型上下文協定），五天後這個 GitHub 倉庫就跟著成立，到 2026 年 9 月已經累積超過 9.5 萬顆星，比官方自己的 modelcontextprotocol/servers 倉庫還要多。

先講結論：要找 MCP 伺服器，從這份清單開始沒有錯，它分類細、更新快，可瀏覽性在同類資源裡數一數二。但把它當成品質保證就是另一回事了。我把整份清單抓下來逐項清點，再沿著它的收錄流程往裡挖，看到的圖像是：這份名義上屬於社群的目錄，收錄管線已經和一家商業公司綁在一起，而且綁得很深。數字和證據攤開來看，你會知道它值得用在哪裡，以及哪些地方要自己把關。

四千兩百多個伺服器，收在同一個 README 裡

先花三十秒把名詞講清楚。MCP 是一種開放標準，解決的問題是：每個 AI 助手要接外部工具（查資料庫、操作瀏覽器、讀檔案），以前都得替每個組合寫一次客製程式，MCP 把這件事標準化，做成一種共通的轉接規格。所謂 MCP 伺服器，就是照這個規格包裝好的工具匣，AI 助手接上它，就能使用裡面的功能。

awesome-mcp-servers 的本體就一個檔案：README.md，2026 年 9 月的版本有 4,730 行、1.83 MB。逐項清點的結果是 4,219 條伺服器條目，對應 4,173 個不重複的 GitHub 倉庫，分裝在 58 個分類裡。分類的顆粒度很細，從瀏覽器自動化、資料庫、檔案系統、家庭自動化，到航空航天與占星計算都有專屬區塊。長尾的程度可以感受一下：有個大中華生活服務綜合伺服器，把外送、叫車、支付、地圖和 12306 高鐵購票全塞進同一個工具匣；獨立做的 12306 餘票查詢伺服器我們先前也實測過。

Pin

成長速度也能量化。我調出這個倉庫 2025 年 3 月 31 日的 README 快照來對比：當時全檔 660 行、26 個分類、385 條收錄；十八個月後變成 4,730 行、58 個分類、4,219 條，條目數翻了十一倍。這個曲線量測的與其說是清單的品質，不如說是 MCP 生態本身的膨脹速度：協議公開還不到兩年，「替 AI 助手做一個工具匣」已經長成一個有數千個參與者的品類。

它和官方資源的關係容易搞混，值得先釐清。modelcontextprotocol/servers 倉庫放的是協定官方提供的少數參考實作，README 開頭就自己聲明這些是教學示範、不是生產環境可用的方案，還加了一句指引：要找伺服器清單，請去官方的 MCP Registry。這個官方 Registry 已經開放，我用它的 API 翻頁，數到八千筆還沒有見底；同一個伺服器的每個發布版本各算一筆，去掉重複後約兩千九百個不重複伺服器，還追不上這份清單的 4,219 條，但已經是同一個量級的資料庫。差別在定位：官方 Registry 是搜尋與發布的資料庫，awesome-mcp-servers 是有人整理分類、可以像目錄一樣翻的索引，各有各的用處。另外它還有兩份姊妹清單，純託管、免安裝的遠端伺服器在 awesome-remote-mcp-servers，客戶端 App 整理在 awesome-mcp-clients，三份都由同一個人維護。

清單還備有七種語言的翻譯版，但繁體中文版只剩歷史意義：英文版收 4,219 條的今天，繁中版只譯了 321 條，停在清單早期的規模，用字也偏向對岸慣用語，讀起來會有隔閡。要查現況，直接讀英文版。

新伺服器要進名單，先過一個叫 Check Glama Link 的機器人

看完規模，再看收錄怎麼運作，這是整份清單最有戲的部分。

新條目靠 pull request 投稿。貢獻文件裡有一條很少見的規定：投稿者如果是自動化代理（agent），只要在 PR 標題結尾加上三個機器人表情符號，合併就會走快速通道。這不是聊備一格的條款，用這個標記的 PR 累積已有 4,826 個；我抽查最近四天的投稿，帶標記的約占三分之二，標題清一色是「加入某某公司或某某開發者的 MCP 伺服器」。換句話說，這份清單的進貨主力，是各家產品自己派機器人來上架，工程師社群彼此推薦的反而少見。

投稿之後，倉庫裡一個名為 Check Glama Link 的 CI 工作流會自動檢查每個 PR，給它貼標籤。檢查項目包括表情符號是否合法、連結是否重複、條目名稱是否符合規範，以及最關鍵的一條：新條目有沒有掛上 glama.ai 的分數徽章。沒有的話，機器人會在 PR 底下留言，開頭說「為了確保只列出能用的伺服器，收錄要求正在更新」，接著列步驟：先把你的伺服器提交到 Glama（一家經營 MCP 目錄與評分的商業公司），在 Glama 平台補上 Dockerfile，讓它通過啟動測試與客戶端詢問測試，最後回來把徽章加進條目。

Pin

這裡有個數字值得停下來看：截至 2026 年 9 月，掛著 missing-glama 標籤、卡在這一步的開放 PR 有 1,177 個。要說精確，這道關卡是軟性的：CI 只貼標籤和留言，最終合併權在維護者手裡，倉庫裡也確實存在沒掛徽章就收錄的條目。但對一個想快點上架的投稿者來說，機器人指的路只有一條：先去 Glama 註冊。一份 GitHub 上的開源清單，新投稿的事實上關卡，是先成為一家商業目錄的登錄項目。

這個生態的基礎設施集中度，比表面看起來高。維護者同一個人的名下，還有讓桌面助理連接遠端伺服器的連線工具 mcp-remote（後面安全段還會談到它）、TypeScript 版的 MCP 框架 fastmcp，以及客戶端與開發工具兩份姊妹清單。查詢入口、部分連線工具、框架，都壓在同一個人身上，這對單一維護者的專案來說是把雙面刃：風格一致、決策快，但也代表他的優先順序（以及他的公司）會形塑整個入口的樣子。

話說回來，這道閘門有它實際的功能，批評要批評得準。MCP 伺服器要真的能啟動、能回應客戶端「你有哪些工具」的詢問才算過關，多少擋掉純投機的空殼倉庫，而機器人指定的整個流程裡，沒有出現任何付費步驟。問題出在另一件事。清單維護者 punkpeye 的 GitHub 個人頁寫得很明白：本名 Frank Fiegel，任職公司欄填的是 Glama，自述是工程師轉創辦人。清單的 CI 機器人、徽章圖檔、社群 Discord 連結都掛在 Glama 的網域上，就連教學區的前兩條也是 Glama 的內容：一個是 Glama 的 GitHub 專案，一個直接連到 Glama 的部落格。維護者和閘門公司的創辦人是同一個人，而這層關係在清單頁面上找不到任何說明。你看到的「精選清單」，投稿漏斗的另一端是一家公司的潛在客戶名單。

徽章分數量的是說明書，不是安全

清單裡 2,877 個條目，約三分之二，掛著 Glama 徽章，點進去是該伺服器在 Glama 目錄的評分頁；剩下的 1,342 條沒有徽章，多半是這套要求上線前就收錄的舊條目，這個數字對比本身就說明徽章制是中途加上的新規。照 Glama 自己公布的評分規格（TDQS，工具定義品質分數），這個分數的七成來自每個工具的說明文字與參數描述寫得好不好，三成來自整體一致性，打分的方式是讓語言模型按評分細項逐項評。

這個分數有它量測的東西。一份說明文字確實會直接影響 AI 助手能不能正確呼叫工具：同樣一個查詢工具，說明只寫兩個字，模型就只能瞎猜參數；說明把參數格式、回傳內容、錯誤情境寫清楚，模型第一次就呼叫成功的機會就高得多。從這個角度看，徽章對投稿者是一道流程之外的品質回饋，對使用者是初步的過濾訊號。

但它量不到的東西更多。程式碼有沒有後門、會不會把你的資料送往第三方、伺服器扛不扛得住生產環境的流量、作者會不會棄坑，都不在分數的範圍裡。把徽章當成文件品質的參考可以，把它當安全或穩定認證，就是誤讀了。清單自己也沒有做安全把關的宣稱，這點它倒是誠實的。

收錄了，不代表還活著

CI 只檢查新投稿，不回頭清理舊條目，那 4,219 條裡有多少已經失效？我做了系統抽樣：每隔固定間隔取一個倉庫，共抽 30 個逐一查證。結果是 28 個還活著，1 個已經 404，1 個被作者封存（archived）。以目錄的標準而言這個活率不算差，但抽到的那筆封存很值得記下來：prisma/mcp，知名資料庫工具公司 Prisma 的官方 MCP 倉庫。連大廠的官方作品都會收攤，清單上的每一條本來就該當成有待驗證的線索，而不是現貨。

清單的毛邊也印證了這種進貨快、整理少的體質。E-Commerce 分類在同一份 README 的第 1,986 行和第 2,035 行各出現一次，連網頁錨點名稱都相同；貢獻文件要求分類按字母排序，實際開頭卻是 Aggregators、Aerospace、Agreements、Accessibility 這樣的順序，CI 顯然不管排序。重複與錯置要靠有人手動發 PR 修，追不上每天十幾個新條目的進貨速度。這也是大型 awesome 清單的通病，收錄的動能來自想被看見的投稿者，整理的動能卻只能來自維護者的空閒時間。

真正會咬人的在安裝那一步

清單本身只是文字連結，風險不會從 README 跳出來。但它的下一步，把伺服器裝起來，是這個生態真正危險的地方，而且風險是現在進行式。

GitHub 安全通告資料庫裡，2026 年 9 月 21 日新添了一筆重大等級認定：npm 套件 @vite-mcp/vite-type 是惡意軟體，官方說明寫的是裝過或執行過這個套件的電腦應視為已完全淪陷，所有金鑰都應該換掉。名稱裡掛著 mcp 字樣的套件被拿來當誘餌，而且就是這個月的事。再往前一筆，2025 年 7 月的通報顯示，MCP 生態常用的遠端連線工具 mcp-remote 曾有嚴重等級的弱點（CVE-2025-6514，CVSS 9.6）：連上不受信任的 MCP 伺服器時，對方可以在授權流程裡塞入經過設計的內容，觸發作業系統層級的指令注入。也就是說，在這個生態裡，連「連線」這個動作本身都曾經是攻擊面。

這裡要先還清單一個公道：它其實有一個收滿 242 條的安全分類，裡面不乏認真做供應鏈防護的作品，例如掃描工具定義是否被下毒、用內容雜湊鎖定版本的供應鏈閘道，以及裝機前先比對惡意套件通報的檢查工具。但收錄安全主題的工具，與收錄機制本身做安全把關，是兩回事：清單的閘門只確認伺服器能啟動、能應答，進到清單的每一個伺服器，程式碼層面的安全仍然沒有人替你審過。清單替你省的是尋找的時間，省不了查證的時間，這一點不變。

防護的基本盤其實不複雜，難的是養成習慣。能裝在容器或沙箱裡跑的伺服器，就別讓它直接碰主系統；伺服器要的檔案系統、瀏覽器、環境變數授權，用不到的範圍一律不給，環境變數裡的 API 金鑰只放它真的需要的那些；不認識的遠端伺服器位址不要連，前面那個指令注入案例的教訓就是「連線」這個動作本身也有成本。MCP 的價值在於讓 AI 助手方便拿到工具，方便的方向對攻擊者也一樣成立。

怎麼從四千條挑出你要的那一條

實際要用的時候，我的建議是把清單當索引用，挑選的判斷留在清單外。

先縮小範圍。用 README 的分類錨點直接跳到你的領域，別從頭滑。每條條目都帶語言與作業系統的表情符號標記，例如 🐍 代表 Python 程式碼、📇 代表 TypeScript，先用這些標記刷掉你不維護的技術棧。以資料庫分類為例，實數是 141 條，其中掛 🎖️ 官方標記（代表工具官方自己出品或深度維護）的只有 17 條，其餘一百多條都是社群與廠商作品，同一個投稿者連續上架兩條的痕跡也直接排在頁面上。縮完範圍你會發現，真正要比較的對象其實只有個位數。

符號裡還有一組要分清楚：☁️ 與 🏠 的差別。清單的圖例說明寫得清楚，☁️ 代表雲端服務，你的請求和資料會經過對方的伺服器；🏠 代表本機執行，工具跑在自己的電腦上。這個符號對隱私敏感的讀者比徽章分數更實用：要接公司資料庫或私人文件庫的伺服器，選 ☁️ 等於把通道交給第三方，選 🏠 才談得上自己控制資料流向。同一個功能常常兩種形態都有人做，挑的時候先問自己要哪一種。

再驗倉庫本身。點進候選的 GitHub 頁面，先看最後提交時間，再看 issue 有沒有人回、授權條款在不在。這一輪會刷掉為數不少的棄坑品與空殼品，前面抽樣裡那種封存倉庫就是在這一步現形。徽章分數可以看，但記住它量測的是說明文件。

裝之前，回到套件管理器的官方來源核對名稱。GitHub 倉庫和 npm 套件是兩回事，冒名套件是這個生態被實證的攻擊手法。具體查四個欄位：套件的發布者是誰（和倉庫作者同一個人嗎）、上次發布時間、每週下載量級、以及套件頁連回的倉庫網址是否就是你從清單點進去的那個。冒名攻擊在這幾項上通常會露餡，正牌套件則經得起對。安裝後不需要的授權範圍（檔案系統、瀏覽器控制、環境變數）也值得逐項檢視，能關就關。

入口也不只這一份。想要官方血統，MCP Registry 的資料可以直接搜尋；喜歡評分與分類的瀏覽體驗，Glama、Smithery 這類商業目錄都活著且收錄量大。它們和 awesome 清單一樣，都只是入口，沒有任何一家替你做過安全背書，這個判斷在哪個入口都省不掉。

不同身分的讀者，停點也不同。個人用戶只想讓 Claude Desktop 或類似桌面助理多幾個本事，清單夠你挑兩三個夠用的伺服器，裝了不順手就移除，試錯成本低。開發者要替自己的應用接工具，比起裝多少伺服器，更該在意客戶端怎麼呼叫，這時 mcp-use 這類開源函式庫比堆伺服器更貼近需求。已經有一組固定伺服器要管理的重度使用者，桌面管理面板是另一條路，我們實測過的 AiMaMi 把對話、MCP 與模型路由收在同一個介面。

這份清單幫不了你的事

最後把界線畫清楚。這份清單能給你的：一個分類完整、持續進貨的 MCP 伺服器索引，還有一條被啟動測試過濾過一部分的新品流。它不能給你的：品質排序（收錄沒有分層，熱門與空殼平起平坐）、安全保證（徽章量測的是說明文件）、中文現況（繁中版停在早期規模），以及收錄項目的授權狀態（MIT 條款保護的是清單這個檔案本身，清單裡 4,173 個倉庫各有各的授權，其中不乏沒有授權條款的）。

它也不會告訴你，自己的收錄閘門與一家商業公司的利益共用同一條管線。這不代表清單不能信，你現在知道規則了：把它當圖書館的卡片目錄，別當採購認證。找到候選，驗倉庫、驗套件來源、驗授權，這幾步做完再按下安裝，MCP 生態的紅利你領得到，坑也繞得過。

清單與真實專案之間的差距，我們在 1k GitHub Stars 開源星數地圖 的實測裡遇過同樣的結論：星數與收錄告訴你哪裡熱鬧，哪裡能落腳，要自己走一趟才知道。