Which integrations are available for this server?

Allows searching arXiv for research papers, downloading papers, parsing PDFs into structured sections, and extracting key findings using client-side LLMs.

How do I use arxiv-analyzer?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@arxiv-analyzer search arXiv for few-shot learning papers" 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.

arxiv-analyzer

by arman1o1

Overview Schema Source Related Servers Discussions Admin

Python

Local

arXiv Research Paper Analyzer MCP Server

An MCP (Model Context Protocol) server that enables LLM agents to search arXiv, download papers, parse PDFs into structured sections, and extract key findings using client-side LLMs. It features persistent local caching and layout-aware PDF extraction to optimize token usage and processing speed.

Architecture

The following diagram illustrates the workflow and architecture of the arXiv Analyzer server:

graph TD
    Agent([LLM Agent]) -->|Call Tool / Read Resource| Server[arXiv Analyzer MCP Server]
    Server -->|Query Meta / Download PDF| ArxivAPI[arXiv API]
    Server -->|Read Cached Files| Cache[Local File Cache]
    Server -->|Parse PDF Layout| MuPDF[PyMuPDF Parser]
    MuPDF -->|Segment Text| Sections[Parsed Sections]
    Server -.->|Request LLM completion| Sampling[Client LLM Sampling]
    Sampling -.->|Return Summary| Server

Related MCP server: arXiv MCP Server

Project Structure

mcp-arxiv-analyzer/
├── .github/workflows/
│   └── ci.yml               # GitHub Actions CI pipeline
├── mcp_arxiv_analyzer/
│   ├── __init__.py
│   ├── arxiv_client.py      # arXiv API integration and downloader
│   ├── cache.py             # File caching layer for PDFs, sections, and summaries
│   ├── llm.py               # Client sampling interfaces and fallback logic
│   ├── pdf_parser.py        # PyMuPDF parser for layout-aware section segmentation
│   └── server.py            # MCP server endpoint and tool handlers
├── tests/                   # Unit and integration test suite
├── pyproject.toml           # Package configuration and dependencies
└── README.md                # Documentation

Tools Exposed

search_arxiv: Search arXiv for research papers matching a query.
download_paper: Download a paper by ID, parse its PDF into layout sections, and cache it.
get_paper_sections: Get cached section names and outlines.
get_section_text: Retrieve the raw text content of a specific section of a paper.
get_paper_context: Retrieve a token-efficient pre-assembled overview context of the paper (Abstract, Intro, Conclusion, Outline, and focus-related sections) for summarization.
extract_key_findings: Generate a structured summary of contributions, methods, experiments, and limitations. Falls back to providing context for client-side summarization if client-side sampling (CreateMessage) is unsupported.

Setup and Installation

Prerequisites

Python 3.10 or higher
uv package manager (recommended) or pip

1. Clone the Repository

git clone https://github.com/arman1o1/mcp-arxiv-analyzer.git
cd mcp-arxiv-analyzer

2. Setup Virtual Environment and Install

Using uv:

uv venv
source .venv/bin/activate  # On Windows: .venv\Scripts\activate
uv pip install -e .

Using standard pip:

python -m venv .venv
source .venv/bin/activate  # On Windows: .venv\Scripts\activate
pip install -e .

Running the Server

To run the MCP server on stdio (the standard protocol for MCP integrations):

python -m mcp_arxiv_analyzer.server

Configuration with MCP Hosts

To configure the server with your MCP host (like Claude Desktop or Antigravity), add the following server configuration to your mcp_config.json:

{
  "mcpServers": {
    "mcp-arxiv-analyzer": {
      "command": "uv",
      "args": [
        "--directory",
        "/absolute/path/to/mcp-arxiv-analyzer",
        "run",
        "python",
        "-m",
        "mcp_arxiv_analyzer.server"
      ]
    }
  }
}

Running Tests

To run the unit and integration tests locally, install development dependencies and run pytest:

pip install -e .[dev]
pytest

Available Tools

6 tools

download_paperA

Download an arXiv paper by ID, parse its PDF into sections, and cache it.

ParametersJSON Schema

Name	Required	Description	Default
`arxiv_id`	Yes	arXiv paper ID (e.g. '2305.10601v1' or '2305.10601')

TDQS

