# arXiv の論文を読むための MCP Tool を作った

## やりたいこと

1. LLM に arXiv に出た論文を紹介してほしい
2. 可能な範囲で内容もディスカッションしたい

## 問題１：論文を見つけてくれない

とりあえず，まずは素朴に LLM に聞いてどうなるかを見てみます（{ ... } に think out loud させています）．


"graphon papers arXiv this week 2025" とか "graphon arXiv August 2025" とかで Web 検索をしてなんとか結果を取得しようと頑張ってくれるのですが，納得できる結果を返してくれません．理由は明確で，Claude Desktop が arXiv を検索しないためです．これでは原理的に新しい論文やアクセス数の多くない論文が見逃されてしまいます．

そこで，まずは arXiv から検索を行う MCP Tool を実装します．

## 解決１：arXiv 検索 MCP Tool の実装

arXiv は[検索用の API](https://info.arxiv.org/help/api/user-manual.html) を公開しているのでそれを素朴に MCP にするだけです．適当に LLM 向けにパラメタを調整して同じクエリを試すと次のようになります．


明らかに改善しました．無理のある Web 検索のかわりに arXiv に対して自然なパラメタで検索をしています．実際 MCP Tool なしの場合に取りこぼしていた論文も２つ見つけてくれています．

## 問題２：論文の中身を見てくれない

さて，ここからが本題です．２つ目の論文について詳細が気になったので聞いてみます．


出力だけを見るとそれっぽく見えるのですが，実際にはかなり問題があります．Failed to fetch ... とあることからわかるように，LLM は本文を取得しようとして失敗したので abstract に LLM の知識を組み合わせてそれっぽく表示しています．

研究者各位はよく知っているように，少なくない論文において abstract に書かれていることと実際に本文で示されていることにはギャップがあります（結果を過剰に良く解釈する，仮定が省略されている，など）．そして LLM は基本的に書いてあることを肯定するので，ギャップを勝手に埋めて論文に書かれていないことや理論的に正しくないことを言い始めます．これではハルシネーション一直線です．

これを防ぐには LLM に実際に論文を読んでもらうしかありません．

## 解決２：arXiv コンテンツ取得 MCP Tool の実装

というわけで，LLM に arXiv の論文本文を読ませるツールを追加します．一番素朴な実装は論文を丸ごと LLM に食わせることですが，実際に試したところあまりうまくいきませんでした．最近の LLM はコンテキストウインドウが広いので論文データ（50kb-100kb）くらいまるごと読めるのですが，これをやってみたら個別の質問に対する返答精度が低下しました．

そこで，人間がやることを真似させます．人間が論文を読むときはだいたいセクションごとに読むはずです．具体的には，まずは論文全体をざっと眺めて大まかなセクション構成を把握する．そして読んで面白そうなセクション（だいたい Introduction -> Conclusion -> Method / Experiment の順）を選択的に読む，とします．これを LLM にもやらせましょう．ツールに２つの機能を持たせます．

1. overview モード．論文のセクション構造を返す（厳密には：セクション名・最初の１パラグラフ・総文字数を返す）
3. section モード．指定したセクションの中身を返す

これを実際に実装して LLM に使わせてみると次のようになりました．


期待通り，最初の Tool Call でセクション構造を取得し，続く Tool Call で詳細が書いてありそうなところを読みにいっています．読んだ後の解説はこんな感じになります．




このように abstract を言い換えただけではない，ちゃんとした詳細な解説を生成してくれるようになります．わたしはこの論文を読んでいるのでわかりますが，これはそれなりに正確な解説です．

また，より詳細が知りたい場合は追加で問い合わせればこんなのにも答えてくれます




## 既存パッケージとの比較

arXiv と会話する有名な MCP ツールに[ArXiv MCP Server](https://github.com/blazickjp/arxiv-mcp-server)がありますが，わたしにとって少なくとも２つ満足できない箇所があります．

1. `search` の日付フィルタの実装がよくないです．これは依存している[arxiv ライブラリ](https://pypi.org/project/arxiv/)の問題です．[arXiv 本体の API](https://info.arxiv.org/help/api/user-manual.html) にはちゃんと日付フィルタが実装されているのですが，arxiv ライブラリはこれを実装していません．そのためクライアントは多めに取得したのち自分でフィルタすることになります．これは論文数が多い分野では取得数が莫大になるか見逃すかのどちらかになります．
2. `read_paper` が論文全体を一括で食わせています．わたしの実験ではこれは精度が不十分です（定義を書かせたり証明を追わせたりすると差が出る）．読むべき場所を指定させるのは LLM 自身に[Context Engineering](https://www.philschmid.de/context-engineering)をさせている + タスクに対する Nudging をしていると思えるので，精読系タスクではわたしはこちらの方針のほうが良いんじゃないかなと思っています．

## まとめ

1. ちゃんとしたツールを用意すると目で見てわかるレベルで性能が向上する．ハルシネーションも減る．
2. 「人間がやること」をツール経由で真似させるのはわりと定石かも

## おまけ：実装例

https://gitlab.com/-/snippets/4884254

この記事の著者が使っている Personal MCP Server にはこれ以外にも複数のツールが入っていて読みづらいので，本記事に関連する部分だけ Claude Code に抜き出してもらいました．

実際のコードと上のコードの差分は

1. MCP Server 自体を Cloudflare Workers (+ Cloudflare Access) で公開することにより安全に複数端末からアクセスできるようにしている
2. arXiv に対するアクセスを自宅ラボの API gateway を経由させることによって arXiv が要求する 1 request per 3 sec のレートリミットを厳守している

です．上のコードは Unlicense で公開しますので，興味のある方は勝手に利用してください．再配布含めて自由です．