Which integrations are available for this server?

Enables searching the arXiv database, retrieving article metadata and details, downloading papers as PDFs, and loading article text into context for analysis by LLMs.

How do I use arXiv MCP Server?

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 MCP Server search for recent papers about large language models" 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 MCP Server

by lecigarevolant

Overview Schema Source Related Servers Discussions Admin

Python

Hybrid

arXiv MCP Server

MCP Compatible Python License

A Model Context Protocol (MCP) server that enables interacting with the arXiv API using natural language.

Features

Retrieve metadata about scholarly articles hosted on arXiv.org
Download articles in PDF format to the local machine
Search arXiv database for a particular query
Retrieve articles and load them into a large language model (LLM) context

Related MCP server: arXiv MCP Server

Tools

get_article_url
- Retrieve the direct PDF URL by title or arXiv ID
  - title (String, optional)
  - arxiv_id (String, optional)
download_article
- Download the article as a PDF
  - title (String, optional)
  - arxiv_id (String, optional)
load_article_to_context
- Load article text into context (partial extraction supported)
  - title (String, optional)
  - arxiv_id (String, optional)
  - start_page (Int, optional, 1-based)
  - end_page (Int, optional, 1-based)
  - max_pages (Int, optional)
  - max_chars (Int, optional)
  - preview (Bool, optional; HEAD check only)
get_details
- Retrieve metadata by title or arXiv ID
  - title (String, optional)
  - arxiv_id (String, optional)
search_arxiv
- Search arXiv and return matching article metadata
  - all_fields (String): General keyword search across all metadata fields
  - title (String): Keyword(s) to search for within the titles of articles
  - author (String): Author name(s) to filter results by
  - abstract (String): Keyword(s) to search for within article abstracts
  - start (Int): Index of the first result to return
  - max_results (Int, default 10, up to 50)

Setup

MacOS

Clone the repository

git clone https://github.com/prashalruchiranga/arxiv-mcp-server.git
cd arxiv-mcp-server

Install uv package manager. For more details on installing, visit the official uv documentation.

# Using Homebrew
brew install uv

# or
curl -LsSf https://astral.sh/uv/install.sh | sh

Create and activate virtual environment.

uv venv --python=python3.13
source .venv/bin/activate

Install development dependencies.

uv sync

Windows

Install uv package manager. For more details on installing, visit the official uv documentation.

# Use irm to download the script and execute it with iex
powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 | iex"

Close and reopen the shell, then clone the repository.

git clone https://github.com/prashalruchiranga/arxiv-mcp-server.git
cd arxiv-mcp-server

Create and activate virtual environment.

uv venv --python=python3.13
source .venv\Scripts\activate

Install development dependencies.

uv sync

Usage with Claude Desktop

To enable this integration, add the server configuration to your claude_desktop_config.json file. Make sure to create the file if it doesn’t exist.

On MacOS: ~/Library/Application Support/Claude/claude_desktop_config.json On Windows: %APPDATA%/Roaming/Claude/claude_desktop_config.json

{
  "mcpServers": {
    "arxiv-server": {
      "command": "uv",
      "args": [
        "--directory",
        "/ABSOLUTE/PATH/TO/PARENT/FOLDER/arxiv-mcp-server/src/arxiv_server",
        "run",
        "server.py"
      ],
      "env": {
        "DOWNLOAD_PATH": "/ABSOLUTE/PATH/TO/DOWNLOADS/FOLDER"
      }
    }
  }
}

You may need to put the full path to the uv executable in the command field. You can get this by running which uv on MacOS or where uv on Windows.

Deployment

Hosted platforms such as Smithery require HTTP transport. Set MCP_TRANSPORT=http; the server will bind to the PORT environment variable provided by the platform. The provided Docker/Smithery config also pins the SSE endpoints to /.well-known/mcp/sse and /.well-known/mcp/messages/ for spec compliance.
Hosted deployments expose Streamable HTTP at /mcp and serve a JSON schema at /.well-known/mcp-config so Smithery can provision per-session settings (currently just an optional downloadPath).
For local stdio integrations, no additional configuration is required—the server defaults to STDIO when PORT is not set.

Example Prompts

Can you get the details of 'Reasoning to Learn from Latent Thoughts' paper?

Get the papers authored or co-authored by Yann Lecun on convolutional neural networks

Download the attention is all you need paper

