Skip to main content
Glama
LiamConnell

arXiv MCP Server

by LiamConnell
OverviewSchemaRelated ServersScoreDiscussions
Python
Hybrid

arXiv CLI & MCP Server

A Python toolkit for searching and downloading papers from arXiv.org, with both a command-line interface and a Model Context Protocol (MCP) server for LLM integration.

CLI agents work well with well-documented CLI tools and/or MCP servers. This project provides both options.

Features

  • Search arXiv papers by title, author, abstract, category, and more

  • Download PDFs automatically with local caching

  • MCP Server for integration with LLM assistants (Claude Desktop, etc.)

  • Typed responses using Pydantic models for clean data handling

  • Rate limiting built-in to respect arXiv API guidelines

  • Comprehensive tests with 26 integration tests (no mocking)

Related MCP server: arXiv MCP Server

Installation

Option 1: Install from GitHub (Recommended)

Install directly from the GitHub repository:

# Install the latest version
uv pip install git+https://github.com/LiamConnell/arxiv_for_agents.git

# Or with pip
pip install git+https://github.com/LiamConnell/arxiv_for_agents.git

# Now you can use the arxiv command
arxiv --help

Option 2: Install from Source

Clone the repository and install locally:

# Clone the repository
git clone https://github.com/LiamConnell/arxiv_for_agents.git
cd arxiv_for_agents

# Install in editable mode
uv pip install -e .

# Now you can use the arxiv command
arxiv --help

Option 3: Development Installation

For development with all dependencies:

# Clone and install with dev dependencies
git clone https://github.com/LiamConnell/arxiv_for_agents.git
cd arxiv_for_agents
uv pip install -e ".[dev]"

# Run tests
uv run pytest

Verify Installation

# If installed as package
arxiv --help

# Or if using as module
uv run python -m arxiv --help

Usage

Note: If you installed as a package, use arxiv directly. Otherwise, use uv run python -m arxiv.

Search Papers

Search by title:

# Using installed package
arxiv search "ti:attention is all you need"

# Or using as module
uv run python -m arxiv search "ti:attention is all you need"

Search by author:

arxiv search "au:Hinton" --max-results 20

Search by category:

arxiv search "cat:cs.AI" --max-results 10

Combined search:

arxiv search "ti:transformer AND au:Vaswani"

Get Specific Paper

Get paper metadata and download PDF:

arxiv get 1706.03762

Get metadata only (no download):

arxiv get 1706.03762 --no-download

Force re-download:

arxiv get 1706.03762 --force

Download PDF

Download just the PDF:

arxiv download 1706.03762

List Downloaded PDFs

arxiv list-downloads

JSON Output

Get results as JSON for scripting:

arxiv search "ti:neural" --json
arxiv get 1706.03762 --json --no-download

Search Query Syntax

The arXiv API supports field-specific searches:

  • ti: - Title

  • au: - Author

  • abs: - Abstract

  • cat: - Category (e.g., cs.AI, cs.LG)

  • all: - All fields (default)

You can combine searches with AND, OR, and ANDNOT:

arxiv search "ti:neural AND cat:cs.LG"
arxiv search "au:Hinton OR au:Bengio"

Download Directory

PDFs are downloaded to ./.arxiv by default. Change this with:

arxiv --download-dir ./papers search "ti:transformer"

MCP Server (Model Context Protocol)

The arXiv CLI includes a Model Context Protocol (MCP) server that allows LLM assistants (like Claude Desktop) to search and download arXiv papers programmatically.

Running the MCP Server

# Option 1: Using the script entry point (recommended)
uv run arxiv-mcp

# Option 2: Using the module
uv run python -m arxiv.mcp

The server runs in stdio mode and communicates via JSON-RPC over stdin/stdout.

MCP Tools

The server provides 4 tools for paper discovery and management:

  1. search_papers - Search arXiv with advanced query syntax

    • Supports field prefixes (ti:, au:, abs:, cat:)

    • Boolean operators (AND, OR, ANDNOT)

    • Pagination and sorting options

    • Returns paper metadata including title, authors, abstract, categories

  2. get_paper - Get detailed information about a specific paper

    • Accepts flexible ID formats (1706.03762, arXiv:1706.03762, 1706.03762v1)

    • Optionally downloads PDF automatically

    • Returns complete metadata including DOI, journal references, comments

  3. download_paper - Download PDF for a specific paper

    • Downloads to local .arxiv directory

    • Returns file path and size information

    • Supports force re-download option

  4. list_downloaded_papers - List all locally downloaded PDFs

    • Shows arxiv IDs, file sizes, and paths

    • Useful for managing local paper collection

MCP Resources

The server exposes 2 resources for direct access:

  • paper://{arxiv_id} - Get formatted paper metadata in markdown

  • downloads://list - Get markdown table of all downloaded papers