A3.5/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must fully disclose behaviors. It mentions downloading, parsing, and caching, but does not specify the output format, potential errors, or whether caching is persistent. This leaves significant ambiguity.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence that front-loads the core action. Every phrase adds value (download, parse, cache), with no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (one parameter, no output schema, no annotations), the description adequately covers the main function but lacks details on output and side effects. It could mention subsequent access to sections.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% for arxiv_id with a clear description. The tool description adds no additional semantics beyond the schema. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: downloading an arXiv paper by ID, parsing its PDF into sections, and caching it. It distinguishes from sibling tools like search_arxiv (searching) and get_paper_sections (retrieving already parsed sections).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description does not explicitly state when to use this tool versus alternatives, but usage is implied: when you need to obtain parsed sections of a paper. It lacks explicit context or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

extract_key_findingsB

Generate a structured summary of contributions, methods, experiments, and limitations using an LLM.

ParametersJSON Schema

Name	Required	Description	Default
`arxiv_id`	Yes	arXiv paper ID
`focus_area`	No	Optional focus area for the key findings

TDQS

B3.3/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description must fully explain behavior. It mentions using an LLM but does not disclose read-only nature, authentication needs, rate limits, or potential variability in output. This leaves significant gaps.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence that directly conveys the tool's purpose without extraneous words. Every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with 2 parameters and no output schema, the description is adequate but incomplete. It omits details about the output format, potential nondeterminism, and resource implications of using an LLM, which are relevant for an AI agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The tool description adds general context about the summary content but does not enhance parameter understanding beyond what the schema already provides (e.g., 'focus_area' is merely labeled 'Optional focus area').

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Generate' and the resource 'structured summary of contributions, methods, experiments, and limitations', which is distinct from sibling tools that download, retrieve sections, or search papers.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus siblings like 'get_paper_sections' or 'download_paper'. The description lacks context on prerequisites or exclusion criteria.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_paper_contextA

Retrieve a token-efficient pre-assembled overview context of the paper (Abstract, Intro, Conclusion, Outline, and focus-related sections) for summarization.

ParametersJSON Schema

Name	Required	Description	Default
`arxiv_id`	Yes	arXiv paper ID
`focus_area`	No	Optional topic/question to retrieve relevant technical sections for

TDQS

A4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the burden. It discloses the included sections and token-efficiency but omits details like output format, caching, or API behavior. Partial transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence with clear action verb, resource, and purpose. No filler; every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a two-parameter tool without output schema, the description provides sufficient context for an agent to understand the tool's role among siblings. It could mention output format, but the purpose is clear.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema covers 100% of parameters. The description adds value by linking focus_area to 'focus-related sections', clarifying its purpose beyond the schema's 'Optional topic/question'.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool retrieves a pre-assembled overview context for summarization, listing specific sections (Abstract, Intro, Conclusion, Outline, focus-related). This distinguishes it from siblings like get_paper_sections, which likely returns individual sections.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies use for summarization tasks but does not explicitly state when to avoid this tool or mention alternative tools like get_section_text for detailed sections. No exclusions provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_paper_sectionsB

Get the section titles and outline of a cached paper.

ParametersJSON Schema

Name	Required	Description	Default
`arxiv_id`	Yes	arXiv paper ID

TDQS

B3.1/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full responsibility. It states 'cached paper' but does not explain behavior if the paper is not cached (e.g., error, auto-cache). No disclosure of whether the operation is read-only or has side effects. Basic retrieval transparency is missing.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence with no filler. Every word is functional and necessary.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

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 param, no output schema, no nested objects), the description is adequate but leaves questions about the caching requirement and the format of the returned outline. With sibling tools, some usage guidance would improve completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% for the single parameter, which is described as 'arXiv paper ID' in the schema. The description adds no additional meaning beyond the schema. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states 'Get the section titles and outline of a cached paper,' which uses a specific verb and resource. It is clear, though it does not explicitly differentiate from sibling tool 'get_section_text' (which retrieves full section content). The mention of 'cached' adds a subtle scope that may not be obvious.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives like 'get_section_text' or 'get_paper_context'. The description does not mention prerequisites (e.g., paper must be cached) or typical use cases.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_section_textB

Retrieve the raw text content of a specific section of a paper.

ParametersJSON Schema

Name	Required	Description	Default
`arxiv_id`	Yes	arXiv paper ID
`section_name`	Yes	Name of the section (e.g. 'Abstract', 'Introduction', 'Methodology')

TDQS

