Which integrations are available for this server?

Allows searching and fetching scientific papers from arXiv, enabling users to query papers by category, date, and title, and retrieve full abstracts for specific research papers.

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 Find the latest papers about large language models in cs.CL" 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 lingqukan

Overview Schema Source Related Servers Discussions Admin

Python

Hybrid

arXiv MCP Server

An MCP (Model Context Protocol) server that lets LLMs like Claude search and fetch arXiv papers directly.

中文文档

Features

Fetch recent papers from any arXiv category and store them locally
Query papers with flexible filtering by date, category, title, and entry ID
Retrieve full abstracts on demand for papers of interest
Clean up old papers from the local database
Database statistics by publication date and category

Tools

Tool	Parameters	Description
`fetch_papers`	`category`, `date=None`, `num_days=3`, `max_results=100`	Fetch recent papers from arXiv API and store in local database
`count_papers_on_date`	`category`, `date`	Count how many papers were published in a category on a specific date
`query_papers`	`date=None`, `categories=None`, `title=None`, `entry_ids=None`, `fields=None`, `max_results=500`	Query local database with flexible filtering and field selection
`cleanup_papers`	`before_date=None`, `date=None`, `categories=None`	Delete papers by date and/or category
`get_stats`	—	Paper counts by publication date and top categories

Design principle: fetch_papers and query_papers return only titles and metadata by default to save context. Use query_papers(fields=["abstract"]) when you need abstracts for specific papers.

Installation

Claude Code (recommended)

Add to your ~/.claude.json under mcpServers:

{
  "mcpServers": {
    "arxiv": {
      "command": "uvx",
      "args": ["arxiv-today-mcp"],
      "type": "stdio"
    }
  }
}

Claude Desktop

Add to your claude_desktop_config.json:

{
  "mcpServers": {
    "arxiv": {
      "command": "uvx",
      "args": ["arxiv-today-mcp"]
    }
  }
}

Usage Example

Browse today's papers: Ask Claude "What's new in cs.AI today?" — Claude will call fetch_papers then query_papers, returning titles grouped by topic.
Get details: "Tell me more about papers 2 and 5" — Claude will call query_papers with those entry IDs and fields=["abstract"] to summarize the abstracts.

Configuration

The database path can be overridden with an environment variable:

{
  "mcpServers": {
    "arxiv": {
      "command": "uvx",
      "args": ["arxiv-today-mcp"],
      "env": {
        "ARXIV_MCP_DB_PATH": "/your/custom/path/papers.db"
      }
    }
  }
}

Requirements

Python >= 3.10
uv or uvx

Available Tools

5 tools

cleanup_papersA

Delete papers from the local database by date and/or category.

At least one filter must be provided to prevent accidental full deletion.
Filters are combined with AND logic.

Args:
    before_date: Delete papers published before this date (exclusive), e.g. "2026-03-01"
    date: Delete papers published on this specific date, e.g. "2026-03-18"
    categories: Delete only papers in these categories (OR logic), e.g. ["cs.AI", "cs.LG"]

ParametersJSON Schema

Name	Required	Description	Default
`before_date`	No
`date`	No
`categories`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.4/5.0

Behavior4/5

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

No annotations provided, so description carries full burden. Discloses: destructive nature, safety guardrails (requires ≥1 filter), AND logic between filter types, OR logic within categories, and exclusive date boundary. Could further clarify permanence/irreversibility of deletion.

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?

Well-structured with safety constraint front-loaded. Main clause establishes operation, followed by constraint, logic explanation, and Args section with examples. Slightly verbose Args section necessary given zero schema coverage.

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?

Appropriate for complexity: covers safety critical for destructive tool, explains parameter interactions (AND/OR), and output schema exists so return values need no description. Missing explicit note that deletion is permanent/irreversible.

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?

Schema has 0% description coverage (only titles). Description fully compensates by providing semantic meaning, format examples ('2026-03-01'), and logic constraints (exclusive, specific, OR logic) for all 3 parameters.

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?

Specific verb 'Delete' + resource 'papers' + scope 'local database' + mechanism 'by date and/or category'. Implicitly distinguishes from read-only siblings (fetch_papers, query_papers, count_papers) through explicit destructive language.

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?

Excellent safety constraint: 'At least one filter must be provided to prevent accidental full deletion.' Explains filter logic (AND between fields). Missing explicit reference to sibling query_papers for previewing deletions, but includes critical guardrails.

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

count_papers_on_dateA

Count how many papers were published in an arXiv category on a specific date.

Use this before fetch_papers to check the volume of papers for a given day,
so you can decide how many to fetch with fetch_papers(max_results=N).

Args:
    category: arXiv category (e.g. "cs.AI", "cs.CL", "stat.ML")
    date: Date in YYYY-MM-DD format (e.g. "2026-03-18")

ParametersJSON Schema

