Search and retrieve papers from arXiv, including metadata (abstract, authors, categories, DOI, links), browse by category, and fetch paper text.
Click on "Install 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-query-mcp search for papers on reinforcement learning"
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.
An MCP (Model Context Protocol) server that gives AI assistants direct access to arXiv. Search papers, retrieve full metadata, browse categories, and read paper text.
Related MCP server: arXiv MCP Server
Search arXiv — Full query syntax support with title, author, abstract, and category filters
Get paper metadata — Retrieve complete details for any paper by ID (abstract, authors, categories, DOI, links)
Browse by category — List recent papers in specific subject areas (ML, AI, NLP, Computer Vision, etc.)
Read paper text — Fetch HTML-rendered paper content or fallback to abstracts with links
Flexible formatting — Response support for both markdown (human-readable) and JSON (programmatic)
Pagination — Handle large result sets with configurable limits and offsets
Python 3.11 or later
Dependencies mcp[cli]>=1.0.0, httpx>=0.27.0, pydantic>=2.0.0 (see pyproject.toml) (project uses poetry for dependency management)
pip install arxiv-query-mcpgit clone https://github.com/LWaetzig/google-scholar-mcp.git
cd google-scholar-mcp
pip install -e .Detailed documentation about single tools can be found here
Add the server to your Claude Desktop configuration:
Platform | Path |
macOS |
|
Windows |
|
Add the arxiv entry under mcpServers, replacing the path with the absolute path to your clone:
{
"mcpServers": {
"arxiv": {
"command": "python",
"args": ["-m", "arxiv-query-mcp"]
}
}
}Restart Claude Desktop. You should see the arxiv tools available in the tool picker.
Any MCP client (e.g., Cline, Continue, or custom tools) can use this server. Configure the connection to:
Command: python -m arxiv-query-mcp.server
Transport: stdioContributions are welcome! Please:
Fork the repository
Create a feature branch (git checkout -b feature/your-feature)
Commit your changes with clear messages
Push to your fork
Open a pull request
For issues, questions, or feature requests, please open an issue on GitHub.
Fetch the readable text content of an arXiv paper.
First tries the HTML version of the paper (available for most papers submitted after ~2023 with LaTeX source). Falls back to returning the full abstract and metadata if the HTML version is unavailable.
Use arxiv_get_paper first to find the paper ID, then call this tool to read the paper's content.
Args: params (FetchPaperTextInput): - paper_id (str): arXiv paper ID, e.g. '2303.08774'
Returns: str: Extracted paper text (up to 10,000 characters) or full abstract with links when HTML is unavailable.
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the fallback mechanism (HTML vs abstract) and character limit, but omits details like error handling, rate limits, or authentication. With no annotations, the description carries full burden and provides moderate transparency.
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 five sentences, each serving a purpose: purpose, fallback, usage, parameter, return. No fluff.
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 tool with one required parameter and clear output, the description is largely complete. However, it fails to mention the response_format parameter, which is documented in the schema but not in the description.
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 description adds value for the paper_id parameter with an example and relationship to arxiv_get_paper. However, it omits the response_format parameter, which has a default and enum. Schema coverage is 0%, so the description partially compensates.
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 it fetches readable text content of an arXiv paper, and explicitly distinguishes from siblings by advising to use arxiv_get_paper first to find the ID. This provides a specific verb and resource with clear differentiation.
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 gives a clear workflow: use arxiv_get_paper to get the ID, then call this tool. It also explains fallback behavior. However, it does not explicitly state when not to use this tool or mention any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve full metadata for a specific arXiv paper by its ID.
Returns complete information: title, all authors, full abstract, categories, dates, journal reference, DOI, and direct links to abstract, PDF, and HTML.
Args: params (GetPaperInput): - paper_id (str): arXiv ID, e.g. '2303.08774', '1706.03762v2', or old-style 'hep-th/9901001' - response_format (str): markdown | json
Returns: str: Full paper metadata.
JSON schema when response_format='json':
{ "id", "title", "authors", "abstract", "published", "updated",
"primary_category", "categories", "abstract_url", "pdf_url",
"html_url", "comment", "journal_ref", "doi" }Examples: - Attention Is All You Need: paper_id='1706.03762' - GPT-4 technical report: paper_id='2303.08774' - AlphaFold: paper_id='2108.10991'
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully details the return fields (title, authors, abstract, etc.) and response format options. It does not mention rate limits or side effects, but as a read operation, transparency is adequate.
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 well-structured: summary line, bullet-like field list, clear args section, return description, and examples. Front-loaded with purpose, no redundant sentences.
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 retrieval tool with an output schema (implied from JSON fields), the description covers inputs, outputs, and examples completely. No gaps remain.
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 description adds significant value beyond the schema: provides paper_id format examples (including old-style IDs), lists both response_format options, and gives concrete usage examples. Schema descriptions are also present but description enhances understanding.
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 verb 'Retrieve' and the resource 'full metadata for a specific arXiv paper by its ID.' It distinguishes from siblings like arxiv_search (search) and arxiv_fetch_paper_text (full text).
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 metadata by ID, with examples. It does not explicitly state when not to use it or specify alternatives, but the sibling tool names provide context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List recent papers in a specific arXiv subject category.
Retrieves papers filtered to one category, sorted by submission date by default. Useful for monitoring a research area's latest preprints.
Args: params (ListByCategoryInput): - category (str): arXiv category code, e.g. 'cs.LG', 'math.CO' - max_results (int): Results per page (1 - 50, default 20) - start (int): Pagination offset - sort_by (str): relevance | lastUpdatedDate | submittedDate - sort_order (str): descending | ascending - response_format (str): markdown | json
Returns: str: Paginated list of papers in the category.
Common category codes: cs.LG — Machine Learning cs.AI — Artificial Intelligence cs.CL — Computation & Language cs.CV — Computer Vision cs.CR — Cryptography cs.RO — Robotics cs.NE — Neural & Evolutionary math.CO — Combinatorics math.ST — Statistics Theory physics.quant-ph — Quantum Physics stat.ML — Statistics / ML econ.GN — General Economics q-bio.NC — Neurons & Cognition
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries the burden. It explains default sorting by submission date, parameter effects, and output format (paginated list). Does not mention rate limits or auth, but given the read-only nature, this is acceptable.
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?
Description is well-structured with Args, Returns, and a categorized list of common category codes. Every sentence adds value, and critical information 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 high schema coverage, presence of an output schema, and modest complexity, the description fully addresses the tool's functionality. Includes common category codes for easy reference.
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 descriptions already cover all parameters (100% coverage), so the description adds marginal value beyond the schema. The listing of common category codes is helpful but not essential for understanding parameters.
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?
States specific verb 'List' and resource 'papers in a specific arXiv subject category'. Clearly distinguishes from sibling tools like arxiv_search (which searches across categories) and arxiv_get_paper (single paper).
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?
Explicitly says 'Useful for monitoring a research area's latest preprints', providing clear context. Does not explicitly exclude when not to use or mention alternatives, but the purpose differentiation from siblings is implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search arXiv for academic papers using full query syntax.
Supports field-specific search and boolean operators. Returns paginated results with title, authors, abstract snippet, and direct links.
Args: params (SearchInput): - query (str): Query string, e.g. 'ti:attention AND cat:cs.LG' - max_results (int): Results per page (1 - 50, default 10) - start (int): Pagination offset (default 0) - sort_by (str): relevance | lastUpdatedDate | submittedDate - sort_order (str): descending | ascending - response_format (str): markdown | json
Returns: str: Paginated list of matching papers with metadata and links.
JSON schema when response_format='json':
{
"total": int,
"count": int,
"start": int,
"has_more": bool,
"next_start": int | null,
"papers": [{ "id", "title", "authors", "abstract", "published",
"updated", "primary_category", "categories",
"abstract_url", "pdf_url", "html_url",
"comment", "journal_ref", "doi" }]
}Examples: - 'ti:large language model AND cat:cs.LG' — LLM papers in ML - 'au:lecun AND cat:cs.CV' — LeCun's vision papers - 'abs:diffusion AND abs:image generation' — diffusion image gen - 'ti:attention is all you need' — search by title phrase
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description fully discloses pagination, result format, and supported operators. 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?
Well-structured with clear sections: purpose, parameters, returns, examples. Slightly verbose but no unnecessary 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?
Covers query syntax, pagination, sort options, response formats, and output schema. Complete given tool complexity.
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 already includes detailed descriptions for all parameters. Description adds value with examples and output JSON schema, but schema already covers semantics well.
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?
Clearly states 'Search arXiv for academic papers' and explains query syntax. Distinguishes from sibling tools like arxiv_fetch_paper_text which focus on fetching full text.
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?
Provides examples and parameter details but does not explicitly state when to use this tool vs siblings. Guidance is implied through examples and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool has a distinct purpose: fetching full text, retrieving metadata, listing papers by category, and performing complex search queries. There is no overlap in functionality.
All tool names follow the pattern 'arxiv_verb_noun' with snake_case, e.g., arxiv_fetch_paper_text, arxiv_get_paper. The naming is uniform and predictable.
Four tools is an appropriate number for an arXiv query server, covering the essential operations without being too many or too few.
The tool set covers the core arXiv querying needs: paper metadata retrieval, full-text access, category browsing, and full-text search. There are no obvious gaps for a read-only client.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Search arXiv, fetch paper metadata, and read full-text content.
Search arXiv/Semantic Scholar/OpenAlex + medical evidence (PubMed/Europe PMC) + LaTeX/PDF tools.
Search arXiv and ACL Anthology, retrieve citations and references, and browse web sources to accel…
Discover the latest arXiv papers by category and keyword. Control how many results you get to spee…
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/LWaetzig/arxiv-query-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server