Which integrations are available for this server?

Provides live arXiv paper search with category filtering, author matching, and date sorting, as well as paper details and dynamic category feeds. Automatically discovers GitHub repositories that implement or reference arXiv papers, extracting star counts, languages, licenses, and repository URLs.

How do I use ArXivLens MCP?

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., "@ArXivLens MCP Find recent papers on KV-cache compression and their GitHub implementations" 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.

ArXivLens MCP

by chan4kum

Overview Schema Source Related Servers Discussions Admin

Python

Hybrid

🔍 ArXivLens MCP

Autonomous Real-Time Academic Intelligence, Paper Discovery & Code-Implementation Mapping

An enterprise-grade Model Context Protocol (MCP) server and client built with FastMCP 2.0, standardizing how AI agents scout research papers, extract structured insights, and verify open-source GitHub implementations in real time.

Key Features • Architecture • Real-Time Problem Statement • Quickstart • Claude & Cursor Setup • Interactive Agent

⚡ Real-Time Problem Statement

Every day, hundreds of cutting-edge AI, Machine Learning, and Computer Science papers are published to arXiv, while corresponding open-source code repositories, benchmarks, and model checkpoints are scattered across GitHub, Hugging Face, and Papers With Code.

Researchers, AI engineers, and technical leads face three critical real-time challenges:

Information Overload & Latency: Finding newly dropped breakthrough papers in specific niches (e.g., test-time compute, reasoning models, KV-cache compression) before they get buried.
The Implementation Gap: Locating verified, highly-starred GitHub repositories and code implementations that correspond to an arXiv paper in real time.
Synthesis & Evaluation Friction: Manually downloading and reading 30-page PDFs just to extract key contributions, methodology gaps, and experimental baselines.
Agent Integration Bottleneck: LLM agents (Claude Desktop, Cursor, Custom Agents) lack standardized, safe, and live access to academic repositories and code-linkage databases.

ArXivLens MCP solves this end-to-end by exposing production-grade MCP Tools, dynamic Resources, and structured Prompts over standard transports (stdio and SSE).

Related MCP server: arXiv MCP Server

🎯 Key Features

🔍 Live arXiv Search: Real-time querying across arXiv's Atom 1.0 XML API with category filtering (cs.AI, cs.LG, cs.CL, cs.CV, stat.ML), author matching, and date sorting.
💻 Automated Code Discovery: Proactively scans GitHub for repositories implementing or referencing the paper, extracting star counts, languages, licenses, and direct URLs.
📑 Structured Research Briefs: Synthesizes paper abstracts into executive 1-page briefs breaking down Problem Statement, Proposed Methodology, Key Contributions, Limitations, and Matching Code.
📡 Dynamic MCP Resources:
- arxiv://categories: Catalog of supported research domains.
- arxiv://feed/{category}: Live category paper feed.
- paper://{arxiv_id}/brief: Dynamic markdown research brief for any paper ID.
🧠 Expert Prompt Templates: Standardized prompt templates for systematic literature reviews, critical methodology peer-reviews, and reproducibility audits.
🖥️ Dual Interface: Includes both a FastMCP Server and a Rich Terminal Client with an interactive autonomous agent loop.
⚡ Zero-Cost Local Evaluation: Built-in mock reasoning fallback allows testing and evaluation immediately without requiring paid API keys!

🏗️ Architecture

flowchart TD
    subgraph Clients["MCP Clients & AI Hosts"]
        Claude["Claude Desktop"]
        Cursor["Cursor AI"]
        TerminalCLI["ArXivLens CLI / Agent"]
        CustomAgent["LangChain / LlamaIndex / Agent Frameworks"]
    end

    subgraph Protocol["Model Context Protocol (MCP Transport)"]
        StdIO["stdio (Subprocess Pipe)"]
        SSE["SSE / HTTP Transport"]
    end

    subgraph Server["ArXivLens FastMCP 2.0 Server"]
        Router["FastMCP Request Dispatcher"]
        
        subgraph Capabilities["Server Primitives"]
            Tools["MCP Tools\n• search_arxiv\n• get_paper_details\n• find_code_repositories\n• generate_research_brief"]
            Resources["MCP Resources\n• arxiv://categories\n• arxiv://feed/{cat}\n• paper://{id}/brief"]
            Prompts["MCP Prompts\n• literature_review\n• paper_critique\n• reproducibility_audit"]
        end

        subgraph CoreServices["Internal Services"]
            ArxivSvc["ArxivService\n(Atom 1.0 XML Async Client)"]
            GitHubSvc["GitHubService\n(REST Search API & Matcher)"]
            BriefSvc["BriefService\n(Synthesis & Markdown Engine)"]
        end
    end

    subgraph Upstream["Upstream Real-Time Data Sources"]
        ArXivAPI["arXiv Official API\n(export.arxiv.org)"]
        GitHubAPI["GitHub Search API\n(api.github.com)"]
    end

    Clients --> Protocol
    Protocol --> Router
    Router --> Capabilities
    Tools --> CoreServices
    Resources --> CoreServices
    CoreServices --> ArXivAPI
    CoreServices --> GitHubAPI