MCP Prompts

Pre-built prompt templates to guide usage:

  • search_arxiv_prompt - Guide for searching arXiv papers

  • download_paper_prompt - Guide for downloading and managing papers

Claude Desktop Configuration

Add to your Claude Desktop config file (~/Library/Application Support/Claude/claude_desktop_config.json on macOS):

If installed from GitHub/pip:

{
  "mcpServers": {
    "arxiv": {
      "command": "arxiv-mcp"
    }
  }
}

If running from source/development:

{
  "mcpServers": {
    "arxiv": {
      "command": "uv",
      "args": ["run", "arxiv-mcp"],
      "cwd": "/path/to/arxiv_for_agents"
    }
  }
}

Or use --directory to avoid needing cwd:

{
  "mcpServers": {
    "arxiv": {
      "command": "uv",
      "args": ["--directory", "/path/to/arxiv_for_agents", "run", "arxiv-mcp"]
    }
  }
}

MCP Use Cases

Once configured, you can ask Claude to:

  • "Search arXiv for recent papers on transformer architectures"

  • "Find papers by Geoffrey Hinton in the cs.AI category"

  • "Download the 'Attention is All You Need' paper"

  • "Show me papers about neural networks from 2023"

  • "List all the papers I've downloaded"

  • "Get the abstract for arXiv:1706.03762"

The MCP integration allows Claude to autonomously search, retrieve, and manage academic papers from arXiv.

Architecture

Module Structure

arxiv/
├── __init__.py       # Package exports
├── __main__.py       # CLI entry point
├── cli.py            # Click commands
├── models.py         # Pydantic models
├── services.py       # API client service
└── mcp/              # MCP server
    ├── __init__.py   # MCP package exports
    ├── __main__.py   # MCP server entry point
    └── server.py     # FastMCP server with tools, resources, prompts

tests/
└── test_services.py  # Integration tests (26 tests)

Pydantic Models

All API responses are typed using Pydantic:

from arxiv import ArxivService

service = ArxivService()
result = service.search("ti:neural", max_results=5)

# result is typed as ArxivSearchResult
print(f"Total: {result.total_results}")

for entry in result.entries:
    # entry is typed as ArxivEntry
    print(f"{entry.arxiv_id}: {entry.title}")
    print(f"Authors: {', '.join(a.name for a in entry.authors)}")

Key Models

  • ArxivSearchResult: Search results with metadata

    • total_results: Total matching papers

    • entries: List of ArxivEntry objects

  • ArxivEntry: Individual paper

    • arxiv_id: Clean ID (e.g., "1706.03762")

    • title, summary: Paper metadata

    • authors: List of Author objects

    • categories: Subject categories

    • pdf_url: Direct PDF link

    • published, updated: Datetime objects

  • Author: Paper author

    • name: Author name

    • affiliation: Optional affiliation

Testing

Run all 26 integration tests (makes real API calls):

uv run pytest tests/test_services.py -v

Run specific test class:

uv run pytest tests/test_services.py::TestArxivServiceSearch -v

The tests are integration tests that hit the real arXiv API, ensuring the service works with actual data.

API Rate Limiting

