arxiv-mcp-server 評:LaTeX 原文の章読みと BibTeX をローカルで回す 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 生成、トピック監視に絞っている。採用判断の分かれ目は、検索を外部サービスに任せられるかどうかにある。
- 誰に向いている？
- 論文を読み込む工程をエージェントに任せたいが、PDF のパース結果ではなく著者が投稿した LaTeX を章単位で読み、引用は arXiv メタデータから BibTeX として起こしたい場合に向く。逆に、分野横断の全文検索や引用グラフの探索をこのサーバーだけで完結させたいなら対象外で、そこは README も外部サービスに委ねると明記している。
- 商用利用できる？
- できます。Apache-2.0 は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。最後のコミットは 20 日前です。
- 何の言語で書かれている？
- 主に Python です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
検索ラッパーではないと README が線を引く理由
このサーバーの説明で最初に目に入るのは、機能の列挙ではなく否定形だ。README は「Why this is not a search wrapper」という節を置き、検索、ソース取得、引用グラフ、ダウンロードはそれぞれ外部サービスを呼ぶと書き、ローカルに残るのは文献ループだと定義している。文献ループの中身は3つ。著者が投稿した LaTeX を1章ずつ読むこと、arXiv のメタデータから BibTeX を書き出すこと、トピック監視をディスク上に保持すること。
この線引きは思想というより調達の判断材料になる。検索品質は arXiv API 側の都合で決まり、このサーバーを乗り換えても変わらない。逆に、章単位の読み方や保存先の扱いはこのサーバー固有の実装で、乗り換えると失われる。評価すべき対象がどこにあるかが README の時点で切り分けられている。
もう一つ、README が繰り返すのは「Papers stay on disk」という一点だ。取得した論文はローカルのディレクトリに置かれ、サーバーは stdio で動く。論文本文がベンダーのサーバーに渡る経路を前提にしていない。未公開の草稿や社内限定のプレプリントを扱うチームにとっては、ここが採用の可否を分ける。
paper ID → outline → 1章 → 引用という作業順序
README が示す作業の流れは「paper ID → outline → one section → citations」の4段階で、これは機能一覧ではなくエージェントに渡す手順の設計だ。まず論文 ID を決め、次にアウトラインを得て、そこから章を1つだけ読み、最後に引用を起こす。全文を一度にコンテキストへ流し込むのではなく、読む範囲を章に限定する。
この順序には実務上の意味がある。LaTeX の原文は節ごとに構造がはっきりしているので、アウトラインを先に取れば、エージェントは「どの章を読むべきか」を判断してから本文を取りに行ける。PDF から抽出したテキストを渡す場合、段組みや数式の崩れをモデル側で補正する必要があるが、著者投稿の LaTeX を章単位で読むなら、その補正工程を挟まない。数式や記号の扱いが安定する方向に働く。
ただし、この流れが成立するのは論文が arXiv 上に LaTeX ソース付きで存在する場合に限られる。古い論文や、ソースを公開していない論文では章単位の読みが成立しない。README はこの欠落時のフォールバックについて何も書いていない。ここは導入前に自分の対象分野で確かめるべき空白だ。
uvx 一発で入れる:クライアント別の登録コマンド
既定の導入は uvx arxiv-mcp-server の一行で、リポジトリの clone も Python 環境の準備も要らないと README は書いている。uvx は uv が提供するコマンドなので、コマンドベースの連携を使う場合は uv の導入が前提になる。
mcpServers 形式の JSON を受け取るクライアント、たとえば Claude Desktop や Kiro では次の設定をそのまま貼る。
{"mcpServers": {"arxiv": {"type": "stdio", "command": "uvx", "args": ["arxiv-mcp-server"]}}}
保存先を変えたい場合は args に "--storage-path" と絶対パスを足す。既定は ~/.arxiv-mcp-server/papers で、ここを共有ディスクやプロジェクト配下に移せる。
クライアント別の近道も README に載っている。Claude Code は claude mcp add --transport stdio --scope user arxiv -- uvx arxiv-mcp-server、Codex は codex mcp add arxiv -- uvx arxiv-mcp-server、Hermes は hermes mcp add arxiv --command uvx --args arxiv-mcp-server の後に hermes mcp test arxiv で確認する。Claude Code と Codex にはプラグイン経由の導入も用意され、Claude Code では claude plugin marketplace add blazickjp/arxiv-mcp-server の後に claude plugin install arxiv-mcp-server@arxiv-mcp を実行し、反映には再起動か /reload-plugins が要ると書かれている。macOS 向けには .mcpb 形式のバンドルが v0.7.2 のリリースに添付されている。
注意点が1つ明示されている。PyPI の arxiv-mcp-server と同名の無関係な npm パッケージが存在するため、npm、pnpm、npx arxiv-mcp-server では入れてはいけない。対応パッケージは PyPI の arxiv-mcp-server==0.7.2 だ。
ローカル完結が効かない場面
このサーバーの価値は、外部サービスへの依存を減らすのではなく、依存する範囲を限定するところにある。検索と取得は外部、読みと保存はローカル。この分担は、検索そのものを速くしたい要求には答えない。arXiv 全体を横断する語句検索の品質を上げたいなら、arXiv API 側の制約がそのまま残る。
もう1つの制約は、LaTeX ソースが取れない論文の扱いだ。章単位の読みが看板である以上、ソース非公開の論文ではその利点が消える。README はこの場合の代替経路を説明していないので、導入を検討する側が自分の対象範囲にソース付き論文がどれくらい含まれるかを先に見積もる必要がある。
トピック監視も、README の記述からは通知の送り先や実行間隔まで読み取れない。ディスク上に監視を保持するところまでは書かれているが、それを誰がいつ起動するのかは、クライアント側のエージェントの使い方に委ねられている。定期的な新着通知を期待して入れると、期待が外れる可能性がある。
PaperQA や Semantic Scholar 系との分かれ目
同じ「エージェントに論文を読ませる」目的の道具として、PDF を取り込んでチャンクに分割し、埋め込みと検索で回答を組み立てるタイプがある。PaperQA はその代表で、質問応答の精度を上げるためにインデックス構築と検索の層を持つ。arxiv-mcp-server はその層を持たず、代わりに LaTeX の章構造と arXiv メタデータに寄りかかる。
違いは前処理の重さに出る。インデックス型は取り込み時に埋め込み生成のコストを払い、その分だけ曖昧な質問に強い。章読み型は取り込みをほぼ行わず、どの章を読むかをエージェントが決める。質問が「この論文の評価実験はどう設計されているか」のように章と対応しているなら、後者のほうが工程は短い。逆に「この分野でこの手法はどう扱われてきたか」のような横断的な問いには、インデックス型か、検索を外部サービスに任せる構成のほうが向く。
引用の扱いも分かれる。Semantic Scholar 系の API を直接叩く構成では引用グラフをたどれるが、このサーバーはグラフ探索を外部に委ね、自分は arXiv メタデータからの BibTeX 書き出しを担う。文献レビューの骨格を LaTeX の章立てに沿って組み、参考文献リストを BibTeX として手元に残したいなら、こちらの分担のほうが素直だ。
Apache-2.0 と更新頻度から見る運用コスト
ライセンスは Apache-2.0。特許条項を含む寛容なライセンスで、社内ツールへの組み込みや改変配布の余地がある。ただしこれはライセンス文書そのものの話であり、同梱されるプラグイン定義やクライアント連携の設定ファイルが同じ条件で配布されているかは、リポジトリを確認しないと断定できない。法務判断は各自の責任で行う必要がある。
更新のペースは速い。v0.7.0 が 2026-08-22、v0.7.1 が 08-23、v0.7.2 が 08-24 と、3日で3版が出ている。uvx でバージョンを固定せずに入れると、クライアントを再起動するたびに別の版を拾う可能性がある。再現性を重視するなら uvx arxiv-mcp-server==0.7.2 のようにバージョンを明示するほうが安全だ。
維持コストとして見落としやすいのは、保存先ディレクトリの管理だ。既定の ~/.arxiv-mcp-server/papers はホーム配下にあり、論文が増えればそのまま容量を食う。共有環境で使うなら "--storage-path" でプロジェクト配下や共有ボリュームに逃がし、バックアップや削除の対象に含めておく必要がある。サーバー自体はローカルで動くので、運用の手間はこのディレクトリとクライアント設定の2か所に集約される。
導入前に確かめる3つのこと
最初に確認するのはクライアントの設定形式だ。mcpServers というトップレベルキーを受け取るクライアントなら README の JSON をそのまま使えるが、servers というキーを使うものや TOML 形式、独自の設定画面を持つものもある。README 自身が「consult the client's MCP documentation」と書いており、ここは各クライアントの流儀に従う。
次に、保存先を既定のままにするか決める。共有マシンや複数プロジェクトで使うなら、args に "--storage-path" と絶対パスを足す。逆に個人の端末で試すだけなら既定のままで問題ない。
最後に、導入コマンドが PyPI 側を指しているかを確認する。uvx arxiv-mcp-server あるいは claude mcp add や codex mcp add の形なら正しい。npx arxiv-mcp-server を実行していたら、それは同名の別パッケージだ。導入後の確認コマンドもクライアントごとに用意されていて、Claude Code は claude mcp get arxiv、Codex は codex mcp get arxiv、Hermes は hermes mcp test arxiv で接続を確かめられる。
編集部の結論
論文を読み込む工程をエージェントに任せたいが、PDF のパース結果ではなく著者が投稿した LaTeX を章単位で読み、引用は arXiv メタデータから BibTeX として起こしたい場合に向く。逆に、分野横断の全文検索や引用グラフの探索をこのサーバーだけで完結させたいなら対象外で、そこは README も外部サービスに委ねると明記している。導入前に確認すべきは、クライアントが mcpServers 形式の JSON を受け取るか、args に "--storage-path" を足す必要があるか、そして npm 名の同名パッケージを誤って入れていないかの3点。uvx が解決するのは PyPI の arxiv-mcp-server==0.7.2 であり、npx 経由で入るものは別物だ。
コミュニティノート