🚀 Quickstart

1. Installation

Clone the repository and install dependencies using uv (recommended) or pip:

git clone https://github.com/chan4kum/arxivlens-mcp.git
cd arxivlens-mcp

# Using uv (fastest)
uv sync

# Or using standard pip
python3 -m venv .venv
source .venv/bin/activate
pip install -e .

2. Configure Environment (Optional)

Copy .env.example to .env:

cp .env.example .env

Tip: Adding a GITHUB_TOKEN increases your GitHub API rate limit from 60 req/hr to 5,000 req/hr.

💻 CLI & Interactive Client

ArXivLens comes out-of-the-box with an interactive CLI built with rich:

Inspect Server Capabilities

Inspect all registered MCP tools, resources, and prompts:

uv run arxivlens-client inspect

Real-Time Paper Search

uv run arxivlens-client search "DeepSeek-R1 reasoning" --max 3

Generate Structured Research Brief

uv run arxivlens-client brief 1706.03762

Find GitHub Code Repositories

uv run arxivlens-client code 1706.03762

Autonomous Agent Loop

Launch the interactive terminal agent to scout papers and match code conversationally:

uv run arxivlens-client agent

🔌 Claude & Cursor Desktop Integration

Claude Desktop

Add this to your claude_desktop_config.json:

{
  "mcpServers": {
    "arxivlens": {
      "command": "uv",
      "args": [
        "--directory",
        "/absolute/path/to/arxivlens-mcp",
        "run",
        "arxivlens-server"
      ],
      "env": {
        "PYTHONUNBUFFERED": "1"
      }
    }
  }
}

Cursor AI

Open Cursor Settings > Features > MCP Servers.
Click Add New MCP Server:
- Name: ArXivLens
- Type: command
- Command: uv --directory /absolute/path/to/arxivlens-mcp run arxivlens-server

🧪 Testing

Run the comprehensive unit and integration test suite:

# Run pytest with coverage
uv run pytest -v tests/

# Run linter
uv run ruff check .

📂 Repository Structure

arxivlens-mcp/
├── .github/workflows/ci.yml       # GitHub Actions automated CI
├── config/
│   ├── claude_desktop_config.json # Claude Desktop configuration
│   └── cursor_mcp.json            # Cursor AI configuration
├── docs/
│   ├── ARCHITECTURE.md            # In-depth architectural documentation
│   └── SETUP_GUIDE.md             # Integration guide for agents & hosts
├── src/arxivlens/
│   ├── __init__.py                # Package exports
│   ├── server.py                  # FastMCP 2.0 Server (Tools, Resources, Prompts)
│   ├── client.py                  # FastMCP Client async wrapper
│   ├── cli.py                     # Rich terminal CLI & Agent loop
│   ├── models.py                  # Pydantic data models
│   └── services/
│       ├── arxiv_service.py       # Async arXiv Atom XML client
│       ├── github_service.py      # GitHub search & code matcher
│       └── brief_service.py       # Research brief synthesis engine
├── tests/
│   ├── conftest.py                # Mock fixtures for offline testing
│   ├── test_services.py           # Unit tests for services
│   ├── test_server.py             # Server endpoints tests
│   └── test_client.py             # Client integration tests
├── .env.example                   # Environment configuration template
├── .gitignore                     # Git ignore patterns
├── LICENSE                        # MIT License
├── pyproject.toml                 # Packaging & CLI entrypoints
└── README.md                      # Project documentation

🤝 Contributing

Contributions are welcome! Please follow these steps:

Fork the repository.
Create your feature branch (git checkout -b feature/amazing-feature).
Run tests and linter (uv run pytest && uv run ruff check .).
Commit your changes (git commit -m 'feat: add amazing feature').
Push to the branch (git push origin feature/amazing-feature).
Open a Pull Request.