The service enforces a 3-second delay between API requests by default (arXiv's recommendation). You can adjust this:

from arxiv import ArxivService

service = ArxivService(rate_limit_delay=5.0)  # 5 seconds

Examples

Python API

from arxiv import ArxivService

# Initialize service
service = ArxivService(download_dir="./papers")

# Search
results = service.search(
    query="ti:attention is all you need",
    max_results=5,
    sort_by="relevance"
)

print(f"Found {results.total_results} papers")
for entry in results.entries:
    print(f"- {entry.title}")

# Get specific paper
entry = service.get("1706.03762", download_pdf=True)
print(f"Downloaded: {entry.title}")

# Just download PDF
pdf_path = service.download_pdf("1706.03762")
print(f"PDF saved to: {pdf_path}")

CLI Examples

# Find recent papers in a category
arxiv search "cat:cs.AI" \
  --max-results 10 \
  --sort-by submittedDate \
  --sort-order descending

# Search and output as JSON for processing
arxiv search "ti:transformer" --json | jq '.entries[].title'

# Batch download multiple papers
for id in 1706.03762 1810.04805 2010.11929; do
  arxiv download $id
done

Development

The codebase follows these principles:

  1. Type safety: Pydantic models for all API responses

  2. Clean architecture: Separation of CLI, service, and models

  3. Real tests: Integration tests with actual API calls (no mocks)

  4. Rate limiting: Respects arXiv API guidelines

  5. Caching: Automatic local caching to avoid re-downloads

arXiv API Reference

License

This is a personal project for interacting with arXiv's public API.

Available Tools

4 tools
download_paperA

Download PDF for a specific arXiv paper.

Downloads the PDF to the local download directory (./.arxiv by default). Returns the local file path upon success.

ParametersJSON Schema
NameRequiredDescriptionDefault
arxiv_idYesarXiv ID to download
forceNoForce download even if file exists

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4/5.0
Behavior4/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behaviors: it downloads to a local directory (./.arxiv by default), handles file existence with a 'force' parameter, and returns a local file path. This covers operational aspects beyond basic functionality, though it lacks details like error handling or network behavior.

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 extremely concise and well-structured: two sentences that front-load the core purpose and follow with essential behavioral details. Every sentence earns its place by adding critical information without redundancy or fluff, making it efficient and easy to parse.

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 largely complete. It explains the download action, local storage, and return value, and the output schema likely covers return details. However, it could benefit from mentioning sibling tool relationships or error cases for full 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 description coverage is 100%, so the schema already documents both parameters ('arxiv_id' and 'force') thoroughly. The description adds minimal value beyond the schema by implying the 'force' parameter's purpose ('even if file exists'), but doesn't provide additional syntax or format details. This meets the baseline for high schema coverage.

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 ('Download PDF') and resource ('for a specific arXiv paper'), distinguishing it from siblings like 'get_paper' (likely metadata retrieval), 'list_downloaded_papers' (listing), and 'search_papers' (searching). It provides a verb+resource+scope combination that leaves no ambiguity about its function.

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 when a PDF download is needed, but it doesn't explicitly state when to use this tool versus alternatives like 'get_paper' (which might retrieve metadata without downloading) or 'search_papers' (for finding papers). There's no guidance on prerequisites, exclusions, or comparative scenarios, leaving usage context inferred rather than clearly defined.

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

get_paperA

Get detailed information about a specific arXiv paper.

Returns complete metadata including abstract, authors, categories, and more. Optionally downloads the PDF to local storage.

Accepts flexible ID formats:

  • 2301.12345

  • arXiv:2301.12345

  • 2301.12345v1 (with version)

ParametersJSON Schema
NameRequiredDescriptionDefault
arxiv_idYesarXiv ID (e.g., '2301.12345', 'arXiv:2301.12345', '2301.12345v1')
download_pdfNoWhether to download the PDF automatically
force_downloadNoForce download even if file exists locally

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4/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 returns complete metadata and optionally downloads the PDF, adding behavioral context beyond the input schema. However, it does not cover aspects like rate limits, authentication needs, error handling, or what 'local storage' entails, leaving gaps in behavioral 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?

The description is front-loaded with the core purpose, followed by return details and parameter guidance. Each sentence adds value: the first states the purpose, the second specifies returns, the third explains optional PDF download, and the fourth clarifies ID formats. There is no wasted text, making it efficient and well-structured.

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 has an output schema (which likely covers return values), no annotations, and high schema coverage, the description is mostly complete. It explains the tool's purpose, return metadata, optional PDF download, and ID formats. However, it could benefit from more behavioral details like error cases or storage implications, but the output schema reduces the need for return value explanation.

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 schema already documents all parameters. The description adds value by explaining flexible ID formats (e.g., '2301.12345', 'arXiv:2301.12345', '2301.12345v1'), which provides semantic context beyond the schema's generic description. However, it does not elaborate on the parameters beyond this, so it meets the baseline for high schema coverage.

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 'Get' and resource 'detailed information about a specific arXiv paper', specifying it returns complete metadata and optionally downloads the PDF. It distinguishes from sibling tools like 'download_paper' (which likely focuses only on downloading), 'list_downloaded_papers' (which lists already downloaded items), and 'search_papers' (which searches multiple papers).

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 for retrieving detailed metadata and optionally downloading a PDF for a specific arXiv paper, but does not explicitly state when to use this tool versus alternatives like 'download_paper' or 'search_papers'. It provides context by mentioning flexible ID formats, which helps in usage, but lacks explicit exclusions or named alternatives.

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

list_downloaded_papersB

List all PDFs that have been downloaded to local storage.

Returns a list of downloaded papers with file information.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

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 the full burden of behavioral disclosure. It states the tool lists PDFs and returns file information, but it doesn't describe key behavioral traits such as whether it's read-only (implied but not explicit), performance characteristics (e.g., speed, pagination), error handling, or any side effects. The description adds minimal context beyond the basic operation.

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 concise and well-structured with two sentences: the first states the purpose, and the second clarifies the return value. It's front-loaded with the main action and avoids unnecessary details. However, it could be slightly more efficient by combining the sentences or omitting redundant phrasing like 'with file information' if the output schema covers it.

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 low complexity (0 parameters, simple list operation) and the presence of an output schema (which likely describes the return values), the description is adequate but has gaps. It covers the basic purpose and return type, but lacks usage guidelines and behavioral context, which are important for a tool with no annotations. It's minimally viable but not fully helpful for an AI agent.

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?

The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add parameter details, which is appropriate here. It gets a baseline of 4 because it doesn't need to compensate for any gaps in schema coverage, and it doesn't introduce confusion about parameters.

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: 'List all PDFs that have been downloaded to local storage.' It specifies the verb ('List'), resource ('PDFs'), and scope ('downloaded to local storage'). However, it doesn't explicitly differentiate from sibling tools like 'get_paper' or 'search_papers', which might also retrieve paper information but with different mechanisms or filters.

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 mentions what it does but doesn't specify use cases, prerequisites, or exclusions. For example, it doesn't clarify if this is for checking local cache versus querying a database, or how it differs from 'get_paper' or 'search_papers'.

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

search_papersA

Search arXiv papers with advanced query syntax.

Query supports field prefixes:

  • ti: - Title search (e.g., "ti:transformer")

  • au: - Author search (e.g., "au:Hinton")

  • abs: - Abstract search (e.g., "abs:neural networks")

  • cat: - Category search (e.g., "cat:cs.AI")

  • all: - All fields (default)

Boolean operators: AND, OR, ANDNOT

Examples:

  • "ti:machine learning" - Search in title

  • "au:Hinton AND cat:cs.AI" - Combined search

  • "abs:neural networks OR abs:deep learning" - OR search

ParametersJSON Schema
NameRequiredDescriptionDefault
queryYesSearch query (supports field prefixes: ti:, au:, abs:, cat:)
max_resultsNoMaximum number of results (1-100)
startNoStarting index for pagination
sort_byNoSort criterion (relevance, lastUpdatedDate, submittedDate)relevance
sort_orderNoSort order (ascending, descending)descending

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A3.8/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 behavioral traits such as supporting advanced query syntax with field prefixes and Boolean operators, and includes examples. However, it doesn't mention rate limits, authentication needs, pagination behavior beyond the 'start' parameter, or what the output looks like (though an output schema exists). The description adds useful context but lacks comprehensive behavioral details.

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 appropriately sized and front-loaded: it starts with the core purpose, then details query syntax with clear bullet points and examples. Every sentence earns its place by providing essential information without redundancy. The structure is logical and easy to follow.

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 complexity (5 parameters, advanced query syntax) and rich schema (100% coverage, output schema exists), the description is mostly complete. It covers the query parameter semantics well and provides examples. Since an output schema exists, it doesn't need to explain return values. However, it could improve by mentioning behavioral aspects like rate limits or error handling, but the presence of an output schema mitigates this gap.

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 schema already documents all parameters thoroughly. The description adds value by explaining the 'query' parameter in detail with field prefixes and Boolean operators, which enhances understanding beyond the schema's basic description. However, it doesn't provide additional semantics for other parameters like 'max_results', 'start', 'sort_by', or 'sort_order'. Baseline 3 is appropriate as the schema does heavy lifting.

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: 'Search arXiv papers with advanced query syntax.' It specifies the resource (arXiv papers) and the action (search) with a distinguishing feature (advanced query syntax). This differentiates it from sibling tools like 'download_paper', 'get_paper', and 'list_downloaded_papers', which have different functions.

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 through examples and query syntax details, suggesting it's for searching arXiv papers with specific field prefixes and Boolean operators. However, it doesn't explicitly state when to use this tool versus alternatives like 'get_paper' (likely for retrieving a specific paper) or 'list_downloaded_papers' (likely for local files). No exclusions or prerequisites are mentioned.

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

Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.8/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose with no overlap: download_paper handles PDF retrieval, get_paper provides metadata, list_downloaded_papers manages local storage, and search_papers performs queries. The descriptions reinforce these boundaries, making tool selection unambiguous for an agent.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern (download_paper, get_paper, list_downloaded_papers, search_papers) with clear, descriptive verbs. There are no deviations in style or convention, making the naming predictable and easy to understand.

Tool Count4/5

With 4 tools, the server is well-scoped for arXiv paper management, covering core operations like search, metadata retrieval, and PDF handling. It feels slightly lean but reasonable, as it includes essential functions without unnecessary bloat, though additional tools for updates or deletions might enhance coverage.

Completeness4/5

The tool set covers key arXiv workflows: searching, getting metadata, downloading, and listing downloaded papers. Minor gaps exist, such as no explicit update or delete operations for local files, but agents can work around this. The surface is largely complete for the domain of paper discovery and access.

Maintenance

ActivityInactive
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • arXiv MCP Server

    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.
    4
    MIT

  • arXiv MCP Server

    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.
    3
    1
    MIT

  • arxiv-search MCP Server

    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.
    1
    6
    MIT

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/LiamConnell/arxiv_for_agents'

If you have feedback or need assistance with the MCP directory API, please join our Discord server