arxiv-mcp-server: A Local MCP Server That Reads LaTeX Sections, Not Abstracts
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.
At a glance
- What is it?
- arxiv-mcp-server is a Python MCP server that keeps papers on disk and reads original LaTeX section by section, with BibTeX export from arXiv metadata. It is a tool for agent-driven literature work, not another search wrapper.
- Who is it for?
- Adopt arxiv-mcp-server if your workflow is agent-driven and paper-centric: you want to read author-submitted LaTeX one section at a time, keep a local paper store, and avoid building a search pipeline. Skip it if you need a general-purpose arXiv search tool or if your client cannot run uvx over stdio.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 20 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What Problem This Solves and Who It Is For
The project positions itself as a local MCP server for agent literature work. The specific problem is that most arXiv integrations are search wrappers: they query the API, return abstracts, and leave the agent to work from summaries. This server instead focuses on the reading loop. The README states the differentiator is original-LaTeX section reads, BibTeX from arXiv metadata, and topic watches. Papers stay on disk. The intended user is someone running an AI agent inside a client like Claude Code, Codex, or Kiro, who needs to read a paper's full text in its author-submitted form, not a rendered PDF or an abstract. The working loop is explicit: paper ID to outline to one section to citations. That loop is for literature review, citation chasing, and writing support, not for discovery.
Why It Is Not a Search Wrapper
The README makes a deliberate design claim: search, source retrieval, citation graphs, and downloads call external services, but the literature loop stays local. What does that mean in practice? The server runs locally over stdio by default. It reads LaTeX sections from papers that are stored on disk. It exports BibTeX from arXiv metadata, which is authoritative rather than scraped. Topic watches are kept on disk, so the agent can maintain a persistent set of interests without re-querying a remote API every time. The trade-off is clear: this is not a tool for finding papers. It is a tool for working with papers you already have or that the agent has identified through other means. The README's phrasing, 'Search is optional,' suggests that the server may not even include a search tool by default, or that search is a peripheral feature. That is a meaningful boundary for anyone evaluating it.
How the Mechanism Works: LaTeX Sections and BibTeX
The core mechanism is reading original LaTeX, not a parsed or rendered version. The README says 'read author-submitted LaTeX one section at a time.' That implies the server fetches the LaTeX source for a given arXiv paper ID, parses the section structure, and exposes tools that let the agent request a single section, such as the introduction or the methodology. This is different from tools that read the full PDF or extract text, because LaTeX preserves the author's own sectioning, equations, and citations. The other key mechanism is BibTeX export from arXiv metadata. The README emphasizes 'authoritative arXiv metadata,' meaning the BibTeX entries are generated from the arXiv API's structured data, not from a heuristic parse of the PDF. Topic watches are stored on disk, so the agent can maintain a persistent set of interests without re-querying a remote API every time. The working loop is paper ID to outline to one section to citations. That loop implies the server exposes tools for fetching an outline, reading a section, and retrieving citations, all tied to a paper ID.
Getting It Running: Commands and Configuration
Installation is straightforward if you have uv installed. The default command is `uvx arxiv-mcp-server`. The README notes that command-based integrations need uv, which provides uvx, and that no repository clone or Python environment setup is required. For clients that accept the mcpServers JSON shape, such as Claude Desktop and Kiro, the configuration is a stdio entry with the command set to uvx and args set to the package name. The default paper directory is `~/.arxiv-mcp-server/papers`. To change it, you append `--storage-path`, followed by an absolute path, to the args array. Per-client recipes are given for Claude Code, Codex, Hermes, VS Code, and Kiro. For Claude Code, the direct MCP install is `claude mcp add --transport stdio --scope user arxiv -- uvx arxiv-mcp-server`. There is also a plugin route that registers the repository as a marketplace and installs a bundled research skill. Codex uses `codex mcp add arxiv -- uvx arxiv-mcp-server`. Hermes uses `hermes mcp add arxiv --command uvx --args arxiv-mcp-server` followed by `hermes mcp test arxiv`. The README also warns that an unrelated npm package uses the same name, so you must not install with npm or npx.
A Genuine Limitation: The Package Name Collision and Client Dependency
The most concrete limitation is the package name collision. The README explicitly warns that an unrelated npm package uses the same name, so installing with npm, pnpm, or npx will get you the wrong software. That is a real failure mode for anyone who habitually reaches for npx. The project is published on PyPI as arxiv-mcp-server version 0.7.2, and the README says to use that exact version. Another limitation is that the server is not a search tool. If your agent needs to discover papers from a broad query, this server is the wrong tool. The README says search is optional, but the emphasis is on reading and citation work. Also, the server depends on external services for search, source retrieval, citation graphs, and downloads, so those features are not local and may be subject to network availability or API rate limits. The documentation does not describe offline behavior for those external calls, so an agent working without network access would be limited to papers already on disk.
Maintenance and Upgrade Cost
The project is under active development, with releases v0.7.0, v0.7.1, and v0.7.2 all in August 2026. The last push was 2026-08-26. The README does not describe a migration or upgrade path. Upgrading likely means reinstalling the PyPI package via uvx, which will pull the latest version when you run the command again. Since the server is invoked via uvx, the upgrade cost is low on the server side: you just restart the client. However, the bundled plugins and Power integrations, such as the Claude Code plugin or the Kiro Power, may need to be updated separately. The README says to verify the direct MCP installation with `claude mcp get arxiv` after install, and to restart Claude Code or run `/reload-plugins` after installing the plugin. That suggests that after an upgrade, you should re-run those verification steps. The storage directory persists across upgrades, so your papers and topic watches should remain intact, but the README does not state this explicitly. The license is Apache-2.0, which permits commercial use and modification, but you should review the license text for any attribution requirements.
Alternative Approaches and What This One Changes
A common alternative is a general MCP server that wraps the arXiv API for search and retrieval, such as a server that returns abstracts and PDF links. Those tools focus on discovery: you ask for papers on a topic, get a list of results, and then fetch the PDF. The difference in approach is that arxiv-mcp-server inverts the priority. Instead of search first, it assumes you have a paper ID and want to read the LaTeX source section by section. Another alternative is to use a tool that reads PDFs directly, but PDF text extraction loses the original LaTeX structure, especially for equations and tables. This server's approach preserves the author's sectioning, which is valuable for agents that need to cite specific claims or understand the flow of a paper. The trade-off is that you need a separate mechanism for finding papers, because this server does not claim to be a search wrapper. If your workflow is 'find papers then read them,' you might need two tools. If your workflow is 'I have a paper ID and want to work through it,' this server is purpose-built.
Editorial conclusion
Adopt arxiv-mcp-server if your workflow is agent-driven and paper-centric: you want to read author-submitted LaTeX one section at a time, keep a local paper store, and avoid building a search pipeline. Skip it if you need a general-purpose arXiv search tool or if your client cannot run uvx over stdio. Before adopting, verify that your MCP client supports the mcpServers JSON shape or the per-client recipes, and confirm that the storage path default (~/.arxiv-mcp-server/papers) is acceptable, since changing it requires editing the client config. Also check the exact PyPI version (0.7.2) to avoid the unrelated npm package with the same name. The project is actively released (v0.7.2 in August 2026) and Apache-2.0 licensed, but the documentation does not describe an upgrade path or migration tooling, so plan to reinstall via uvx and re-verify your client configuration after each update.
Community notes