Provides tools for searching and retrieving scientific papers from arXiv by keyword, author, category, or arXiv ID, returning metadata such as title, abstract, authors, dates, DOI, journal reference, and PDF links via the official arXiv API.
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 Research MCP Search arXiv 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.
A read-only, deployable MCP server for scientific literature research.
ChatGPT
↓ Streamable HTTP
arXiv Research MCP
↓ official Atom API
arXiv scientific papersThe server retrieves and normalizes metadata. ChatGPT remains responsible for explaining physics, comparing papers, and working through equations.
Tool | Use |
| General keyword or advanced arXiv search with paging and sorting |
| Complete metadata for one modern or legacy arXiv ID |
| Papers by a named author |
| Category search with optional keywords |
| Newest submissions in a category |
Every tool is marked read-only and returns typed structured data containing the arXiv ID, normalized title and abstract, authors, categories, dates, DOI, journal reference, abstract URL, and PDF URL when available.
Related MCP server: arXiv MCP Server
Requires Python 3.11 or newer.
py -m venv .venv
.venv\Scripts\Activate.ps1
python -m pip install --upgrade pip
python -m pip install -e ".[dev]"
Copy-Item .env.example .envEdit ARXIV_USER_AGENT in .env and replace the example contact with your
email or project URL. arXiv does not require an API key.
Run locally over stdio:
arxiv-mcpRun the remote-compatible transport locally:
arxiv-mcp --transport streamable-http --host 127.0.0.1 --port 8000The endpoints are:
http://127.0.0.1:8000/mcp
http://127.0.0.1:8000/healthFor a manual tool test, start the HTTP server, run the official MCP Inspector,
and connect it to http://127.0.0.1:8000/mcp:
npx @modelcontextprotocol/inspector@latestpytest
ruff check .Tests use mocked HTTP responses and do not consume the arXiv API. GitHub Actions runs the same checks on every push and pull request.
Fixed allowlisted upstream: https://export.arxiv.org/api/query
Three-second global request spacing by default
Bounded retries for timeouts, network failures, HTTP 429, and temporary 5xx responses
Strict result, offset, category, sort, and arXiv-ID validation
Safe XML parsing with external entities disabled
No shell execution, arbitrary URL fetching, secrets, write operations, or user-data storage
Stateless Streamable HTTP deployment
The repository includes a non-root Dockerfile and render.yaml Blueprint.
Push this repository to GitHub.
Sign in to Render and select New → Blueprint.
Connect the GitHub repository and apply render.yaml.
In the Render service environment, change ARXIV_USER_AGENT to include your
real contact email or repository URL.
Wait for /health to pass, then copy the service URL.
The final MCP URL is:
https://<your-render-service>.onrender.com/mcpThe Blueprint uses Render's free instance so deployment does not silently create
a billing commitment. Render documents that free services sleep after 15 minutes
of inactivity and can take about a minute to restart. That cold start can exceed
an MCP client's timeout; upgrade the service to starter or another paid instance
before relying on it as an always-available production connector. See the
Render free-tier limitations and
Blueprint reference.
These steps follow the current official OpenAI documentation:
Deploy the server and confirm the public HTTPS /mcp URL works in MCP Inspector.
In ChatGPT, open Settings → Security and login and enable Developer mode.
Open ChatGPT Plugins and select the plus button.
Enter:
Name: arXiv Research
Description: Read-only search and metadata retrieval from the official arXiv API.
Connection: public MCP endpoint
Server URL: https://<your-render-service>.onrender.com/mcp
Authentication: none
Create the connection and confirm that exactly five tools are discovered.
Start a new chat and add arXiv Research from the tools menu.
OpenAI currently requires a public HTTPS endpoint (or its Secure MCP Tunnel) and
Streamable HTTP, typically at /mcp. Developer-mode availability depends on the
account and workspace policy. OpenAI's current page does not promise it for every
named ChatGPT plan, so the presence of the Developer mode toggle on your account is
the authoritative check. If a Plus account does not show it, the server remains
usable through MCP Inspector, another MCP client, or the OpenAI API Playground.
See OpenAI's current connection guide
and MCP server guide.
Search arXiv for recent quantum gravity papers.
Find papers about the Bondi-Sachs formalism.
Search hep-th for path integral approaches to gravity.
Find papers by Roger Penrose related to general relativity.
Get the metadata and PDF link for arXiv:2401.12345.
.
├── src/arxiv_mcp/
│ ├── arxiv_client.py
│ ├── config.py
│ ├── models.py
│ └── server.py
├── tests/
├── .github/workflows/ci.yml
├── .env.example
├── Dockerfile
├── render.yaml
├── pyproject.toml
└── README.mdMIT licensed.
Retrieve complete metadata for one known arXiv ID, including abstract, DOI, journal reference, categories, and PDF link.
| Name | Required | Description | Default |
|---|---|---|---|
| arxiv_id | Yes | arXiv ID or arXiv abstract/PDF URL |
| Name | Required | Description |
|---|---|---|
| doi | No | |
| title | Yes | |
| abs_url | Yes | |
| authors | Yes | |
| pdf_url | Yes | |
| updated | Yes | |
| abstract | Yes | |
| arxiv_id | Yes | arXiv identifier, including a version when supplied |
| published | Yes | |
| categories | Yes | |
| primary_category | No | |
| journal_reference | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, covering safety and immutability. The description adds value by enumerating the specific metadata returned (abstract, DOI, journal reference, categories, PDF link), which is not in the annotations. 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?
A single, front-loaded sentence with zero filler. Every clause earns its place: the verb, the scope (one known ID), and the return contents are all included efficiently.
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's simplicity (one parameter, well documented in schema), the presence of an output schema, and annotations covering read-only/idempotent behavior, the description fully covers what an agent needs to know to invoke it correctly. Nothing essential is missing.
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 100% because the parameter has its own description ('arXiv ID or arXiv abstract/PDF URL'), so the schema already explains what arxiv_id accepts. The tool description does not add further parameter detail, so baseline 3 applies.
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 a specific verb 'Retrieve' and resource 'complete metadata for one known arXiv ID', and explicitly notes this is for a single known ID, distinguishing it from sibling search tools. The description clearly communicates exact scope and content.
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 phrase 'for one known arXiv ID' implies when to use it (you have the exact ID) and implicitly distinguishes it from search-based siblings, but does not explicitly name alternatives or state when not to use it. Clear context, but no explicit exclusions beyond what is implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the most recently submitted papers in one arXiv category. Use for current literature scans and research updates.
| Name | Required | Description | Default |
|---|---|---|---|
| category | Yes | arXiv category such as gr-qc, hep-th, quant-ph, math-ph, or cs.AI | |
| max_results | No | Number of papers to return |
| Name | Required | Description |
|---|---|---|
| query | Yes | |
| start | Yes | |
| papers | Yes | |
| returned | Yes | |
| total_results | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the description only needs to add context. It adds the scoping constraints 'most recently submitted' and 'in one arXiv category', but does not describe ordering, pagination, or default behavior beyond what the schema and output schema cover. No contradiction with annotations.
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?
Two sentences with zero waste: the first defines the function directly, the second gives a concise usage hint. The most important 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?
For a simple read-only tool with a full output schema and complete parameter documentation, the description covers scope and intended use. It omits mention of the max_results default, but that is already in the schema, so the description is adequate for correct invocation.
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 100%, so both 'category' and 'max_results' are fully documented including allowed values and defaults. The description adds no parameter-specific detail, so a baseline score of 3 is appropriate.
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 a clear verb 'Return' and specific resource 'the most recently submitted papers in one arXiv category', which distinguishes it from search tools. Also includes the explicit use case 'current literature scans and research updates', making the tool's role unambiguous.
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 explicit context for when to use the tool via 'Use for current literature scans and research updates'. It does not name sibling tools like search_arxiv or explicitly state when not to use it, but the recency-focused wording implies it is for recent-paper scans rather than broad search.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the official arXiv index by keywords or advanced arXiv query syntax. Use this for general paper discovery and pagination.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Keywords or an arXiv API query expression | |
| start | No | Zero-based result offset | |
| sort_by | No | relevance | |
| sort_order | No | descending | |
| max_results | No | Number of papers to return |
| Name | Required | Description |
|---|---|---|
| query | Yes | |
| start | Yes | |
| papers | Yes | |
| returned | Yes | |
| total_results | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is established. The description adds the 'official' nature of the index and pagination support, but no other behavioral traits. This is adequate given the annotation coverage.
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?
Two sentences with no filler, front-loading the core purpose and usage. The description is concise and structured effectively for quick agent scanning.
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 presence of an output schema and comprehensive annotations, the description adequately covers purpose, query types, general discovery, and pagination. Sort options are not mentioned but are evident from schema enums and defaults, so the description is complete enough for correct invocation.
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 60% with descriptions for query, start, and max_results. The description enriches the query parameter by noting 'advanced arXiv query syntax,' which adds value beyond the schema. sort_by and sort_order are left to their enums and defaults, which are self-explanatory.
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 states a specific verb ('Search'), a resource ('official arXiv index'), and input types ('keywords or advanced arXiv query syntax'). It also mentions 'general paper discovery' which hints at differentiation from author/category-specific siblings, though it doesn't explicitly name them.
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 clear usage context with 'Use this for general paper discovery and pagination.' It does not explicitly list when not to use it or name alternative sibling tools, but the context implies these are covered by other sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find arXiv papers written by a named author. Use this when the author is the main search constraint.
| Name | Required | Description | Default |
|---|---|---|---|
| author_name | Yes | Author name, e.g. Roger Penrose | |
| max_results | No | Number of papers to return |
| Name | Required | Description |
|---|---|---|
| query | Yes | |
| start | Yes | |
| papers | Yes | |
| returned | Yes | |
| total_results | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already carry readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is covered. But the description adds essentially no behavioral context beyond the schema — it doesn't disclose fuzzy-name matching behavior, how arXiv normalizes author names, pagination, or that 'Roger Penrose' style input may need tuning. The 'Find' verb is consistent with readOnly, so no contradiction, but the description contributes little beyond what annotations provide.
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?
Two tightly written sentences with zero redundancy. The core purpose is front-loaded in the first sentence, and the selection rule follows immediately. Every word earns its place.
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?
An output schema exists and schema coverage is complete, so return values and parameters are documented. The main omission is guidance on how this tool differs from the general search_arxiv sibling — an agent may not know whether search_arxiv accepts a topic instead of an author. For a simple two-parameter search tool this is borderline adequate but could be more decisive.
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 100% — both author_name and max_results are fully documented with examples and constraints in the schema itself. The description adds no additional parameter-level meaning. Baseline 3 is correct since the schema does the heavy lifting and there is no gap to compensate for.
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 states a specific verb and resource — 'Find arXiv papers written by a named author' — and pins the distinguishing constraint (author as the main search dimension). This differentiates it from siblings like search_arxiv_by_category, though it doesn't explicitly contrast with the general search_arxiv tool. Clear enough for an agent to pick correctly in most cases.
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?
'Use this when the author is the main search constraint' gives a concrete selection rule, which is useful. However, it never names alternatives or states when this tool should NOT be used — e.g., when category or general keyword search is more appropriate. The guidance is present but minimal and leaves the sibling boundary to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search within one arXiv subject category, optionally narrowed by keywords. Use for fields such as gr-qc, hep-th, quant-ph, math-ph, or astro-ph.CO.
| Name | Required | Description | Default |
|---|---|---|---|
| category | Yes | arXiv category such as gr-qc, hep-th, quant-ph, math-ph, or cs.AI | |
| keywords | No | Optional keywords to combine with the category | |
| max_results | No | Number of papers to return |
| Name | Required | Description |
|---|---|---|
| query | Yes | |
| start | Yes | |
| papers | Yes | |
| returned | Yes | |
| total_results | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, covering safety and side-effect profile. The description adds no behavioral details beyond that—such as how results are ordered, whether it searches titles or abstracts, or pagination behavior. Since annotations handle the basic traits, the description contributes little additional 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 only two sentences, both essential. The main purpose is front-loaded, and the category examples are useful without being verbose. Zero wasted words—ideal conciseness.
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?
The tool has an output schema covering return format and annotations covering safety, so those gaps are filled. However, the description omits operational details such as result sorting, whether keywords apply to title/abstract/full text, or any limits beyond max_results (already in schema). For a search tool, these details affect effective usage, so the description is adequate but not fully 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?
Schema description coverage is 100%, so the baseline is 3. The description adds a small clarification ('optionally narrowed by keywords') that mirrors the schema's own description ('Optional keywords to combine with the category'). The category examples are duplicated. No substantial meaning is added beyond the schema, so it stays at baseline.
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 a specific action ('Search within one arXiv subject category') and the resource (arXiv category). It provides examples of valid categories, making the purpose concrete. However, it does not explicitly differentiate from sibling tools like search_arxiv, relying on the name to convey the category-specific scope, so it misses the 'distinguishes from siblings' criteria.
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 context by naming specific categories ('Use for fields such as gr-qc, hep-th...'), but this is more about parameter format than tool selection. It gives no explicit guidance on when to use this versus search_arxiv or search_arxiv_by_author, nor any exclusions. The context is implied rather than stated.
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.
v1.0.0get_arxiv_paperget_recent_arxiv_paperssearch_arxivsearch_arxiv_by_authorsearch_arxiv_by_categoryScored across 5 tools
Each tool has a clearly distinct purpose: general search, specific paper retrieval, author search, category search, and recent papers. No two tools overlap in function; the specialized search tools are properly scoped with explicit use cases, and get_recent_arxiv_papers is differentiated from search_arxiv_by_category by focusing on recency rather than keyword filtering.
All tool names follow a consistent verb_noun pattern, with 'search_' for discovery operations and 'get_' for retrieval. The pattern is uniform despite minor semantic differences (e.g., 'search_arxiv' vs 'search_arxiv_by_author' vs 'get_recent_arxiv_papers'), and the naming makes the action and target obvious.
Five tools is an ideal scope for an arXiv research client. Each tool provides a distinct capability that covers the primary use cases of paper discovery and metadata retrieval without unnecessary bloat. The count feels intentional and well-balanced for the server's stated purpose.
The tool surface covers the core arXiv workflows: general search, targeted searches by author and category, retrieval by ID, and recent-paper scans. The only minor gaps are non-essential features like citation lookup or category listing, but these are not critical for the server's purpose and can be worked around with existing tools (e.g., using search_arxiv for category keywords).
Search arXiv, fetch paper metadata, and read full-text content.
Search arXiv/Semantic Scholar/OpenAlex + medical evidence (PubMed/Europe PMC) + LaTeX/PDF tools.
ArXiv preprint search, daily category digest, and author-collaborator graph.
Search and download academic papers from arXiv, PubMed, bioRxiv, medRxiv, Google Scholar, Semantic…