arabold/docs-mcp-server：把官方文件版本對齊你的專案，再交給 MCP 客戶端查詢
Grounded Docs MCP Server: Open-Source Alternative to Context7, Nia, and Ref.Tools
秒懂
- 它是什麼？
- 這個專案用 CLI 或長駐 MCP 端點，把官網、GitHub、npm、PyPI 與本機檔案抓成本地索引，讓 AI 助理查到你實際使用的版本。它值得用，前提是你願意負擔索引與嵌入模型的維運成本。
- 適合誰用？
- 如果你的團隊已經在用 Claude、Cline、Copilot 或 Gemini CLI，而且痛點是助理引用舊版 API，這個專案值得先以 CLI 試跑一次 scrape 與 search，確認檢索品質再決定是否長駐。若你不想自行維運索引與嵌入模型，或文件站台是純前端渲染且沒有 llms.txt，託管式服務如 Context7 會省下不少工。
- 可以商用嗎？
- 可以。MIT 是寬鬆授權：你可以使用、修改並販售以它為基礎的軟體，只需保留著作權與授權聲明。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 17 天前。
- 用什麼語言寫的？
- 主要是 TypeScript（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
它解決的是版本漂移，不是「AI 不懂文件」
多數人把這類工具理解成「幫 AI 補文件」，這個說法太鬆。真正的問題是版本漂移：你的 package.json 鎖在某一版，模型腦中的 API 卻停在訓練語料的那一版，於是它給出已經被移除的參數、改名的 hook、或根本不存在於該版本的設定鍵。README 把它寫成「queries target the exact library versions in your project」，這句話才是專案的核心主張。
對象也很明確。會用到 MCP 客戶端的人，也就是 Claude、Cline、Copilot、Gemini CLI 的使用者，而且手上有一份會隨版本變動的第三方依賴。反過來說，如果你的專案幾乎不引入外部套件，或你查的文件是內部規格而非公開官網，這個工具的價值會下降，因為它最擅長的是抓取公開文件來源。
README 把它定位成 Context7、Nia、Ref.Tools 的開源替代品。差別不在功能清單，而在資料落地何處：這個專案「runs entirely on your machine」，索引與查詢都在你的網路內完成。對某些團隊來說這一點比檢索品質更關鍵。
抓取、切分、索引：資料流的三段
從 README 與 CLI 介面可以看出三段流程。第一段是抓取，來源包含網站、GitHub 儲存庫、npm、PyPI 與本機資料夾，也吃 zip 與 tar 壓縮檔，壓縮檔內容會被逐項解開處理。第二段是解析與切分，支援的格式清單相當長：PDF、Word、Excel、PowerPoint、OpenDocument、RTF、EPUB、FictionBook、Jupyter Notebook，加上 Markdown、MDX、reStructuredText、AsciiDoc、Org Mode 等標記語言，以及九十多種原始碼語言。第三段是索引與檢索，這一段有兩條路徑。
沒有嵌入模型時，檢索靠關鍵字與結構化比對。README 說嵌入模型是 optional，但「dramatically improves search quality by enabling semantic vector search」。這句話反過來讀就是：不設嵌入模型，語意檢索不會發生。你問「useEffect cleanup」卻在文件裡寫成「清除副作用」，純關鍵字比對很可能撈不到。
檢索品質不是憑感覺調。專案附了一份 benchmark 指南，用 IR 指標加上 LLM 評分來量測檢索結果，並說明如何執行與解讀。這一點在同類工具裡並不常見，因為多數專案只給你一個搜尋框，不給你一把尺。
llms.txt 探測與 Markdown 協商：抓取層的兩個設計
網頁抓取有兩個機制值得單獨看。第一個是 llms.txt 探測：爬取與更新會先在文件子路徑與站台根目錄尋找 llms.txt，找到就把裡面整理的連結當成額外的爬取種子，而且這些路徑優先嘗試 .md 變體，例如 /guide/index.html.md 或 /page.html.md，失敗才退回原始頁面。這是把「站台作者已經整理好的文件入口」直接拿來用的做法，比讓爬蟲自己走連結省事，也少抓一堆導覽列與廣告頁。
第二個是內容協商。網頁請求預設送出 Accept: text/markdown, text/html;q=0.9, */*;q=0.8。支援 Markdown 協商的伺服器會直接回傳 Markdown，省掉把 HTML 轉回文字的步驟，轉換過程中的程式碼區塊遺失、表格走位這類問題也跟著消失。README 提到 Cloudflare 等服務支援這種協商。
這兩個機制都有前提：站台得配合。llms.txt 是社群約定，不是標準，很多文件站台沒有；內容協商也取決於伺服器與 CDN 設定。沒配合的站台就退回一般爬取，此時抓取深度與涵蓋範圍就回到爬蟲本身的判斷，品質落差可能不小。
CLI 與 MCP 端點：兩種用法，不同取捨
專案同時提供 CLI 與長駐伺服器。CLI 的路徑最短，README 給的例子是先用 npx @arabold/docs-mcp-server@latest scrape react https://react.dev/reference/react 建立索引，再用 search react "useEffect cleanup" --output yaml 查詢，需要單頁時用 fetch-url https://react.dev/reference/react/useEffect 直接取回 Markdown。結構化指令在非互動模式下預設把乾淨的 JSON 送到 stdout，診斷訊息走共用 logger 並避開 stdout，--quiet 關掉非錯誤訊息，--verbose 打開除錯輸出。這套 stdout 紀律對寫腳本的人很重要，因為它讓輸出可以直接餵給下一個程式。
MCP 端點則適合需要長駐服務的情境。直接執行 npx @arabold/docs-mcp-server@latest，開啟 http://localhost:6280 的 Web UI 加入文件，然後在客戶端設定裡掛上 SSE 端點 http://localhost:6280/sse。Docker 版本用 ghcr.io/arabold/docs-mcp-server:latest，掛載 docs-mcp-data 與 docs-mcp-config 兩個 volume，並帶上 --protocol http --host 0.0.0.0 --port 6280。
兩者的差別在生命週期。CLI 每次執行都是一次性工作，索引狀態要自己想辦法保存與更新；MCP 端點是常駐服務，Web UI 可以隨時補文件，但也就多了一個要顧的服務與一個要開的埠。README 建議設定嵌入模型時直接以環境變數帶入，例如 OPENAI_API_KEY="sk-proj-..." npx @arabold/docs-mcp-server@latest，Ollama、Gemini、Azure 的做法寫在 embedding-models 指南裡。
另外有一個容易踩的細節：--preserve-hashes 只該用在以 #/guide 這類網址路由的文件站台。README 明講一般站台的 hash 通常只是頁內錨點，開了反而會把同一頁的錨點當成不同頁面，索引被灌水。更麻煩的是，當這個選項搭配 scrapeMode=fetch 時，抓取器會自動升級成 Playwright，因為單純的 fetch 無法執行客戶端的 hash 路由。也就是說，一個旗標會連帶把抓取成本與相依性往上抬一階。
維護成本落在索引新鮮度與嵌入模型帳單上
這個專案不會自動變聰明。文件更新了，索引不會自己跟上，除非你觸發 refresh。README 提到 refresh 預設會沿用既有的 preserveHashes 設定，CLI 與 Web 的更新入口都能明確覆寫。這是個合理設計，但同時也說明更新是一個你要主動發起的動作。
嵌入模型的成本要單獨算。用 OpenAI 就是按量計費，每次重新索引整份文件都會再打一次 embedding API；改用 Ollama 可以避開帳單，代價是本機要跑得動模型，且索引時間會拉長。README 沒有給任何索引速度或成本的數字，所以任何「比別人快幾倍」的說法在這個材料裡都無法成立，我也不打算編。
儲存面則取決於部署方式。Docker 版本把資料放在 docs-mcp-data，設定放在 docs-mcp-config，備份與遷移就是處理這兩個 volume。
授權是 MIT，這是寬鬆授權，修改與商用都相對自由。但要注意這只涵蓋本專案的程式碼：你抓下來的文件內容仍受各站台自己的授權約束，嵌入模型供應商的服務條款也另外算。這不是法律意見，真要落地前請找法務確認。
什麼情況下它會變成負擔
第一個失效情境是純前端渲染、又沒有 llms.txt 的文件站台。爬蟲拿到的可能是一份空殼 HTML，真正的內容要等 JavaScript 執行完才出現。專案對這個問題的處理是繞道：啟用 preserveHashes 且 scrapeMode 為 fetch 時自動升級到 Playwright。這解決了部分情境，但代價是抓取變慢、資源吃得更多，而且只覆蓋 hash 路由這一種形態。
第二個是文件量與更新頻率的組合。索引一份大型文件站台需要時間與 embedding 額度，如果上游每週改版，你的索引就會長期落後。這種情況下，索引的新鮮度反而成為新的幻覺來源：模型引用的是你上個月抓的版本，跟你今天裝的版本已經不同。
第三個是團隊規模。這是單機導向的設計，README 強調「your code never leaves your network」，但沒有描述多人共用索引、權限或集中式部署的做法。幾十人的團隊要共用一份索引，得自己想辦法，而這部分材料裡看不到答案。
最後，如果你的需求只是偶爾查一頁 API，fetch-url 這種單頁抓取就夠了，整套索引與嵌入模型的維運並不划算。
與 Context7 的分歧在資料落地，不在功能表
README 直接把 Context7、Nia、Ref.Tools 列為對照對象。兩邊的差異可以講得更具體一點。
Context7 這類託管服務把抓取、索引與檢索都放在供應商端，你只要接上端點就能用，索引新鮮度由對方維護，你不需要跑嵌入模型，也不需要保留資料目錄。代價是查詢內容會經過第三方，且你能索引哪些來源、用什麼切分策略，取決於對方的支援範圍。
docs-mcp-server 走的是另一條路：抓取、切分、索引、檢索全在你的機器上完成，資料目錄是 docs-mcp-data 這個 volume，嵌入模型可以是本機 Ollama，整條鏈路不出你的網路。代價是你要自己觸發 refresh、自己負擔 embedding 成本、自己處理 Playwright 這類抓取相依性。
所以選擇的判斷點不是「哪個功能多」，而是你能不能接受文件內容與查詢字串離開自己的網路。能接受，託管服務省事；不能接受，就得接手這套索引的維運。這兩者之間沒有中間路線，材料裡也沒有看到混合部署的說明。
編輯結論
如果你的團隊已經在用 Claude、Cline、Copilot 或 Gemini CLI，而且痛點是助理引用舊版 API，這個專案值得先以 CLI 試跑一次 scrape 與 search，確認檢索品質再決定是否長駐。若你不想自行維運索引與嵌入模型，或文件站台是純前端渲染且沒有 llms.txt，託管式服務如 Context7 會省下不少工。導入前先確認三件事：Node.js 是否達 22 以上、嵌入模型要走 OpenAI 還是本機 Ollama、以及你的文件站台是否需要 --preserve-hashes。這三項沒確認，後面調檢索品質會白費力氣。
社群筆記