arxiv-mcp-server：把論文閱讀迴路留在本機的 MCP 伺服器
A local MCP server for agent literature work. Original-LaTeX section reads, BibTeX from arXiv metadata, and topic watches. Papers stay on disk. Search is optional.
秒懂
- 它是什麼？
- arxiv-mcp-server 是給代理程式做文獻工作的本地 MCP 伺服器，主打原始 LaTeX 章節讀取、從 arXiv 中繼資料產生 BibTeX，以及主題追蹤。搜尋是選配，論文檔案留在磁碟上。
- 適合誰用？
- 適合需要讓 Claude、Codex 或 Hermes 代理反覆閱讀單篇論文、逐節消化 LaTeX 並產生引用資料的研究者，尤其是重視論文檔案留在本機、不願每次搜尋都依賴外部服務的人。不適合把 arxiv-mcp-server 當成搜尋引擎或引用圖譜工具的使用者，因為 README 明說這些功能仍呼叫外部服務，伺服器本身不是搜尋包裝。
- 可以商用嗎？
- 可以。Apache-2.0 是寬鬆授權：你可以使用、修改並販售以它為基礎的軟體，只需保留著作權與授權聲明。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 20 天前。
- 用什麼語言寫的？
- 主要是 Python（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
這不是搜尋包裝，而是論文閱讀迴路
arxiv-mcp-server 解決的問題很具體：當語言模型代理需要做文獻工作時，常見做法是把 arXiv 搜尋結果丟給模型，但這只涵蓋摘要與中繼資料。這個伺服器把工作迴路定義為 paper ID 到 outline、再到單一 section、最後到 citations。也就是說，它服務的對象是已經鎖定某篇論文、想深入讀原始 LaTeX 的代理程式，而不是還在探索階段、需要大量搜尋結果的研究者。README 直接寫明「Search is optional」，搜尋是選配，這與多數 arXiv MCP 工具把搜尋當核心的設計相反。作者的意圖很清楚：搜尋、來源抓取、引用圖譜與下載都各自呼叫外部服務，真正留在本機的是文獻閱讀迴路。
原始 LaTeX 章節讀取與 BibTeX 的來源差異
這個伺服器的差異點在於讀取作者投稿的原始 LaTeX，而不是 arXiv 產生的 PDF 文字層。對代理程式來說，LaTeX 保留了數學式、表格結構與章節界線，逐節讀取比一次讀完整篇更符合模型的工作記憶限制。BibTeX 則從 arXiv 的權威中繼資料產生，不是從 PDF 猜。這兩個來源的差異值得注意：LaTeX 是作者投稿版本，可能與最終排版版本有出入，而中繼資料是 arXiv 官方記錄。伺服器把這兩者分開處理，表示它預設使用者在意的是引用正確性，而不是 PDF 的視覺呈現。引用資料的可靠性來自 arXiv，不是來自模型推論，這對寫論文的人來說是實質差異。
安裝與設定：uvx 一條命令，但用戶端格式各異
預設安裝命令是 uvx arxiv-mcp-server，這需要 uv 提供的 uvx，不需要複製倉庫或建立 Python 環境。README 給出標準的 stdio 設定，形狀是 mcpServers 的 JSON，適用於 Claude Desktop 與 Kiro。但其他用戶端可能用頂層 servers 物件、TOML 或自己的設定介面，這表示同一套設定不能到處貼上。預設論文目錄是 ~/.arxiv-mcp-server/papers，要改目錄就在 args 加上 --storage-path 與絕對路徑。Claude Code 有 claude mcp add --transport stdio --scope user arxiv -- uvx arxiv-mcp-server 的單行安裝，OpenAI Codex 用 codex mcp add arxiv -- uvx arxiv-mcp-server，Hermes Agent 用 hermes mcp add arxiv --command uvx --args arxiv-mcp-server。這些命令都不難，但用戶端之間的差異是實際採用成本。
主題追蹤與磁碟儲存：本機狀態的意義
主題追蹤（topic watches）是這個伺服器另一個少見的功能，它把追蹤清單放在磁碟上，而不是放在模型的對話脈絡裡。這表示代理程式重啟後，追蹤狀態仍然存在，不會因為對話結束而消失。論文檔案同樣留在磁碟，預設目錄可自訂。這個設計的意義在於：代理工作往往跨越多個 session，如果狀態只存在於模型脈絡，每次都要重新建立。把狀態寫進磁碟，等於給代理一個持久的工作記憶。但這也帶來代價，多個用戶端同時連到同一個儲存路徑時，可能發生寫入衝突，README 沒有說明並行存取的行為，這點採用前需要自行驗證。
真正的限制：搜尋仍是外部依賴，LaTeX 版本有落差
README 誠實地指出，搜尋、來源抓取、引用圖譜與下載都呼叫各自的外部服務。這表示如果代理的工作流程從搜尋開始，伺服器仍然依賴 arXiv API 與其他服務的可用性。作者說「This is not a search wrapper」，但這也代表它不打算取代搜尋，只專注在讀取迴路。另一個限制是原始 LaTeX 與最終出版版本可能不同，作者投稿版本可能含有未修正的錯誤，或者缺少排版階段加入的修正。對於依賴出版版本的引用或內容判斷，這會是錯誤工具。此外，伺服器需要 uv 環境，如果使用者的系統沒有 uv，安裝路徑會多一步。這些限制都不是致命，但都說明了它適合的場景有明確邊界。
替代方案：搜尋包與全文閱讀器的取捨
arXiv 相關的 MCP 伺服器很多，多數以搜尋為核心，呼叫 arXiv API 回傳論文清單與摘要。這類工具適合探索階段，代理可以快速篩選候選論文，但它們通常不提供原始 LaTeX 的逐節讀取，也不一定產生 BibTeX。另一類替代是通用 PDF 閱讀器，代理直接讀取下載的 PDF 文字層，這種方式不依賴 arXiv 的 LaTeX 來源，但會失去數學式與結構資訊，引用資料也需要另外處理。arxiv-mcp-server 的取捨是：放棄搜尋的便利，換取更乾淨的閱讀來源與引用中繼資料。如果你的工作流程是「先搜尋再深入閱讀」，可能需要並用兩類工具，而不是只用這一個。
維護與授權：Apache-2.0 與發布節奏
專案授權為 Apache-2.0，這對商業使用與修改都相對友善，但具體義務仍以授權條款為準。從發布記錄看，v0.7.2、v0.7.1 與 v0.7.0 在三天內接連發布，顯示維護者正積極修正問題或增加功能。README 提到 PyPI 上有同名 npm 套件，這是實際的採用陷阱，安裝時必須確認來源是 PyPI。伺服器透過 stdio 執行，升級方式就是更新 PyPI 套件，但用戶端設定中的命令不會變，這算是低維護成本。不過，MCP 協定本身仍在演進，用戶端的設定格式差異（mcpServers 對 servers 對 TOML）代表每次更換用戶端都可能需要調整設定，這是生態系層面的維護成本，不是這個專案能單獨解決的。
編輯結論
適合需要讓 Claude、Codex 或 Hermes 代理反覆閱讀單篇論文、逐節消化 LaTeX 並產生引用資料的研究者，尤其是重視論文檔案留在本機、不願每次搜尋都依賴外部服務的人。不適合把 arxiv-mcp-server 當成搜尋引擎或引用圖譜工具的使用者，因為 README 明說這些功能仍呼叫外部服務，伺服器本身不是搜尋包裝。採用前應先確認兩件事：你的 MCP 用戶端接受哪種設定檔格式，因為不同用戶端可能用 mcpServers、servers 或 TOML；以及你是否有 uv 提供 uvx，這是預設安裝命令的依賴。另外務必從 PyPI 安裝，不要用 npm 或 npx，因為同名 npm 套件與本專案無關。
社群筆記