This MCP server lets MCP clients read and search arXiv papers using their LaTeX source instead of PDFs.
Fetch the full flattened LaTeX source of a paper with get_paper_prompt, recommended for precise math and equations.
Get just a paper’s abstract with get_paper_abstract for quick previews.
List a paper’s section headings with list_paper_sections to navigate long papers.
Fetch a specific section by path or title with get_paper_section.
Search for papers by topic, title, author, category, and submission date with search_papers, returning IDs and metadata for follow-up reading.
Reuse cached LaTeX sources, with configurable caching, TTL, and cache directory via environment variables.
Provides tools for fetching and processing arXiv papers by retrieving their LaTeX source, enabling detailed analysis of mathematical and scientific content.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@arxiv-latex-mcp Explain the first theorem in 2202.00395"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP server that enables Claude Desktop, Claude Code, Cursor, or other MCP clients to directly access and process arXiv papers by fetching the LaTeX source. It uses arxiv-to-prompt under the hood to handle downloading and processing the LaTeX.
Why use the LaTeX source instead of uploading PDFs? Many PDF chat applications often struggle with mathematical content and equation-heavy papers. By utilizing the original LaTeX source code from arXiv papers, the LLM can accurately understand and handle equations and notations. This approach is particularly valuable for fields like computer science, mathematics, and engineering where precise interpretation of mathematical expressions is crucial.
If you are using Claude Desktop, you can utilize Desktop Extensions by double-clicking on the .mcpb file to install.
Download the .mcpb file from here.
The extension needs Python 3.10+ with pip. On first launch, and whenever its dependency requirements or Python runtime change, it downloads wheels into a private cache inside the extension. This requires internet access; subsequent launches reuse that cache. Restart your MCP client after installing an updated extension.
Supported on macOS, Windows, and Linux.
Otherwise, you can run the server directly from PyPI with uvx:
{
"mcpServers": {
"arxiv-latex-mcp": {
"command": "uvx",
"args": ["arxiv-latex-mcp"]
}
}
}You can also install it with pip install arxiv-latex-mcp and run arxiv-latex-mcp, or use:
python -m arxiv_latex_mcpIf you prefer to run from a local checkout, add the following configuration to your config file:
{
"mcpServers": {
"arxiv-latex-mcp": {
"command": "uv",
"args": [
"--directory",
"/ABSOLUTE/PATH/TO/arxiv-latex-mcp",
"run",
"python",
"-m",
"arxiv_latex_mcp"
]
}
}
}You may need to replace the command field with the full path of uv: check this by running which uv (MacOS/Linux) or where uv (Windows).
Restart the application after saving the above.
For Claude Desktop, click on the hammer icon, and you should see the following in the list of "Available MCP tools":
get_paper_prompt — Get the full flattened LaTeX of a paper
get_paper_abstract — Get just the abstract
list_paper_sections — List section headings of a paper
get_paper_section — Get a specific section by its title from list_paper_sections (Section > Subsection for a subsection)
search_papers — Discover papers by topic, title, or author, optionally filtered by category and submission date
Related MCP server: arxiv-mcp
Use search_papers when you do not yet have an arXiv ID. It returns paper IDs,
titles, authors, abstracts, categories, submission dates, and PDF links. Pass a
returned id to get_paper_prompt to read its LaTeX source. If you already have
an ID, call the reading tools directly.
For example, search with {"query": "ti:\"neural networks\"", "categories": ["cs.LG", "stat.ML"], "date_from": "2026-01-01", "max_results": 10, "sort_by": "date"}.
Categories are combined with OR and restrict the query. date_from and date_to
are inclusive submission dates in YYYY-MM-DD format (UTC). Searches return 10
papers by default, up to 50, sorted by relevance or by newest submission date.
Search requests share a three-second throttle; rate-limit errors ask you to wait
before retrying.
Paper sources are kept in arxiv-to-prompt's cache (the same one its CLI uses), so repeated calls on the same paper do not download it again. Unversioned IDs such as 2403.12345 are re-downloaded once their copy is older than 7 days, so revised papers are picked up. Versioned IDs such as 2403.12345v2 never change. If a refresh fails, the cached copy is used. To change this, set environment variables in the server's MCP config ("env": {...}):
Variable | Default | Effect |
|
|
|
|
| Age after which unversioned IDs are re-downloaded |
| arxiv-to-prompt's default | Cache location (default |
Try asking questions about a paper from arXiv, e.g., "Explain the first theorem in 2202.00395"
Get just the abstract of an arXiv paper. Use this for a quick preview when the user hasn't read the paper yet, not when they provide an arXiv ID to discuss a paper.
| Name | Required | Description | Default |
|---|---|---|---|
| arxiv_id | Yes | The arXiv ID of the paper (e.g., '2403.12345') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It implies a safe, read-only operation without side effects. However, it does not disclose behavior on invalid arxiv_ids or mention any API rate limits or authentication, which would be helpful. Still, the purpose is simple and well-communicated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: one stating the core function and one specifying usage context. Every word earns its place; no redundancy or fluff. It is compact and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one required parameter, no output schema, no nested objects), the description fully covers what the agent needs: purpose, usage guidelines, and parameter meaning. It is complete for the given complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (the parameter 'arxiv_id' is described with an example). The tool description adds no additional semantics beyond the schema, hitting the baseline. No further parameter details are necessary for this simple tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states it retrieves 'just the abstract of an arXiv paper', specifying the resource (arXiv paper) and scope (abstract only). It distinguishes from sibling tools like get_paper_section by emphasizing 'just the abstract' and its use case as a quick preview.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear guidance on when to use ('quick preview when the user hasn't read the paper yet') and when not to use ('not when they provide an arXiv ID to discuss a paper'). This contrasts with sibling tools that likely focus on sections or prompts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recommended default: fetch the full LaTeX source of an arXiv paper for precise interpretation of mathematical expressions.
| Name | Required | Description | Default |
|---|---|---|---|
| arxiv_id | Yes | The arXiv ID of the paper (e.g., '2403.12345') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It only mentions 'precise interpretation of mathematical expressions' as a rationale but omits behavioral details like authentication, rate limits, or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with front-loaded recommendation. No wasted words, though it could have a slightly more structured format (e.g., separating action from rationale).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given low complexity (1 param, no output schema), the description covers purpose and context. However, it lacks details on return format (e.g., raw LaTeX text), which would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage (arxiv_id described in schema), the description adds no extra meaning beyond the schema. The parameter is self-explanatory, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches the full LaTeX source of an arXiv paper, using specific verb 'fetch' and resource 'full LaTeX source'. It distinguishes from siblings like get_paper_abstract and get_paper_section by focusing on complete source.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Recommended default' implies a usage context and contrasts with other tools for different needs (abstract, sections). However, it does not explicitly state when not to use it or provide exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a specific section of an arXiv paper by its title. Use when the full paper is too long for context or the user wants to focus on a particular section. Use list_paper_sections first to get the titles.
| Name | Required | Description | Default |
|---|---|---|---|
| arxiv_id | Yes | The arXiv ID of the paper (e.g., '2403.12345') | |
| section_path | Yes | A section title copied verbatim from list_paper_sections (e.g., 'Introduction'), including any LaTeX in it. For a subsection use 'Section > Subsection' with exact titles. Numbers such as '2.1' are not supported. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. It does add a genuine behavioral rationale — retrieving a single section avoids blowing the context window — but says nothing about what actually comes back (text? LaTeX source? formatting) or what happens if the section path does not match. Adequate but with clear gaps for an unannotated read tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, no filler, with the purpose front-loaded and the prerequisite placed last where it is most actionable. Every sentence contributes either scope, a trigger condition, or a dependency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter read tool with full schema coverage and no output schema, the description covers purpose, triggers, and the required prerequisite workflow. The main omission is any indication of the returned content's form, which an agent would need given there is no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters, including the verbatim-title and 'Section > Subsection' conventions, are already fully documented in the schema. The description adds only the ordering hint for section_path via the list_paper_sections reference, which is a marginal gain over baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: 'Get a specific section of an arXiv paper.' The scope (one section, not the whole paper) is explicit and clearly distinguishable from siblings like list_paper_sections and get_paper_abstract. The only soft spot is 'by its title,' which is immediately disambiguated as the section title rather than the paper title.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives two concrete trigger conditions (paper too long for context, user wants a particular section) and an explicit prerequisite: 'Use list_paper_sections first.' It does not state when not to use it (e.g., for an overview, use get_paper_abstract), so the exclusion side of the guidance is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List section headings of an arXiv paper. Useful when the full paper is too long for context and you need to identify which sections to fetch individually. Returns the top-level section titles; pass one verbatim to get_paper_section.
| Name | Required | Description | Default |
|---|---|---|---|
| arxiv_id | Yes | The arXiv ID of the paper (e.g., '2403.12345') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and discloses two important traits: the result is scoped to top-level titles only (not subsections), and returned titles must be passed verbatim downstream. It does not cover failure behavior, e.g. papers whose full text is unavailable, which is the remaining gap for a zero-annotation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, each earning its place: purpose first, the context-saving rationale second, the handoff to get_paper_section third. Front-loaded with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read tool with no output schema, the description supplies the return shape (top-level section titles) and the downstream usage contract, which is everything an agent needs to invoke it and act on the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and there is a single parameter, so the schema already explains arxiv_id with an example format. The description's "pass one verbatim" refers to returned section titles rather than the input parameter, so it adds no extra meaning to arxiv_id beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ("List section headings of an arXiv paper") and immediately distinguishes itself from the sibling that fetches content, get_paper_section. An agent can tell it apart from search_papers, get_paper_abstract, and get_paper_prompt without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit trigger condition ("when the full paper is too long for context") and names the follow-up alternative ("pass one verbatim to get_paper_section"). The when-to-use and what-to-do-next are both spelled out rather than inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Discover arXiv papers by topic, author, or title. Use quoted phrases for exact matches, ti:"title phrase", au:"author name", or abs:keyword. Combine terms with AND, OR, or ANDNOT. Optional categories such as cs.AI, cs.LG, stat.ML, and quant-ph are ORed together and restrict the query. Dates are inclusive submission dates in YYYY-MM-DD format (UTC). Pass a returned id to get_paper_prompt to read the LaTeX source. Requests are throttled; on rate-limit errors, wait 60s before retrying.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Topic, title, author, or arXiv search expression. | |
| date_to | No | Inclusive end date (YYYY-MM-DD). | |
| sort_by | No | relevance | |
| date_from | No | Inclusive start date (YYYY-MM-DD). | |
| categories | No | Categories to include, e.g. ['cs.LG', 'stat.ML']. | |
| max_results | No | Maximum number of papers to return. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the readOnlyHint/openWorldHint annotations: it discloses rate limiting and a concrete 60s backoff, states dates are inclusive submission dates in UTC, and explains that categories are ORed and restrict rather than broaden the result set — all operationally important behaviors not in the annotations or schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose and then packed with high-value syntax, but several sentences are long run-ons (the categories sentence and the date sentence) and the syntax rules could be itemized for faster scanning rather than buried in prose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only search tool with no output schema, this covers query grammar, filtering, dates, throttling, and next-step routing well. The remaining gap is that it never indicates what a result record contains (id, title, authors, abstract) beyond implying ids exist, and sort_by behavior is unaddressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 83% schema coverage the baseline is 3, but the description substantially exceeds it by defining the query grammar (quoted phrases, ti:/au:/abs: prefixes, AND/OR/ANDNOT) and clarifying the semantics of categories as ORed-and-restricting, which the schema only labels 'Categories to include.' Only sort_by is left undiscussed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Discover arXiv papers') and scopes it to topic, author, or title, which cleanly separates it from the sibling retrieval tools (get_paper_abstract, get_paper_section, get_paper_prompt) that operate on an already-known paper.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear trigger conditions (discovery by topic/author/title) and an explicit hand-off: 'Pass a returned id to get_paper_prompt to read the LaTeX source.' It does not, however, state when-not to use it or contrast against the other siblings (e.g., 'if you already have an id, use get_paper_abstract instead').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.3.0get_paper_section1 field changedInput schema / properties / section_path / descriptionPrevious value: -"The section path to extract (e.g., '1', '2.1', 'Introduction'). Use list_paper_sections to find available paths."New value: +"A section title copied verbatim from list_paper_sections (e.g., 'Introduction'), including any LaTeX in it. For a subsection use 'Section > Subsection' with exact titles. Numbers such as '2.1' are not supported."search_papersv0.2.2get_paper_abstractget_paper_promptget_paper_sectionlist_paper_sectionsScored across 5 tools
The tools mostly have clearly distinct roles: search, abstract preview, section listing, section retrieval, and full LaTeX source retrieval. The main possible confusion is between get_paper_abstract and get_paper_prompt when deciding whether to preview or read the full source, but the descriptions provide guidance.
All tool names use snake_case with a verb_noun structure, giving a predictable pattern. Minor deviations exist: get_paper_prompt is less descriptive of its actual behavior (fetching LaTeX source), and list_paper_sections uses plural while get_paper_section uses singular.
Five tools is well-scoped for an arXiv paper reading server. Each tool supports a specific step in the discovery-to-source-reading workflow without obvious redundancy.
The surface covers the core workflow: search for papers, preview abstracts, list sections, fetch individual sections, and retrieve the full LaTeX source. Minor gaps include no dedicated metadata retrieval (authors, categories, dates) or direct paper lookup by ID outside these paths, but agents can work around this.
arXiv MCP — preprint server search (free, no auth)
Academic research MCP server for paper search, citation checks, graphs, and deep research.
Driflyte MCP server which lets AI assistants query topic-specific knowledge from web and GitHub.