📜 License

Distributed under the MIT License. See LICENSE for more information.

Available Tools

4 tools

find_code_repositoriesFind Code RepositoriesA

Discover open-source GitHub repositories implementing or referencing an arXiv paper.

ParametersJSON Schema

Name	Required	Description
`title`	No	Optional title of the paper to enhance repository discovery.
`arxiv_id`	Yes	The arXiv ID of the paper.
`max_results`	No	Maximum number of repositories to return (default: 5).

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.8/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 behavioral burden. It discloses the core behavior—searching GitHub for repositories tied to an arXiv paper—and 'discover' implies a read-only operation. However, it does not mention details like whether results are limited to open-source only (though it says open-source) or any search constraints beyond the schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence with no filler. It conveys the tool's scope and purpose efficiently, and every word contributes to understanding what the tool does.

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

Completeness4/5

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

Given the tool's simple scope, fully described parameters, and the presence of an output schema, the description is largely complete. The only minor gap is the absence of explicit guidance on when to invoke this tool relative to the sibling tools, but the core call pattern is clear.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already fully documents all three parameters. The description adds no additional parameter-level meaning beyond the schema, so the baseline score of 3 is appropriate.

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 states a specific action ('Discover'), a specific resource ('open-source GitHub repositories'), and a precise selection criterion ('implementing or referencing an arXiv paper'). This clearly distinguishes the tool from siblings like search_arxiv, which finds papers, and get_paper_details, which retrieves paper details.

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

Usage Guidelines3/5

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

The description implies the tool should be used when an arXiv ID is already known and code repositories are needed, but it does not explicitly say when to prefer this over siblings or when not to use it. No alternatives or exclusions are named, leaving the routing decision to inference.

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

generate_research_briefGenerate Research BriefB

Synthesize an executive research brief for a paper, including problem statement, methodology, key findings, and matching code.

ParametersJSON Schema

Name	Required	Description	Default
`arxiv_id`	Yes	The arXiv identifier of the paper.

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

B3.3/5.0

Behavior2/5

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

There are no annotations, so the description carries the burden of behavioral disclosure. It does not state whether the tool is read-only, fetches external data, has failure modes, requires network access, or modifies anything. The content list is useful but does not expose 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single focused sentence that front-loads the action and resource, then lists deliverable components. There is no filler or redundancy; every phrase contributes to understanding the tool's output.

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

Completeness3/5

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

The tool has one well-documented parameter and an output schema, so basic invocation details are covered. However, with no annotations and no usage guidance, the description does not fully convey when this synthesis tool should be chosen over combining get_paper_details and find_code_repositories, leaving a notable gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the only parameter arxiv_id is already described as 'The arXiv identifier of the paper.' The description does not add further parameter meaning or examples, so it meets the baseline but does not exceed it.

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 uses a specific verb and resource: 'Synthesize an executive research brief for a paper,' and lists concrete content components. This clearly distinguishes it from siblings like search_arxiv, get_paper_details, and find_code_repositories, which have different objectives.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. It does not mention siblings, prerequisites, or contexts where get_paper_details or find_code_repositories would be more appropriate, leaving the agent to infer usage.

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

get_paper_detailsGet Paper DetailsA

Retrieve full metadata and abstract for a specific arXiv ID.

ParametersJSON Schema

Name	Required	Description	Default
`arxiv_id`	Yes	The unique arXiv ID (e.g., '1706.03762' or '2310.06825').

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.1/5.0

Behavior3/5

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

No annotations are provided, so the description carries the burden of disclosing behavior. 'Retrieve' correctly implies a read-only lookup, but the description does not mention behavior for invalid IDs, rate limits, or other operational traits. For a simple fetch-by-ID tool, this is adequate but not rich.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence with no filler. The action and target are front-loaded, and every word earns its place.

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?

With only one required parameter, full schema coverage, and an output schema available, the description is sufficient for an agent to invoke the tool correctly. Return-value details are covered by the output schema, so nothing essential is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the single arxiv_id parameter already has a descriptive schema with examples. The description's 'specific arXiv ID' adds no semantic meaning beyond what the schema provides, so the baseline score of 3 applies.

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 states a specific verb ('Retrieve') and a precise resource ('full metadata and abstract') for a specific arXiv ID. This clearly distinguishes it from sibling search_arxiv, which is for discovery rather than fetching a known paper.

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

Usage Guidelines4/5

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

