de en es ja ko ru zh

ArXiv MCP Server

Name: ArXiv MCP Server
Author: freyzo

by freyzo

Overview Schema Source Related Servers Discussions Admin

Python

Local

arXiv Deep Research

Instalar en VS Code Instalar en VS Code Insiders

Un servidor del Protocolo de Contexto de Modelo (MCP) para buscar, descargar y leer artículos de arXiv, diseñado como un agente especializado para su integración en sistemas multiagente como Microsoft Magentic-UI y AutoGen.

La idea: En lugar de tratar la búsqueda en arXiv como una simple herramienta de consulta, este servidor está estructurado como un agente de investigación de primer nivel, uno que puedes conectar directamente a un equipo al estilo Magentic-One como un McpAgent, dando a un Orquestador acceso a toda la literatura científica como un recurso delegable.

Integración con Magentic-UI

Magentic-UI admite instancias personalizadas de McpAgent a través de mcp_agent_configs en su archivo de configuración. Este servidor se conecta directamente:

# examples/magentic_ui_config.yaml
client:
  mcp_agent_configs:
    - agent_name: ArxivResearcher
      description: >
        Specialist agent for searching and reading arXiv papers.
        Use when the task requires finding academic papers, understanding
        research literature, or retrieving technical details from published work.
      server_params:
        type: StdioServerParams
        command: python
        args: ["-m", "arxiv_mcp_server"]
        env:
          PYTHONPATH: /path/to/arxiv-deep-research/src

Una vez registrado, el Orquestador de Magentic-UI puede delegar subtareas de investigación a este agente a través del patrón estándar de Libro de Tareas / Libro de Progreso, exactamente como WebSurfer maneja la navegación web, pero para literatura académica.

Related MCP server: ArXiv Paper MCP

Integración con AutoGen AgentChat

Consulta examples/autogen_research_team.py para ver un equipo completo de 3 agentes:

Orchestrator (MagenticOneGroupChat)
├── ArxivSurfer  ← this MCP server, wrapped via StdioServerParams + mcp_server_tools
└── Coder        ← synthesizes findings into structured markdown reports

pip install "autogen-agentchat" "autogen-ext[openai]" "mcp>=1.2.0"
export OPENAI_API_KEY=...
python examples/autogen_research_team.py

Herramientas

Herramienta	Descripción
`search_papers`	Consulta arXiv con filtros avanzados: rango de fechas, categoría, ordenar por relevancia o fecha
`download_paper`	Obtiene un PDF de un artículo y lo convierte a markdown limpio para el consumo de LLM
`read_paper`	Accede al contenido de un artículo descargado previamente
`list_papers`	Ver todos los artículos en el almacenamiento local

search_papers

Admite una sintaxis de consulta rica: frases entre comillas, operadores booleanos, búsqueda específica por campo (ti:, au:, abs:) y filtrado por categoría:

{
  "query": "\"multi-agent\" AND \"orchestration\" ANDNOT survey",
  "max_results": 10,
  "date_from": "2024-01-01",
  "categories": ["cs.AI", "cs.MA"],
  "sort_by": "relevance"
}

Tubería de investigación multietapa

A un nivel alto, arxiv-deep-research ejecuta un bucle multietapa simple pero potente:

Planificar la tarea de investigación
- Un agente coordinador (por ejemplo, el Orquestador MagenticOneGroupChat de AutoGen) toma el objetivo del usuario y lo divide en subtareas.
Descubrir artículos candidatos
- El coordinador llama a la herramienta MCP search_papers para encontrar artículos de arXiv relevantes por tema, categoría y fecha.
Descargar y normalizar el contenido
- Para los IDs seleccionados, llama a download_paper, que obtiene el PDF y lo convierte en markdown limpio para que los LLM lo lean.
Análisis profundo de artículos
- El coordinador (u otro agente) utiliza el prompt deep-paper-analysis para solicitar un análisis estructurado de un ID de artículo dado, opcionalmente a través de múltiples llamadas mientras exploras trabajos relacionados.
Síntesis e informes
- Un agente descendente como Coder (en el ejemplo de AutoGen) convierte estos análisis en un informe de investigación final: resúmenes, tablas comparativas, problemas abiertos y sugerencias de próximos pasos.

