Provides tools for searching and retrieving academic papers from arXiv, including paper search with flexible queries, detailed metadata retrieval, advanced query construction, and category browsing.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@arxiv-mcp search for recent papers on 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.
Access the world's largest repository of academic papers through the Model Context Protocol
A streamlined Model Context Protocol server that connects AI assistants to arXiv's vast collection of academic papers. Search, analyze, and download research papers directly from your AI workflow.
Python 3.12+
uv package manager
# Pull and run the Docker image
docker run --rm -it ghcr.io/tejas242/arxiv-mcp:latest
# Or using docker-compose
git clone https://github.com/tejas242/arxiv-mcp.git
cd arxiv-mcp
docker compose up# Clone and setup
git clone https://github.com/tejas242/arxiv-mcp.git
cd arxiv-mcp
uv sync
# Test the server
uv run main.pyRelated MCP server: arXiv Research Assistant MCP Server
Function | Status | Description | Parameters |
| ✅ Working | Search arXiv papers with flexible query syntax |
|
| ✅ Working | Retrieve complete metadata for any arXiv paper |
|
| ✅ Working | Construct complex search queries with multiple fields |
|
| ✅ Working | List all available arXiv subject categories | None |
| ⚠️ Limited | Find papers by specific author (use search_papers instead) |
|
| ⚠️ Limited | Browse papers by category (use search_papers instead) |
|
| 🔧 Needs Fix | Download paper PDFs (redirect handling issue) |
|
search_papers - The primary search function
Supports full arXiv query syntax
Handles keywords, authors, categories, titles
Configurable sorting and pagination
Returns formatted results with abstracts and links
get_paper_details - Detailed paper information
Complete metadata extraction
Author information with affiliations
Category classifications and links
Publication dates and updates
build_advanced_query - Query construction helper
Combines multiple search criteria
Supports title, author, category, and abstract searches
Returns properly formatted query strings
get_arxiv_categories - Category reference
Complete list of arXiv subject categories
Descriptions for each category
Helpful for constructing targeted searches
search_by_author - Use search_papers('au:"Author Name"') instead
search_by_category - Use search_papers('cat:category_code') instead
download_paper_pdf - HTTP redirect handling needs improvement
Currently fails due to HTTPS/HTTP redirect issues
PDFs can be accessed directly via the links provided in search results
For Local Installation:
Add to your Claude Desktop config file:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%/Claude/claude_desktop_config.json
{
"mcpServers": {
"arxiv-mcp": {
"command": "uv",
"args": [
"--directory",
"/absolute/path/to/arxiv-mcp",
"run",
"main.py"
]
}
}
}For Docker Installation:
{
"mcpServers": {
"arxiv-mcp": {
"command": "docker",
"args": [
"run",
"--rm",
"-i",
"ghcr.io/tejas242/arxiv-mcp:latest"
]
}
}
}{
"mcp": {
"servers": {
"arxiv-mcp": {
"command": "uv",
"args": ["--directory", "/path/to/arxiv-mcp", "run", "main.py"]
}
}
}
}# Search for papers about transformers
search_papers("transformer architecture")
# Advanced query with specific fields
search_papers('ti:"attention mechanism" AND cat:cs.LG')
# Author-specific search (recommended approach)
search_papers('au:"Geoffrey Hinton"')
# Category browsing (recommended approach)
search_papers('cat:cs.AI')# 1. Find the famous "Attention" paper
search_papers('ti:"Attention Is All You Need"')
get_paper_details("1706.03762")
# 2. Explore related work
search_papers("transformer neural networks")
# 3. Build complex queries
query = build_advanced_query(
title_keywords="few-shot learning",
author_name="Tom Brown",
category="cs.LG"
)
search_papers(query)Code | Description | Example Topics |
| Artificial Intelligence | Machine learning, neural networks, AI theory |
| Machine Learning | Deep learning, reinforcement learning, statistical learning |
| Computer Vision | Image processing, object detection, visual recognition |
| Computation and Language | NLP, language models, text processing |
| Cryptography and Security | Security protocols, encryption, privacy |
| Machine Learning (Statistics) | Statistical learning theory, Bayesian methods |
| General Physics | Theoretical physics, quantum mechanics |
| Numerical Analysis | Computational mathematics, algorithms |
| Quantitative Biology | Neuroscience, computational biology |
Use get_arxiv_categories() for the complete list of available categories.
Based on comprehensive testing of all functions:
Paper search with keywords, authors, categories: 100% success rate
Paper detail retrieval: Complete metadata extraction working
Query construction: All syntax combinations supported
Category listing: All arXiv categories accessible
Author search: Use search_papers('au:"Author Name"') instead of search_by_author()
Category browsing: Use search_papers('cat:category') instead of search_by_category()
PDF downloads: Redirect handling needs improvement (PDFs accessible via direct links)
arxiv-mcp/
├── src/arxiv_mcp/ # Main package
│ ├── server.py # MCP server implementation
│ ├── arxiv_client.py # arXiv API wrapper
│ ├── models.py # Pydantic data models
│ └── utils.py # Helper functions
├── tests/ # Test suite
├── main.py # Entry point
└── pyproject.toml # Project configuv run pytest tests/ -v# Enable detailed logging
PYTHONPATH=src uv run python -c "
import logging
logging.basicConfig(level=logging.DEBUG)
from arxiv_mcp.server import main
main()
"✅ Verify absolute paths in MCP config
✅ Test server runs: uv run main.py
✅ Restart Claude Desktop after config changes
✅ Use arXiv query syntax (see examples above)
✅ Check category names: get_arxiv_categories()
✅ Try broader search terms
✅ Use search_papers() instead of specific search functions
✅ Access PDFs via links in search results
✅ Check internet connection
✅ Verify arXiv ID format (e.g., "1706.03762")
Made with ⚡ by screenager
Build an advanced search query using multiple fields.
Args:
title_keywords: Keywords to search in paper titles
author_name: Author name to search for
abstract_keywords: Keywords to search in abstracts
category: arXiv category to filter by
all_fields: Keywords to search across all fields
Returns:
The constructed query string that can be used with search_papers
| Name | Required | Description | Default |
|---|---|---|---|
| title_keywords | No | ||
| author_name | No | ||
| abstract_keywords | No | ||
| category | No | ||
| all_fields | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It does not mention whether the tool is read-only, safe, or idempotent. While the tool is clearly a query builder with no side effects, the lack of explicit behavioral information is a gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a well-structured docstring with Args and Returns sections. Every sentence provides necessary information: purpose, parameter descriptions, and return value. There is no redundant or extraneous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters but no output schema, the description adequately covers all parameters and the return type. It explains the tool's purpose (building a query) and what the output is (a string for search_papers). For a query-building tool, this is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, meaning the schema provides no parameter meanings. The description compensates by listing each parameter (title_keywords, author_name, etc.) with concise explanations like 'Keywords to search in paper titles'. This adds significant meaning beyond the schema's bare type information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the function is to build an advanced search query using multiple fields, and specifies the return value as a query string for use with search_papers. This provides a specific verb and resource, and distinguishes it from sibling tools that perform searches directly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when constructing complex queries with multiple fields, and mentions the output can be used with search_papers. However, it does not provide explicit guidance on when to use this tool versus alternatives like direct search_papers calls, nor does it mention exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Download the PDF of an arXiv paper.
Args:
arxiv_id: The arXiv identifier
save_path: Optional path to save the PDF (if not provided, saves to temp directory)
Returns:
Path to the downloaded PDF file
| Name | Required | Description | Default |
|---|---|---|---|
| arxiv_id | Yes | ||
| save_path | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses the download behavior and optional save path, but lacks details on error handling, network requirements, or file overwrite behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the core purpose. Every sentence adds value; no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-parameter tool, the description covers the main functionality and return value. It could be more complete by mentioning error behavior for invalid IDs, but overall it is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description adds essential meaning: 'arxiv_id' is the identifier, and 'save_path' is optional with a default behavior (temp directory). This compensates well for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Download') and resource ('PDF of an arXiv paper'), providing a specific verb and resource. It distinguishes from sibling tools which are all query/search operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The description does not mention conditions for use, prerequisites, or cases where other tools should be preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a list of available arXiv subject categories.
Returns:
List of arXiv categories with descriptions
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 the return (list of categories with descriptions) but does not mention any behavioral traits like data freshness, rate limits, or that it is a read-only operation. For a simple list tool, this is adequate but not highly informative.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences, no redundant information, and front-loaded purpose. Every sentence serves a clear function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, no output schema, and low complexity, the description is sufficient: it states the action and the return value. Could be slightly improved by noting the format of categories, but overall complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters (0 parameters, 100% coverage), so the description does not need to add parameter details. Baseline for no parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool retrieves a list of available arXiv subject categories, using a clear verb-resource structure. It is distinct from sibling tools like search_by_category (which searches papers) and get_paper_details (which gets specific paper info).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as when exploring categories before using search_by_category. No exclusions or context for usage are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific arXiv paper.
Args:
arxiv_id: The arXiv identifier (e.g., "2301.00001" or "cs.AI/0601001")
Returns:
Detailed paper information including abstract, authors, categories, etc.
| Name | Required | Description | Default |
|---|---|---|---|
| arxiv_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as read-only nature, rate limits, or authentication requirements, only mentioning the return fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two effective sentences and a clean docstring format (Args/Returns), with no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description covers key return fields (abstract, authors, categories) and the single parameter, but could list additional fields like DOI or published date.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds value by providing an example format (e.g., '2301.00001') and clarifying it's an arXiv identifier, though it could include more detail on accepted formats.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get detailed information about a specific arXiv paper' with a specific verb and resource, distinguishing it from search or download siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving details after obtaining an arXiv ID, but provides no explicit guidance on when to use this tool versus alternatives like search_papers.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for papers by a specific author.
Args:
author_name: Name of the author to search for
max_results: Maximum number of results to return (1-50)
Returns:
List of papers by the specified author
| Name | Required | Description | Default |
|---|---|---|---|
| author_name | Yes | ||
| max_results | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses the return type (list of papers) but does not mention pagination, sorting, or side effects. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and uses structured Args/Returns format. It is front-loaded with purpose. However, the 'Args' section is slightly redundant with the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple search tool with 2 parameters and no output schema, the description adequately explains input and output. Could add detail on sorting or exact match behavior, but overall sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description adds meaning: 'Name of the author to search for' and 'Maximum number of results to return (1-50)'. It clarifies the range and purpose of max_results, though not fully comprehensive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Search for papers by a specific author.' The verb 'search' and resource 'papers' are specific, and it distinguishes from siblings like 'search_by_category' and 'build_advanced_query'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., 'search_papers'). The description does not mention exclusions or context for choosing this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for recent papers in a specific arXiv category.
Args:
category: arXiv category (e.g., 'cs.AI', 'physics.gen-ph', 'math.AG')
max_results: Maximum number of results to return (1-50)
Returns:
List of recent papers in the specified category
| Name | Required | Description | Default |
|---|---|---|---|
| category | Yes | ||
| max_results | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions 'recent papers' but does not define recency, sorting, pagination, or rate limits. The behavior is minimally described, leaving gaps in understanding.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, using a clear structure with Args and Returns. Every sentence provides necessary information without redundancy. It is appropriately sized and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description could detail the return structure (e.g., title, authors, date). It lacks information on sorting or result freshness. Parameter coverage is good but overall completeness is adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description adds meaning: it specifies the format for category with examples and defines the range for max_results (1-50). This goes beyond the schema's type-only definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Search for recent papers in a specific arXiv category,' providing a specific verb and resource. It distinguishes from sibling tools like search_by_author or search_papers by specifying the category-focused search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly indicates when to use this tool (search by category) and provides context for parameters. While it doesn't explicitly state when not to use it or list alternatives, the sibling tool names imply other use cases, making it clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for academic papers on arXiv.
Args:
query: Search query. Can use arXiv query syntax (e.g., "ti:machine learning", "au:Smith", "cat:cs.AI")
max_results: Maximum number of results to return (1-100)
sort_by: Sort by 'relevance', 'lastUpdatedDate', or 'submittedDate'
sort_order: Sort order 'ascending' or 'descending'
Returns:
Formatted list of papers matching the search criteria
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| max_results | No | ||
| sort_by | No | relevance | |
| sort_order | No | descending |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior fully. It discloses that results are a 'formatted list', but does not mention potential API delays, rate limits, or pagination behavior, which are relevant for an external service call.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (5 lines) with a clear 'Args' and 'Returns' structure. Every sentence adds value, and the purpose is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description's 'Formatted list of papers' is adequate but vague. It mentions query syntax, sorting, and limits, which is sufficient for a search tool, though error handling or empty results could be noted.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% coverage (no descriptions), but the description adds clear meaning for all 4 parameters: query with arXiv syntax examples, max_results range, sort_by and sort_order options. This fully compensates for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Search for academic papers on arXiv' with a specific verb and resource. It distinguishes from sibling tools like search_by_author and search_by_category by omitting field-specific language, making it clear this is a general search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides usage hints for query syntax but does not explicitly guide when to use this tool versus alternatives like search_by_author or build_advanced_query. The agent must infer from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0build_advanced_querydownload_paper_pdfget_arxiv_categoriesget_paper_detailssearch_by_authorsearch_by_categorysearch_papersScored across 7 tools
Most tools have distinct purposes, but search_by_author and search_by_category are subsets of search_papers, which could cause ambiguity. However, they serve as convenient shortcuts and are clearly named.
Naming conventions vary: some use 'search_by_*' while others use 'get_*' or 'download_*'. This mix of verb_noun and verb_preposition_noun patterns is mostly readable but lacks full consistency.
Seven tools is appropriate for an arXiv client, covering search, details, download, and category browsing without being excessive or insufficient.
The tool set covers core arXiv operations: searching, retrieving details, downloading papers, and listing categories. Minor gaps exist, like merging multiple search results, but agents can work around them using the general search tool.
Driflyte MCP server which lets AI assistants query topic-specific knowledge from web and GitHub.
Academic research MCP server for paper search, citation checks, graphs, and deep research.
An MCP server that gives your AI access to the source code and docs of all public github repos