Can you get the papers by Andrew NG which have 'convolutional neural networks' in title?

Can you display the paper?

List the titles of papers by Yann LeCun. Paginate through the API until there are 30 titles

License

Licensed under MIT. See the LICENSE.

Available Tools

5 tools

download_articleB

Download the article as a PDF file. Resolve by arXiv ID or title.

Args: title: Article title. arxiv_id: arXiv ID.

Returns: Success message or structured error JSON.

ParametersJSON Schema

Name	Required	Description	Default
`title`	No
`arxiv_id`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

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. It mentions the download action and resolution methods, but lacks details on permissions, rate limits, file handling (e.g., where the PDF is saved), or error conditions beyond a generic 'structured error JSON.' For a tool with no annotations, this is insufficient to guide safe and effective use.

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 front-loaded with the core purpose, followed by structured sections for args and returns. It's efficient with no wasted sentences, though the 'Args' and 'Returns' labels are slightly redundant since the schema covers this. Overall, it's well-structured and concise.

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 no annotations, 0% schema coverage, but an output schema exists (implied by 'Returns'), the description is moderately complete. It covers the basic purpose and parameters, but lacks behavioral details and doesn't fully leverage the output schema to explain return values. For a download tool with no annotations, it should provide more context on execution and outcomes.

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 0%, so the description must compensate. It lists the parameters ('title' and 'arxiv_id') and explains they are used for resolution, but doesn't specify format (e.g., arXiv ID pattern), exclusivity, or how conflicts are handled. This adds some meaning beyond the bare schema, but doesn't fully cover the gaps, resulting in a baseline score.

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 clearly states the action ('Download') and resource ('article as a PDF file'), specifying the format. It distinguishes from siblings like 'get_article_url' (which likely returns a URL) and 'load_article_to_context' (which might load content without downloading), but could be more explicit about the distinction. The purpose is specific but not fully differentiated.

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 usage by stating 'Resolve by arXiv ID or title,' suggesting it's for retrieving articles from arXiv. However, it doesn't explicitly say when to use this vs. alternatives like 'search_arxiv' (for finding articles) or 'get_details' (for metadata). No exclusions or clear alternatives are provided, leaving some ambiguity.

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

get_article_urlA

Retrieve the direct PDF URL of an article on arXiv.org by title or arXiv ID.

Args: title: Article title. arxiv_id: arXiv ID (e.g., 1706.03762 or arXiv:1706.03762v7).

Returns: URL that can be used to retrieve the article, or structured error JSON.

ParametersJSON Schema

Name	Required	Description	Default
`title`	No
`arxiv_id`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.2/5.0

Behavior3/5

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

With no annotations provided, the description carries the full burden. It discloses the return behavior ('URL that can be used to retrieve the article, or structured error JSON'), which is helpful, but does not mention rate limits, authentication needs, or other operational traits like response formats or error handling details beyond the basic return statement.

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 front-loaded with the core purpose, followed by structured sections for Args and Returns. Every sentence adds value: the first states the action, the second explains parameters, and the third specifies outputs, with no redundant information.

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?

Given the tool's moderate complexity (2 parameters, no annotations, but with an output schema), the description is mostly complete. It covers purpose, parameters, and return values, but lacks details on behavioral aspects like error conditions or usage prerequisites. The output schema likely handles return structure, so the description's focus on semantics is adequate.

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 description coverage is 0%, so the description must compensate. It adds meaning by explaining that 'title' is the article title and 'arxiv_id' is the arXiv ID with examples (e.g., 1706.03762 or arXiv:1706.03762v7), clarifying usage beyond the schema's basic types. However, it does not detail constraints like format requirements or mutual exclusivity.

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 specific action ('Retrieve'), resource ('direct PDF URL of an article on arXiv.org'), and scope ('by title or arXiv ID'), distinguishing it from siblings like download_article (which downloads content) or get_details (which provides metadata).

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

Usage Guidelines4/5

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

The description implies usage context by specifying 'by title or arXiv ID,' but does not explicitly state when to use this tool versus alternatives like search_arxiv (for broader searches) or load_article_to_context (for loading content). It provides clear input options but lacks explicit exclusions or comparisons.

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

get_detailsA

Retrieve metadata of an article by title or arXiv ID.

Args: title: Article title. arxiv_id: arXiv ID.

Returns: JSON string containing article details or structured error JSON.