Puedes ejecutar esta tubería manualmente llamando a las herramientas y prompts desde cualquier cliente compatible con MCP, o automáticamente usando el equipo de AutoGen de muestra.

Benchmark de evaluación

El repositorio incluye un benchmark de calidad de recuperación (eval/benchmark.py) que mide:

Precision@K — fracción de los resultados top-K que son relevantes
Recall@K — fracción de artículos relevantes conocidos encontrados en el top-K
MRR — Rango Recíproco Medio del primer resultado relevante

Las consultas de verdad fundamental (ground-truth) se obtienen de artículos emblemáticos (AutoGen 2308.08155, Magentic-One 2411.04468, RAG 2005.11401, CoT 2201.11903) y pueden extenderse automáticamente utilizando la tubería de datos sintéticos a continuación.

python eval/benchmark.py --k 10 --output results.json

Generación de datos de evaluación sintéticos (estilo AgentInstruct)

scripts/generate_eval_tasks.py implementa una tubería de 4 etapas que genera diversas consultas de benchmark a partir de resúmenes de arXiv, reflejando el enfoque de AgentInstruct:

Stage 1: Seed collection     → fetch paper abstracts from arXiv by category
Stage 2: Content transform   → extract key concepts and problem statements
Stage 3: Instruction gen     → generate realistic research queries via GPT-4o-mini
Stage 4: Instruction refine  → create harder variants at subtopic intersections

export OPENAI_API_KEY=...
python scripts/generate_eval_tasks.py --seed-category cs.AI --num-seeds 20 --output eval/generated_queries.json

La salida incluye niveles de dificultad fácil/medio/difícil para una evaluación estratificada.

Observabilidad: Rastreo con OpenTelemetry

Cada llamada a herramienta está instrumentada con spans de OpenTelemetry (refleja el soporte OTel integrado de AutoGen v0.4):

# Console output (no infrastructure needed)
export ARXIV_MCP_TRACE_CONSOLE=true
python -m arxiv_mcp_server

# OTLP export to Jaeger / Azure Monitor
docker run -d --name jaeger -p 16686:16686 -p 4317:4317 jaegertracing/all-in-one
export OTEL_EXPORTER_OTLP_ENDPOINT=http://localhost:4317
export OTEL_SERVICE_NAME=arxiv-mcp-server
python -m arxiv_mcp_server
# View traces: http://localhost:16686

Spans registrados: mcp.tool.search_papers, mcp.tool.download_paper, mcp.tool.read_paper — cada uno con consulta, categorías, recuento de resultados, latencia y estado de error como atributos.

El rastreo es una operación sin costo cuando opentelemetry-sdk no está instalado.

Instalación

Requiere Python 3.11+

git clone https://github.com/freyzo/arxiv-deep-research
cd arxiv-deep-research
python3 -m venv .venv
source .venv/bin/activate
pip install -e .

# Optional: OTel tracing
pip install -e ".[tracing]"

Claude Desktop

{
  "mcpServers": {
    "arxiv": {
      "command": "/path/to/.venv/bin/python",
      "args": ["-m", "arxiv_mcp_server", "--storage-path", "/path/to/papers"]
    }
  }
}

Cursor

{
  "mcpServers": {
    "arxiv": {
      "command": "python",
      "args": ["-m", "arxiv_mcp_server"],
      "env": { "PYTHONPATH": "/path/to/arxiv-deep-research/src" }
    }
  }
}

Prompts

deep-paper-analysis

Flujo de trabajo de análisis integral que cubre resumen ejecutivo, metodología, resultados, implicaciones y direcciones futuras:

{ "paper_id": "2401.12345" }

Ejecución y reanudación de sesiones de investigación

Existen dos formas principales de ejecutar sesiones de investigación hoy en día.

1. Equipo multiagente de AutoGen (demo recomendada)

Esto utiliza modelos de OpenAI para coordinar un flujo de trabajo de investigación completo.

cd arxiv-deep-research
python3 -m venv .venv
source .venv/bin/activate
pip install -e .
pip install "autogen-agentchat" "autogen-ext[openai]" "mcp>=1.2.0"

export OPENAI_API_KEY=your_openai_key
python examples/autogen_research_team.py

Esto inicia una interfaz de consola interactiva donde:

el Orquestador planifica el trabajo,
ArxivSurfer busca y descarga artículos a través de MCP, y
Coder escribe el informe final en markdown.