Name	Required	Description	Default
`category`	Yes
`date`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.8/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. It implies this is a safe read operation (counting) and clarifies its role in the workflow chain. However, it doesn't explicitly state error conditions, rate limits, or the exact return type (though output schema exists to cover the latter).

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?

Front-loaded with purpose statement, followed by usage context, then structured Args documentation. Every sentence earns its place; no tautology or repetition of the tool name. Appropriate length for the complexity.

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

Completeness5/5

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

Given 2 simple flat parameters and the existence of an output schema (mentioned in context signals), the description is complete. It covers purpose, usage sequencing, and parameter semantics without gaps.

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?

Critical compensation for 0% schema description coverage. The Args section adds essential semantics: category includes valid arXiv examples (cs.AI, cs.CL, stat.ML) and date specifies YYYY-MM-DD format with a clear example—information completely absent from the raw schema.

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 opens with a specific verb (Count) + resource (papers) + precise scope scope (arXiv category on specific date). It clearly distinguishes from sibling fetch_papers by emphasizing this only returns a count, not the papers themselves.

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

Usage Guidelines5/5

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

Explicitly prescribes when to use ('before fetch_papers') and why ('to check the volume... so you can decide how many to fetch'). Names the sibling alternative directly and establishes the workflow dependency clearly.

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

fetch_papersA

Fetch recent papers from arXiv API and store them in the local database.

Returns only fetched paper titles (not abstracts) to save context.
Use query_papers(entry_ids=[...], fields=["abstract"]) to retrieve abstracts for specific papers.

Args:
    category: arXiv category (e.g. "cs.AI", "cs.CL", "stat.ML")
    date: Fetch papers published on a specific date in YYYY-MM-DD format.
          When provided, takes priority over num_days.
    num_days: Number of days to look back (default: 3). Ignored when date is set.
    max_results: Maximum number of papers to fetch (default: 100)

ParametersJSON Schema

Name	Required	Description	Default
`category`	Yes
`date`	No
`num_days`	No
`max_results`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.6/5.0

Behavior4/5

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

With no annotations provided, description carries full burden. It successfully discloses: (1) persistence side-effect ('store them in local database'), (2) limited return format ('Returns only fetched paper titles'), and (3) external API dependency ('arXiv API'). Missing minor details like rate limits or duplicate handling, but covers major 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?

Well-structured with 3 front-loaded prose sentences covering purpose, output, and alternatives, followed by Args section. Given 0% schema coverage, the Args block is necessary and earns its place. Slight verbosity from redundant 'Args:' header but acceptable given constraints.

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?

Appropriate for a 4-parameter tool with output schema: description clarifies the storage mutation and return limitation without needing to replicate output schema details. Workflow guidance covers the gap between fetch_papers and query_papers.

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?

Schema description coverage is 0%, requiring description to compensate completely. The Args section documents all 4 parameters with rich semantics: category includes examples ('cs.AI'), date includes format (YYYY-MM-DD) and priority logic ('takes priority over'), num_days includes default (3) and interaction ('Ignored when date is set').

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?

Excellent specificity: verb 'Fetch', resource 'papers from arXiv API', scope 'recent', and critical side-effect 'store them in the local database'. Effectively distinguishes from sibling query_papers by noting this tool stores to database while query_papers retrieves specific fields.

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

Usage Guidelines5/5

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

Explicitly names alternative tool with specific syntax: 'Use query_papers(entry_ids=[...], fields=["abstract"]) to retrieve abstracts'. This provides clear workflow guidance (fetch first, then query) and indicates when to use the sibling instead.

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

get_statsA

Get statistics about papers stored in the local database.

Returns total count, date range, per-date breakdown, and top categories.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.7/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 successfully discloses the output structure (what statistics are returned), but omits critical behavioral traits such as confirming read-only safety, performance characteristics, or caching behavior that would help an agent understand execution impact.

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?

Two well-structured sentences with zero waste. The first sentence front-loads the core purpose, while the second efficiently summarizes the return payload. 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?

Adequately complete for a zero-parameter aggregation tool. Given the existence of an output schema, the description appropriately summarizes rather than duplicates return value specifications. Minor gap: could explicitly confirm this is for aggregate overview vs. individual record inspection.

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?

Tool accepts zero parameters, establishing a baseline of 4. The description appropriately omits parameter discussion as there are no inputs to clarify, matching the empty input schema without contradiction or redundancy.

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?

Provides a specific verb ('Get') and resource ('statistics about papers') with clear scope ('local database'). The enumeration of return values (total count, date range, per-date breakdown, top categories) effectively distinguishes this from siblings like count_papers_on_date and query_papers, though it does not explicitly name those alternatives.

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?

Offers implied usage guidance through the detailed description of return values (e.g., comprehensive stats vs. single-date counts), but lacks explicit 'when-to-use' directives or comparisons against siblings like count_papers_on_date or query_papers.

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

query_papersA