B3.3/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description should disclose behavior but only states the action. Missing details on handling missing sections, authentication, rate limits, or side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence immediately conveys the action, verb first. No unnecessary words; highly efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool is simple with two parameters, but description lacks output format details beyond 'raw text,' and no error or usage context. Adequate but minimally complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so description adds little beyond schema. It mentions 'raw text content,' but schema already describes both parameters adequately. Baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool retrieves raw text from a specific paper section, distinguishing it from siblings that list sections (get_paper_sections) or extract key findings (extract_key_findings).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives like get_paper_sections for listing sections or download_paper for downloading the full paper. The description omits context for selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_arxivB

Search arXiv for research papers matching a query.

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes	The search query (e.g. 'transformer self attention')
`max_results`	No	Maximum number of results to return (default 5)

TDQS

B3.2/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not mention that the tool is read-only, what fields are searched, or any limitations such as rate limits. The description is too minimal to inform the agent of behavioral traits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, concise sentence that directly states the purpose. There is no fluff, but it could be slightly more informative (e.g., mentioning that it returns metadata).

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simplicity of the tool (2 parameters, no output schema), the description provides basic purpose but lacks details on what is returned and any behavioral context. It is minimally adequate but not complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% description coverage with clear parameter descriptions for 'query' and 'max_results'. The description does not add additional meaning beyond the schema, but the schema itself is adequate, so baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function: searching arXiv for research papers matching a query. It uses a specific verb ('search') and resource ('arXiv'), and it differentiates from sibling tools like download_paper or extract_key_findings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, when-not-to-use, or mention any of the sibling tools for context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

6 tool updatesv0.1.0Jun 17, 2026
- First observeddownload_paper
- First observedextract_key_findings
- First observedget_paper_context
- First observedget_paper_sections
- First observedget_section_text
- First observedsearch_arxiv

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.7/5.0

Scored 2026-06-17 15:25 across 6 tools

Disambiguation5/5

Each tool targets a distinct action: searching, downloading, extracting findings, getting context, listing sections, and retrieving section text. No overlap in functionality.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern (e.g., search_arxiv, download_paper, get_section_text), making them predictable and easy to understand.

Tool Count5/5

With 6 tools, the server covers the core workflow of searching, retrieving, and analyzing arXiv papers without unnecessary bloat or missing essential steps.

Completeness4/5

The tool set covers search, download, and detailed analysis (context, sections, findings). Minor gaps exist (e.g., no direct author list tool), but the provided tools allow agents to accomplish most tasks.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

paper-mcp B
io.github.MCPServings
Search arXiv/Semantic Scholar/OpenAlex + medical evidence (PubMed/Europe PMC) + LaTeX/PDF tools.
Research & Data Open Data
21
arxiv-mcp-server A
io.github.cyanheads
Search arXiv, fetch paper metadata, and read full-text content.
Search Research & Data Open Data
424
sec-corporate-events-mcpOAuth
com.thenextgennexus
Extract papers from ArXiv — titles, abstracts, authors, categories & PDF links. Monitor new AI, phys
Research & Data Open Data AI & Machine Learning
2
morosss-sdfsdf
ai.smithery
Find academic papers across major sources like arXiv, PubMed, bioRxiv, and more. Download PDFs whe…
Research & Data Search Open Data
2

Related MCP Servers

arXiv MCP Server
Search Research & Data Documentation Access
LiamConnell
A
license
A
quality
D
maintenance
Enables searching, downloading, and managing academic papers from arXiv.org through natural language interactions. Provides tools for paper discovery, PDF downloads, and local paper collection management.
Updated a year ago (2025-10-21 00:54 UTC)
4
1
MIT
arXiv MCP Server
Search Research & Data Documentation Access
AnnaSuSu
A
license
A
quality
D
maintenance
Enables LLMs to search, download, and read arXiv papers with automatic PDF text extraction and section filtering. Provides AI assistants direct access to scientific literature with local caching for fast re-access.
Updated 8 months ago (2026-01-04 19:41 UTC)
3
1
MIT
paperstack
Search RAG Systems Research & Data
Aldrin-Joan
A
license
Not graded
quality
D
maintenance
Enables arXiv paper search, PDF download, text extraction, and context chunking for LLM pipelines, along with advanced features like citation graphs and reproducibility scoring.
Updated 6 months ago (2026-03-23 04:28 UTC)
2
MIT
paper-search-mcp
Research & Data Search
xiaoxiaoxiaotao
F
license
A
quality
D
maintenance
Enables agents to search papers across Semantic Scholar and arXiv, read and extract text from arXiv PDFs, align records across sources, and produce structured literature-analysis digests.
Updated 6 months ago (2026-03-23 13:20 UTC)
10
1
-