ParametersJSON Schema

Name	Required	Description	Default
`title`	No
`arxiv_id`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.7/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 states the tool retrieves metadata and returns JSON or error JSON, but does not disclose critical behavioral traits such as whether it requires authentication, rate limits, what happens if both parameters are null, or how it handles ambiguous inputs. For a read operation with zero annotation coverage, this leaves significant gaps in understanding the tool's behavior.

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 appropriately sized and front-loaded, with the core purpose stated first, followed by structured sections for arguments and returns. Every sentence adds value, but the 'Args' and 'Returns' sections could be integrated more seamlessly into the flow. It avoids redundancy and is efficient overall.

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?

Given the tool's moderate complexity (2 parameters, no annotations, but with an output schema), the description is mostly complete. It explains the purpose, parameters, and return format. The output schema exists, so the description need not detail return values, but it could better address behavioral aspects like error handling or input constraints. It covers the essentials but has minor gaps in context.

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 0%, so the description must compensate. It adds meaning by explaining that 'title' refers to the article title and 'arxiv_id' to the arXiv ID, which clarifies the semantics beyond the schema's type definitions. However, it does not specify format requirements (e.g., arXiv ID pattern), mutual exclusivity, or default behaviors, leaving some ambiguity. With two parameters and low schema coverage, this provides basic but incomplete compensation.

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 with a specific verb ('Retrieve') and resource ('metadata of an article'), and distinguishes it from siblings by specifying it returns metadata rather than downloading files, getting URLs, loading content, or searching. It explicitly mentions retrieval by title or arXiv ID, making the scope unambiguous.

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

Usage Guidelines4/5

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

The description provides clear context for when to use this tool (to retrieve article metadata by title or arXiv ID), but does not explicitly state when not to use it or name alternatives among the sibling tools. It implies usage for metadata retrieval rather than other operations, but lacks explicit exclusions or comparisons.

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

load_article_to_contextA

Load the article text into context. Supports title or arXiv ID resolution and partial extraction.

Args: title: Article title. arxiv_id: arXiv ID. start_page: 1-based start page (inclusive). end_page: 1-based end page (inclusive). max_pages: hard cap on number of pages to extract. max_chars: hard cap on number of characters to extract. preview: if True, only validate availability and return minimal info.

Returns: Article text or structured error JSON.

ParametersJSON Schema

Name	Required	Description	Default
`title`	No
`arxiv_id`	No
`start_page`	No
`end_page`	No
`max_pages`	No
`max_chars`	No
`preview`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.6/5.0

Behavior3/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. It discloses that the tool supports 'partial extraction' via page/character limits and a 'preview' mode for validation, which adds useful behavioral context beyond the schema. However, it doesn't mention error handling (returns 'structured error JSON'), performance characteristics, rate limits, or authentication needs, leaving gaps for a tool with 7 parameters.

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 well-structured with a purpose statement followed by 'Args' and 'Returns' sections, making it easy to parse. It's appropriately sized—every sentence adds value, though the 'Args' section could be more integrated into the flow rather than a separate block. No wasted words.

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?

Given the tool's complexity (7 parameters, no annotations, but with an output schema), the description is mostly complete. It covers parameter semantics thoroughly and mentions the return types ('Article text or structured error JSON'). The output schema likely details the return structure, so the description doesn't need to elaborate further. However, it lacks guidance on tool selection among siblings.

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

Parameters5/5

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

With 0% schema description coverage for 7 parameters, the description compensates fully by explaining each parameter's purpose in the 'Args' section. It clarifies that 'title' and 'arxiv_id' are alternative identifiers, pages are '1-based' and 'inclusive', limits are 'hard caps', and 'preview' validates availability. This adds significant meaning beyond the bare schema.

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 clearly states the tool's purpose: 'Load the article text into context' with support for 'title or arXiv ID resolution and partial extraction'. This specifies the verb (load), resource (article text), and key capabilities. However, it doesn't explicitly differentiate from sibling tools like 'download_article' or 'get_details', which likely have overlapping functionality.

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. With siblings like 'download_article', 'get_article_url', 'get_details', and 'search_arxiv', the agent has no indication of which tool to choose for loading article text versus downloading files, getting URLs, retrieving metadata, or searching. No prerequisites or exclusions are mentioned.

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

search_arxivA