Para reanudar una sesión, puedes:

ejecutar el script de nuevo y pegar el resumen anterior como parte de una nueva tarea, o
mantener abierta la misma sesión de consola y darle al equipo una instrucción de seguimiento (por ejemplo, “Ahora céntrate en las compensaciones de seguridad”).

2. Uso directo de MCP desde herramientas como Claude Desktop o Cursor

También puedes hablar directamente con el servidor MCP y construir tu propio bucle:

cd arxiv-deep-research
python3 -m venv .venv
source .venv/bin/activate
pip install -e .

export ARXIV_MCP_TRACE_CONSOLE=true   # optional
python -m arxiv_mcp_server

Mientras este servidor se ejecuta, cualquier cliente compatible con MCP puede:

llamar a search_papers y download_paper,
usar read_paper para extraer contenido al chat, y
llamar al prompt deep-paper-analysis varias veces.

El manejador de prompts mantiene un contexto de investigación global simple, por lo que las llamadas repetidas en el mismo proceso mencionarán los IDs de artículos analizados previamente y animarán al modelo a conectarlos. En la práctica, “reanudar” una sesión de investigación significa:

mantener vivo el mismo proceso del servidor MCP, y
emitir nuevas llamadas a deep-paper-analysis para nuevos IDs de artículos desde el mismo cliente o espacio de trabajo.

Estructura del repositorio

arxiv-deep-research/
├── src/arxiv_mcp_server/
│   ├── server.py          # MCP server + OTel init
│   ├── tracing.py         # @trace_tool decorator, OTLP + console exporters
│   ├── config.py
│   ├── tools/             # search, download, read, list
│   └── prompts/           # deep research analysis prompt
├── examples/
│   ├── autogen_research_team.py   # Magentic-One-style 3-agent team
│   └── magentic_ui_config.yaml    # McpAgent config for Magentic-UI
├── eval/
│   └── benchmark.py       # Precision@K / Recall@K / MRR harness
├── scripts/
│   └── generate_eval_tasks.py     # AgentInstruct-style query generator
└── pyproject.toml

Variables de entorno

Variable	Predeterminado	Descripción
`ARXIV_STORAGE_PATH`	`~/.arxiv-mcp-server/papers`	Ubicación de almacenamiento de artículos
`ARXIV_MCP_TRACE_CONSOLE`	`false`	Habilitar salida de rastreo en consola
`OTEL_EXPORTER_OTLP_ENDPOINT`	—	Punto final OTLP (ej. `http://localhost:4317`)
`OTEL_SERVICE_NAME`	`arxiv-mcp-server`	Nombre del servicio en los rastreos

Si utilizas el generador de datos de evaluación opcional, también necesitas:

Variable	Descripción
`OPENAI_API_KEY`	Utilizado por `scripts/generate_eval_tasks.py` para hablar con `gpt-4o-mini`

Problemas conocidos

El soporte de modelos es solo para OpenAI actualmente.
- El equipo de investigación de AutoGen y el generador de evaluación sintética llaman a modelos de OpenAI (gpt-4o / gpt-4o-mini) a través del SDK de Python de OpenAI.
- Aún no hay integración de primer nivel con google-genai / Gemini o Gemma, aunque el diseño lo admitiría.
Aún no hay Recursos MCP.
- Los artículos se exponen solo a través de herramientas (read_paper) en lugar de como Recursos MCP con URIs estables arxiv://. Los clientes MCP que prefieren Recursos aún no pueden listar artículos.
Pruebas limitadas.
- La lógica central de recuperación y evaluación tiene pruebas automatizadas muy ligeras; las funciones de métricas y los manejadores de herramientas deberían ganar pruebas unitarias con el tiempo.

Hoja de ruta

Mejoras planificadas (sujetas a cambios):

Soporte para Gemini / Gemma a través de google-genai
- Agregar una dependencia opcional google-genai y un pequeño ejecutor que pueda llamar a modelos Gemini/Gemma usando GEMINI_API_KEY.
- Exponer esto como un backend alternativo para la demo del equipo de investigación y el generador de evaluación.
Recursos MCP para artículos descargados
- Implementar list_resources / read_resource para que los PDFs descargados aparezcan como recursos arxiv://paper_id en los clientes MCP.
Pruebas y evaluaciones más sólidas
- Agregar pruebas unitarias para métricas, ayudantes de búsqueda y manejadores de prompts.
- Automatizar la ejecución de eval/benchmark.py y realizar un seguimiento de la regresión a lo largo del tiempo.
Sesiones de investigación más ricas
- Reemplazar el contexto de investigación global simple con IDs de sesión explícitos y estado persistente, para que “reanudar sesión X” se convierta en una característica de primer nivel entre reinicios.