Query papers from the local database with flexible filtering and field selection.

All filter parameters are combined with AND logic. Within categories, OR logic is used.
If no filter parameters are provided, returns the most recent papers up to max_results.

Args:
    date: Filter by publication date in YYYY-MM-DD format (e.g. "2026-03-18")
    categories: Filter by one or more arXiv categories (OR logic), e.g. ["cs.AI", "cs.LG"]
    title: Filter by title keyword (title field only, not abstract; case-insensitive for ASCII)
    entry_ids: Fetch specific papers by their arXiv entry IDs. Typically used alone;
               combining with other filters applies AND logic and may return fewer results
               than expected if the other conditions do not match.
    fields: Fields to return. Valid: entry_id, title, authors, abstract, url, published, updated, categories.
            Defaults to: entry_id, title, authors, published, url
    max_results: Maximum number of results to return (default: 500)

ParametersJSON Schema

Name	Required	Description	Default
`date`	No
`categories`	No
`title`	No
`entry_ids`	No
`fields`	No
`max_results`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.6/5.0

Behavior4/5

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

Excellent disclosure of query semantics: explains default behavior when no filters provided (returns most recent), documents the logical operators used, and details parameter interaction effects. As annotations are absent, this carries the full behavioral burden well, though explicit 'read-only' statement is absent.

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?

Structure is exemplary: single-sentence purpose statement upfront, followed by logic explanation, then organized Args block. No filler text; every line conveys specific constraints or behaviors. Docstring-style formatting is readable and efficient.

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

Completeness5/5

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

Fully complete for a query tool of this complexity. All 6 optional parameters are documented, filter logic is explained, and since an output schema exists (per context signals), return values need not be described in narrative.

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, the Args section compensates perfectly by providing detailed semantics for all 6 parameters: date format with example, category logic with examples, field selection with valid values and defaults, and specific usage notes for entry_ids.

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?

Opens with specific verb ('Query'), resource ('papers'), and scope ('local database'), clearly distinguishing from siblings like 'fetch_papers' (external) and 'count_papers_on_date' (aggregation). The phrase 'flexible filtering and field selection' further clarifies capabilities.

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?

Provides clear behavioral guidance on filter logic (AND between parameters, OR within categories) and warns that 'entry_ids' is typically used alone with caveats about combining filters. Lacks explicit comparison to sibling tools like 'fetch_papers'.

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 updatesv0.3.3Mar 24, 2026
- First observedcleanup_papers
- First observedcount_papers_on_date
- First observedfetch_papers
- First observedget_stats
- First observedquery_papers

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

A4.4/5.0

Scored 2026-04-13 01:31 across 5 tools

Disambiguation5/5

Each tool has a clearly distinct purpose with no overlap: cleanup_papers deletes papers, count_papers_on_date counts papers for a specific date/category, fetch_papers retrieves papers from arXiv API, get_stats provides database statistics, and query_papers queries the local database with flexible filtering. The descriptions clearly differentiate their functions and intended use cases.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern with snake_case: cleanup_papers, count_papers_on_date, fetch_papers, get_stats, query_papers. The naming is predictable and readable throughout the set, with clear action-object relationships.

Tool Count5/5

Five tools is well-scoped for an arXiv server focused on fetching, querying, and managing papers in a local database. Each tool earns its place by covering distinct aspects of the workflow: data acquisition (fetch_papers), querying (query_papers), counting (count_papers_on_date), cleanup (cleanup_papers), and monitoring (get_stats).

Completeness5/5

The tool set provides complete coverage for the arXiv paper management domain: fetch_papers acquires data, query_papers allows flexible retrieval, count_papers_on_date supports planning, cleanup_papers handles deletion, and get_stats offers monitoring. There are no obvious gaps—agents can perform the full lifecycle from fetching to querying to cleanup with appropriate statistics.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

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
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
shoumikdc-arxiv-mcp
ai.smithery
Discover the latest arXiv papers by category and keyword. Control how many results you get to spee…
Search Research & Data 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
lecigarevolant
A
license
A
quality
D
maintenance
Enables interaction with arXiv.org to search scholarly articles, retrieve metadata, download PDFs, and load article content directly into LLM context for analysis.
Updated a year ago (2025-09-27 20:02 UTC)
5
3
MIT
search-papers
Research & Data Search Documentation Access
Saidiibrahim
A
license
Not graded
quality
C
maintenance
Enables agents to search, analyze, and explore arXiv academic papers with advanced multi-field search, author lookup, category browsing, citation extraction, and bibliography export.
Updated a year ago (2025-10-01 08:32 UTC)
26 npm
Apache 2.0
arxiv-query-mcp
Research & Data Search
LWaetzig
A
license
A
quality
C
maintenance
Enables AI assistants to search arXiv papers, retrieve metadata, browse categories, and read paper text.
Updated 4 months ago (2026-05-10 15:20 UTC)
4
MIT