The phrase 'for a specific arXiv ID' clearly implies the appropriate context: use this when you already have the paper identifier. It does not explicitly name alternatives or mention when not to use it, so it stops short of full routing guidance.

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

search_arxivSearch ArxivB

Search papers on arXiv in real time.

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes	Search query string (supports keywords, author names, or category prefixes like 'cat:cs.AI').
`sort_by`	No	Sorting criteria: 'relevance', 'submittedDate', or 'lastUpdatedDate'.	relevance
`max_results`	No	Maximum number of papers to retrieve (default: 5, max: 20).

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.1/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'search... in real time' and does not mention API behavior, rate limits, result format, pagination, or read-only status. 'Real time' adds one trait, but it is insufficient for a networked search tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is one front-loaded sentence with no wasted words. It is appropriately sized for a relatively simple tool, even though it could convey more behavioral context.

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

Completeness3/5

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

The tool is simple, the output schema covers return information, and the input schema has full parameter coverage. The single-sentence description is minimally adequate, but the lack of annotations and usage guidance leaves the agent to infer when to select this tool and what behavioral expectations apply.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema already documents all three parameters. The description adds no parameter-level meaning beyond the schema, which makes the baseline score of 3 appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: 'Search papers on arXiv in real time.' This clearly distinguishes it from siblings like get_paper_details or find_code_repositories at a glance. It does not explicitly describe the returned content, but the core purpose is unambiguous.

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

Usage Guidelines2/5

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

No explicit guidance is given about when to use this tool versus the sibling tools, nor are there exclusions or prerequisites. The role of this tool as the search/discovery entry point is implied by its name rather than stated.

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.

4 tool updatesv0.1.0Sep 20, 2026
- First observedfind_code_repositories
- First observedgenerate_research_brief
- First observedget_paper_details
- First observedsearch_arxiv

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

A3.9/5.0

Scored 2026-09-20 17:50 across 4 tools

Disambiguation5/5

Each tool targets a distinct stage of the research workflow: searching, retrieving metadata, finding code, and generating a synthesis. There is no meaningful overlap between tool purposes.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern with clear, descriptive verbs: search, get, find, generate. The naming convention is uniform throughout.

Tool Count5/5

Four tools is well-scoped for an arXiv research assistant: search, detail retrieval, code discovery, and brief generation. Each tool earns its place and the set is neither bloated nor too thin.

Completeness5/5

The surface covers the full research journey from discovery to synthesis, including practical follow-up like finding code repositories. No obvious dead ends or missing lifecycle steps are apparent for this domain.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

developer-tools-mcp-server A
com.thenextgennexus
Search GitHub, npm, PyPI, StackOverflow, ArXiv from one MCP — built for coding agents.
Developer Tools Search
72
LivingMeta — AI in ResearchOAuth
ai.livingmeta
Read-only MCP over the LivingMeta AI-in-Research corpus: 12,400 papers, gaps, priority agenda.
Research & Data Search
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
PapersFlowOAuth
io.github.papersflow-ai
Academic research MCP server for paper search, citation checks, graphs, and deep research.
Research & Data Search Documentation Access
214

Related MCP Servers

paperpal
Search Research & Data
jerpint
A
license
B
quality
D
maintenance
MCP Extension that gives LLMs access to arXiv and Hugging Face papers, enabling users to discuss papers, search for new research, and organize literature reviews through natural conversation.
Updated a year ago (2025-05-08 22:40 UTC)
2
13
MIT
arXiv MCP Server
Research & Data Search Documentation Access
coskun45
F
license
Not graded
quality
D
maintenance
Enables searching and retrieving arXiv papers by topic, fetching abstracts by paper ID, and saving markdown content to files. Includes examples of integrating MCP tools with Google Gemini for AI-powered paper research.
Updated 10 months ago (2025-11-25 10:16 UTC)
-
kivv
Search Text Summarization Research & Data
jeffaf
F
license
Not graded
quality
C
maintenance
Automated arXiv research paper discovery and AI-powered summarization system that enables Claude Desktop users to search, retrieve, and get intelligent summaries of academic papers through MCP integration.
Updated 20 days ago (2026-09-01 18:06 UTC)
1
-
arxivsub-mcp
Research & Data Search
arxivsub
A
license
A
quality
D
maintenance
Enables searching arXiv and top AI conferences, finding related papers, generating research insights, and managing a personal library via MCP tools.
Updated 2 months ago (2026-07-10 05:32 UTC)
5
22 npm
MIT