Available Tools

4 tools

download_paperC

Download a paper and create a resource for it

ParametersJSON Schema

Name	Required	Description	Default
`paper_id`	Yes	The arXiv ID of the paper to download
`check_status`	No	If true, only check conversion status without downloading

TDQS

C2.9/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 mentions 'download a paper and create a resource', implying a write operation, but doesn't specify details like file format, storage location, permissions required, or error handling. For a tool with no annotations, this is insufficient to inform the agent adequately.

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, efficient sentence with zero waste. It is front-loaded with the core action ('download a paper') and avoids unnecessary details, making it easy for an agent to parse quickly.

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

Completeness2/5

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

Given the tool's complexity (involving download and resource creation), no annotations, and no output schema, the description is incomplete. It doesn't cover behavioral aspects like what 'create a resource' entails, potential side effects, or return values. This leaves significant gaps for the agent to understand the tool fully.

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?

The input schema has 100% description coverage, clearly documenting both parameters ('paper_id' and 'check_status'). The description adds no additional meaning beyond the schema, such as explaining the resource creation process or default behaviors. With high schema coverage, the baseline score of 3 is appropriate as the schema does the heavy lifting.

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 clearly states the action ('download a paper') and resource ('create a resource for it'), which is specific and actionable. However, it doesn't explicitly differentiate from sibling tools like 'read_paper' or 'list_papers', which might involve similar paper-related operations without the download aspect.

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 like 'read_paper' or 'search_papers'. It lacks context such as prerequisites (e.g., needing a valid arXiv ID) or exclusions (e.g., not for checking status only). This leaves the agent without clear usage direction.

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

list_papersA

List all existing papers available as resources

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.6/5.0

Behavior2/5

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

No annotations are present, so the description bears full responsibility for behavioral disclosure. It fails to mention that the operation is read-only, whether pagination exists, or any limits, which is insufficient for a listing 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?

A single, front-loaded sentence with no unnecessary words. Every word is meaningful and succinct.

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

Completeness2/5

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

Given no output schema and no annotations, the description should compensate by describing return format or behavior. It only states 'papers' without any detail on what fields or structure is returned, leaving significant gaps.

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

Parameters4/5

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

With zero parameters and 100% schema coverage, the baseline is 4. The description adds meaning by specifying the scope ('all existing papers, available as resources'), which is not present in the empty schema.

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

Purpose5/5

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

The description 'List all existing papers available as resources' clearly states the action (list) and resource (papers), differentiating from siblings get_paper_content and search_papers which focus on individual paper content or search.

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 usage for obtaining a list of all papers, but does not provide when-to-use or when-not-to-use guidance relative to sibling tools, leaving the agent to infer context.

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

read_paperC

Read the full content of a stored paper in markdown format

ParametersJSON Schema

Name	Required	Description	Default
`paper_id`	Yes	The arXiv ID of the paper to read

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations, the description carries full burden but only states the basic operation. It does not disclose behavioral traits such as permissions needed, error handling (e.g., for invalid paper_id), rate limits, or whether it's a read-only operation (implied but not confirmed). More context is needed for a mutation-sensitive agent.

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, efficient sentence with zero waste—front-loaded with the core action and resource, and includes the output format. Every word earns its place without redundancy.

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

Completeness2/5

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

Given no annotations and no output schema, the description is incomplete for a tool that retrieves content. It lacks details on return values (e.g., markdown structure, error responses), behavioral context, or usage relative to siblings, leaving gaps for an agent to operate effectively.

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%, with the parameter 'paper_id' fully documented as 'The arXiv ID of the paper to read'. The description adds no additional meaning beyond this, such as format examples or constraints, meeting the baseline for high schema coverage.

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 clearly states the action ('read the full content') and resource ('stored paper'), specifying the output format ('in markdown format'). It distinguishes from siblings like 'download_paper' (which might retrieve files) and 'list_papers'/'search_papers' (which list or search metadata), but does not explicitly contrast them.

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 guidance is provided on when to use this tool versus alternatives like 'download_paper' (e.g., for raw files vs. markdown content) or 'list_papers'/'search_papers' (e.g., for browsing vs. reading). The description implies usage for accessing content but lacks explicit context or exclusions.

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