Performs a search query on the arXiv API based on specified parameters and returns matching article metadata. This function allows for flexible querying of the arXiv database. Only parameters that are explicitly provided will be included in the final search query. Results are returned in a JSON-formatted string with article titles as keys and their corresponding arXiv IDs as values.

Args: all_fields: General keyword search across all metadata fields including title, abstract, authors, comments, and categories. title: Keyword(s) to search for within the titles of articles. author: Author name(s) to filter results by. abstract: Keyword(s) to search for within article abstracts. start: Index of the first result to return; used for paginating through search results. Defaults to 0. max_results: Maximum number of results to return (1-50).

Returns: A JSON-formatted string containing article titles and their associated arXiv IDs; otherwise, a structured error JSON string.

ParametersJSON Schema

Name	Required	Description	Default
`all_fields`	No
`title`	No
`author`	No
`abstract`	No
`start`	No
`max_results`	No

TDQS

A3.6/5.0

Behavior3/5

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

With no annotations provided, the description carries the full burden. It discloses that 'only parameters explicitly provided will be included in the search query' and specifies the return format as JSON with titles as keys and arXiv IDs as values. However, it lacks details on rate limits, authentication needs, or error handling beyond a vague mention of 'structured error JSON string.'

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 appropriately sized and front-loaded, starting with the core purpose. The Args and Returns sections are structured but slightly verbose; sentences like 'This function allows for flexible querying' could be trimmed without losing value, keeping it efficient overall.

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 6 parameters, no annotations, and no output schema, the description is moderately complete. It covers parameter semantics and return format but lacks details on behavioral aspects like rate limits or error structures. For a search tool with multiple parameters, it provides a baseline but misses advanced context needed for optimal agent use.

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 description coverage is 0%, so the description must compensate. It effectively explains all 6 parameters: all_fields searches across all metadata, title searches titles, author filters by author, abstract searches abstracts, start is for pagination, and max_results limits results. This adds clear meaning beyond the bare schema, though it could detail format specifics like author name conventions.

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 'performs a search query on the arXiv API' and 'returns matching article metadata,' specifying both the action (search) and resource (arXiv articles). It distinguishes from siblings like download_article and get_details by focusing on search rather than retrieval or downloading.

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 like get_details or load_article_to_context. It mentions 'flexible querying' but offers no explicit when/when-not instructions or comparisons to sibling tools, leaving usage context unclear.

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.

5 tool updatesDec 9, 2025
- First observeddownload_article
- First observedget_article_url
- First observedget_details
- First observedload_article_to_context
- 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.8/5.0

Scored 2026-04-18 08:16 across 5 tools

Disambiguation4/5

Most tools have distinct purposes: search_arxiv finds articles, get_details retrieves metadata, download_article gets PDF files, and load_article_to_context extracts text. However, get_article_url overlaps significantly with download_article since both ultimately provide access to the PDF, creating potential confusion about which to use for PDF retrieval.

Naming Consistency5/5

All tools follow a consistent verb_noun naming pattern with clear, descriptive names. The snake_case convention is applied uniformly across all five tools, making the set predictable and easy to understand.

Tool Count5/5

Five tools is well-scoped for an arXiv server, covering the essential workflows: searching, metadata retrieval, URL fetching, PDF downloading, and text extraction. Each tool serves a clear purpose without redundancy, making the count appropriate for the domain.

Completeness4/5

The tool set covers core arXiv operations effectively: search, metadata retrieval, and content access (via URL, download, or text extraction). A minor gap exists in update or management functions (e.g., saving articles locally or tracking history), but these are not essential for the basic purpose, and agents can work around this limitation.

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
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
adamamer20-paper-search-mcp-openai COAuth
ai.smithery
Search and download academic papers from arXiv, PubMed, bioRxiv, medRxiv, Google Scholar, Semantic…
Search Research & Data Open Data
25215

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 Open Data
Mnehmos
A
license
B
quality
D
maintenance
Enables searching and retrieving academic papers from arXiv by various criteria including title, author, and category, with support for extracting full text content from PDFs.
Updated 8 months ago (2026-01-13 01:39 UTC)
4
MIT
arxiv-search MCP Server
Research & Data Search
win4r
A
license
B
quality
D
maintenance
Enables searching academic papers on arXiv and retrieving detailed information such as title, authors, summary, and PDF link.
Updated a year ago (2025-03-16 23:46 UTC)
1
6
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