search_papersA

Search for papers on arXiv with advanced filtering and query optimization.

QUERY CONSTRUCTION GUIDELINES:

Use QUOTED PHRASES for exact matches: "multi-agent systems", "neural networks", "machine learning"
Combine related concepts with OR: "AI agents" OR "software agents" OR "intelligent agents"
Use field-specific searches for precision:
- ti:"exact title phrase" - search in titles only
- au:"author name" - search by author
- abs:"keyword" - search in abstracts only
Use ANDNOT to exclude unwanted results: "machine learning" ANDNOT "survey"
For best results, use 2-4 core concepts rather than long keyword lists

ADVANCED SEARCH PATTERNS:

Field + phrase: ti:"transformer architecture" for papers with exact title phrase
Multiple fields: au:"Smith" AND ti:"quantum" for author Smith's quantum papers
Exclusions: "deep learning" ANDNOT ("survey" OR "review") to exclude survey papers
Broad + narrow: "artificial intelligence" AND (robotics OR "computer vision")

CATEGORY FILTERING (highly recommended for relevance):

cs.AI: Artificial Intelligence
cs.MA: Multi-Agent Systems
cs.LG: Machine Learning
cs.CL: Computation and Language (NLP)
cs.CV: Computer Vision
cs.RO: Robotics
cs.HC: Human-Computer Interaction
cs.CR: Cryptography and Security
cs.DB: Databases

EXAMPLES OF EFFECTIVE QUERIES:

ti:"reinforcement learning" with categories: ["cs.LG", "cs.AI"] - for RL papers by title
au:"Hinton" AND "deep learning" with categories: ["cs.LG"] - for Hinton's deep learning work
"multi-agent" ANDNOT "survey" with categories: ["cs.MA"] - exclude survey papers
abs:"transformer" AND ti:"attention" with categories: ["cs.CL"] - attention papers with transformer abstracts

DATE FILTERING: Use YYYY-MM-DD format for historical research:

date_to: "2015-12-31" - for foundational/classic work (pre-2016)
date_from: "2020-01-01" - for recent developments (post-2020)
Both together for specific time periods

RESULT QUALITY: Results sorted by RELEVANCE (most relevant papers first), not just newest papers. This ensures you get the most pertinent results regardless of publication date.

TIPS FOR FOUNDATIONAL RESEARCH:

Use date_to: "2010-12-31" to find classic papers on BDI, SOAR, ACT-R
Combine with field searches: ti:"BDI" AND abs:"belief desire intention"
Try author searches: au:"Rao" AND "BDI" for Anand Rao's foundational BDI work

ParametersJSON Schema

Name	Required	Description
`query`	Yes	Search query using quoted phrases for exact matches (e.g., '"machine learning" OR "deep learning"') or specific technical terms. Avoid overly broad or generic terms.
`max_results`	No	Maximum number of results to return (default: 10, max: 50). Use 15-20 for comprehensive searches.
`date_from`	No	Start date for papers (YYYY-MM-DD format). Use to find recent work, e.g., '2023-01-01' for last 2 years.
`date_to`	No	End date for papers (YYYY-MM-DD format). Use with date_from to find historical work, e.g., '2020-12-31' for older research.
`categories`	No	Strongly recommended: arXiv categories to focus search (e.g., ['cs.AI', 'cs.MA'] for agent research, ['cs.LG'] for ML, ['cs.CL'] for NLP, ['cs.CV'] for vision). Greatly improves relevance.
`sort_by`	No	Sort results by 'relevance' (most relevant first, default) or 'date' (newest first). Use 'relevance' for focused searches, 'date' for recent developments.

TDQS

A4.7/5.0

Behavior5/5

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

Despite no annotations, the description fully discloses behavioral traits: results sorted by relevance by default, date filtering format, category filtering recommendations, and query optimization. No contradictions or omissions.

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

Conciseness4/5

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

Well-structured with sections, examples, and readability. Slightly verbose but each section adds value. Front-loaded core purpose, but could be more concise without losing utility.

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?

Completely covers all 6 parameters with usage patterns and examples. No output schema expected; description compensates by explaining result relevance and filtering. No missing critical information for a search tool.

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

Parameters5/5

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

Schema description coverage is 100%. The description adds significant value beyond schema by explaining query syntax, category codes, date formats, and sort behavior, enabling precise use.

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?

Clearly states the tool searches for papers on arXiv with advanced filtering. Distinguishes from sibling tools like get_paper_content and list_papers by emphasizing search and filtering capabilities.

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

Usage Guidelines4/5

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

Provides extensive guidelines on query construction, category filtering, date filtering, and examples. However, it does not explicitly state when not to use the tool or directly mention alternatives, though sibling names imply use cases.

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.3.1Feb 5, 2026
- First observeddownload_paper
- First observedlist_papers
- First observedread_paper
- First observedsearch_papers

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.7/5.0

Scored 2026-04-18 06:55 across 4 tools

Disambiguation5/5

Each tool has a distinct and clear purpose: download_paper fetches new papers, list_papers shows existing resources, read_paper accesses stored content, and search_papers finds papers on arXiv. There is no overlap in functionality, making it easy for an agent to select the correct tool for any task.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern with snake_case (e.g., download_paper, list_papers, read_paper, search_papers). This uniformity enhances readability and predictability, allowing agents to easily understand and use the toolset.

Tool Count5/5

With 4 tools, the server is well-scoped for its arXiv paper management domain. Each tool serves a specific and necessary function—searching, downloading, listing, and reading papers—without being overly sparse or bloated, making it efficient for agent workflows.

Completeness5/5

The toolset provides complete coverage for the core arXiv paper workflow: search_papers finds papers, download_paper acquires them, list_papers manages resources, and read_paper accesses content. This covers the full lifecycle from discovery to consumption, with no obvious gaps for typical agent tasks.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

paper-mcp B
io.github.MCPServings
Search arXiv/Semantic Scholar/OpenAlex + medical evidence (PubMed/Europe PMC) + LaTeX/PDF tools.
Research & Data Open Data
21
IlyaGusev-academia_mcp
ai.smithery
Search arXiv and ACL Anthology, retrieve citations and references, and browse web sources to accel…
Search Research & Data Open Data
293
sec-corporate-events-mcpOAuth
com.thenextgennexus
Extract papers from ArXiv — titles, abstracts, authors, categories & PDF links. Monitor new AI, phys
Research & Data Open Data AI & Machine Learning
2
morosss-sdfsdf
ai.smithery
Find academic papers across major sources like arXiv, PubMed, bioRxiv, and more. Download PDFs whe…
Research & Data Search Open Data
2

Related MCP Servers

ArXiv MCP Server
Search Research & Data
huanongfish
A
license
B
quality
D
maintenance
Enables AI assistants to search and access arXiv research papers through a simple Message Control Protocol interface, allowing for paper search, download, listing, and reading capabilities.
Updated 2 years ago (2025-03-04 06:30 UTC)
4
7
Apache 2.0
ArXiv Paper MCP
Research & Data Search Documentation Access
BACH-AI-Tools
A
license
B
quality
D
maintenance
Enables searching, retrieving, and parsing academic papers from arXiv, including keyword search, PDF downloads, content extraction from HTML/PDF formats, and accessing the latest AI research papers.
Updated 10 months ago (2025-12-04 05:37 UTC)
4
10 npm
MIT
arXiv MCP Server
Search Research & Data Open Data
Ray0907
A
license
A
quality
B
maintenance
Enables searching and retrieving academic papers from arXiv with support for advanced filtering by author, category, and date, plus full paper content extraction.
Updated 15 days ago (2026-10-01 04:47 UTC)
6
15
MIT
search-papers
Research & Data Search Documentation Access
Saidiibrahim
A
license
Not graded
quality
C
maintenance
Enables agents to search, analyze, and explore arXiv academic papers with advanced multi-field search, author lookup, category browsing, citation extraction, and bibliography export.
Updated a year ago (2025-10-01 08:32 UTC)
29 npm
Apache 2.0

Appeared in Searches

An agent for discovering and implementing cutting-edge PhD research papers on a working codebase with explanations