Skip to main content
Glama
deenesjakoruzh
freyzo

ArXiv MCP Server

by freyzo
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

arXiv Deep Research

Install in VS Code Install in VS Code Insiders

arXiv論文の検索、ダウンロード、読み取りを行うためのModel Context Protocol (MCP) サーバーです。Microsoft Magentic-UIやAutoGenのようなマルチエージェントシステムに統合するための専門エージェントとして設計されています。

コンセプト: arXiv検索を単なるルックアップツールとして扱うのではなく、このサーバーはファーストクラスのリサーチエージェントとして構成されています。Magentic-OneスタイルのチームにMcpAgentとして直接組み込むことができ、オーケストレーターに委任可能なリソースとして科学文献全体へのアクセス権を提供します。

Magentic-UIとの統合

Magentic-UIは、設定ファイルのmcp_agent_configsを通じてカスタムMcpAgentインスタンスをサポートしています。このサーバーは直接プラグイン可能です：

# 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

登録が完了すると、Magentic-UIオーケストレーターは、標準のタスク台帳/進捗台帳パターンを通じて、このエージェントにリサーチのサブタスクを委任できます。これはWebSurferがWebブラウジングを処理するのと全く同じ方法ですが、学術文献を対象としています。

Related MCP server: ArXiv Paper MCP

AutoGen AgentChatとの統合

3つのエージェントで構成されるチームの完全な例については、examples/autogen_research_team.pyを参照してください：

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

ツール

ツール

説明

search_papers

日付範囲、カテゴリ、関連度や日付による並べ替えなどの高度なフィルターを使用してarXivをクエリします

download_paper

論文のPDFを取得し、LLMが読み取れるクリーンなマークダウンに変換します

read_paper

以前にダウンロードした論文の内容にアクセスします

list_papers

ローカルストレージ内のすべての論文を表示します

search_papers

引用符で囲まれたフレーズ、論理演算子、フィールド固有の検索（ti:、au:、abs:）、カテゴリフィルタリングなど、豊富なクエリ構文をサポートしています：

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

マルチステージ・リサーチパイプライン

高レベルでは、arxiv-deep-researchはシンプルかつ強力なマルチステージループを実行します：

  1. リサーチタスクの計画

    • コーディネーターエージェント（例：AutoGenのMagenticOneGroupChatオーケストレーター）がユーザーの目標を受け取り、サブタスクに分割します。

  2. 候補論文の発見

    • コーディネーターがMCPのsearch_papersツールを呼び出し、トピック、カテゴリ、日付に基づいて関連するarXiv論文を見つけます。

  3. コンテンツのダウンロードと正規化

    • 選択されたIDに対してdownload_paperを呼び出し、PDFを取得してLLMが読み取れるクリーンなマークダウンに変換します。

  4. 論文の詳細分析

    • コーディネーター（または別のエージェント）がdeep-paper-analysisプロンプトを使用して、特定の論文IDの構造化された分析を要求します。関連する研究を調査する際に、必要に応じて複数回呼び出すことも可能です。

  5. 統合とレポート作成

    • （AutoGenの例における）Coderのようなダウンストリームエージェントが、これらの分析を最終的なリサーチレポート（要約、比較表、未解決の問題、次のステップの提案など）にまとめます。

このパイプラインは、MCP対応クライアントからツールやプロンプトを呼び出すことで手動で実行することも、サンプルAutoGenチームを使用して自動的に実行することもできます。

評価ベンチマーク

このリポジトリには、以下を測定する検索品質ベンチマーク（eval/benchmark.py）が含まれています：

  • Precision@K — 上位K件の結果のうち関連するものの割合

  • Recall@K — 既知の関連論文のうち上位K件で見つかったものの割合

  • MRR — 最初の関連結果の平均逆順位

正解クエリは、ランドマークとなる論文（AutoGen 2308.08155、Magentic-One 2411.04468、RAG 2005.11401、CoT 2201.11903）からシードされており、以下の合成データパイプラインを使用して自動的に拡張可能です。

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

合成評価データの生成 (AgentInstructスタイル)

scripts/generate_eval_tasks.pyは、arXivの要約から多様なベンチマーククエリを生成する4ステージのパイプラインを実装しており、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

出力には、層別評価のための初級/中級/上級の難易度ティアが含まれます。

可観測性: OpenTelemetryトレーシング

すべてのツール呼び出しはOpenTelemetryスパンで計測されています（AutoGen v0.4の組み込みOTelサポートを反映）：

# 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

記録されるスパン：mcp.tool.search_papers、mcp.tool.download_paper、mcp.tool.read_paper。それぞれにクエリ、カテゴリ、結果数、レイテンシ、エラー状態が属性として含まれます。

opentelemetry-sdkがインストールされていない場合、トレーシングはコストゼロのノーオペレーション（何もしない処理）となります。

インストール

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" }
    }
  }
}

プロンプト

deep-paper-analysis

エグゼクティブサマリー、手法、結果、影響、今後の方向性を網羅した包括的な分析ワークフロー：

{ "paper_id": "2401.12345" }

リサーチセッションの実行と再開

現在、リサーチセッションを実行する主な方法は2つあります。

1. AutoGenマルチエージェントチーム（推奨デモ）

これはOpenAIモデルを使用して、完全なリサーチワークフローを調整します。

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

これにより、対話型のコンソールUIが起動します：

  • Orchestratorが作業を計画し、

  • ArxivSurferがMCP経由で論文を検索・ダウンロードし、

  • Coderが最終的なマークダウンレポートを作成します。

セッションを再開するには、以下のいずれかを行います：

  • スクリプトを再度実行し、前回の要約を新しいタスクの一部として貼り付ける、または

  • 同じコンソールセッションを開いたままにして、チームにフォローアップの指示（例：「次は安全性のトレードオフに焦点を当てて」）を出す。

2. Claude DesktopやCursorなどのツールからの直接的なMCP使用

MCPサーバーに直接話しかけて、独自のループを構築することもできます：

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

このサーバーが実行されている間、MCP対応クライアントは以下のことが可能です：

  • search_papersとdownload_paperを呼び出す、

  • read_paperを使用してチャットにコンテンツを取り込む、

  • deep-paper-analysisプロンプトを複数回呼び出す。

プロンプトハンドラーはシンプルなグローバルなリサーチコンテキストを保持しているため、同じプロセス内での繰り返しの呼び出しは、以前に分析された論文IDを参照し、モデルがそれらを関連付けることを促します。実際には、「リサーチセッションを再開する」とは以下のことを意味します：

  • 同じMCPサーバープロセスを維持し、

  • 同じクライアントまたはワークスペースから、新しい論文IDに対して新しいdeep-paper-analysis呼び出しを発行する。

リポジトリ構造

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

環境変数

変数

デフォルト

説明

ARXIV_STORAGE_PATH

~/.arxiv-mcp-server/papers

論文の保存場所

ARXIV_MCP_TRACE_CONSOLE

false

コンソールトレース出力を有効にする

OTEL_EXPORTER_OTLP_ENDPOINT

—

OTLPエンドポイント (例: http://localhost:4317)

OTEL_SERVICE_NAME

arxiv-mcp-server

トレース内のサービス名

オプションの評価データジェネレーターを使用する場合は、以下も必要です：

変数

説明

OPENAI_API_KEY

scripts/generate_eval_tasks.pyがgpt-4o-miniと通信するために使用

既知の問題

  • モデルサポートは現在OpenAIのみです。

    • AutoGenリサーチチームと合成評価ジェネレーターはどちらも、OpenAI Python SDKを介してOpenAIモデル（gpt-4o / gpt-4o-mini）を呼び出します。

    • 設計上はサポート可能ですが、google-genai / GeminiやGemmaのファーストクラスの統合はまだありません。

  • MCPリソースはまだありません。

    • 論文はMCPリソースとしてではなく、ツール（read_paper）を介してのみ公開されています。リソースを優先するMCPクライアントは、まだ論文を一覧表示できません。

  • テストが限定的です。

    • コアとなる検索および評価ロジックの自動テストは非常に軽量です。メトリック関数やツールハンドラーには、今後ユニットテストを追加する必要があります。

ロードマップ

計画されている改善点（変更される可能性があります）：

  • google-genaiによるGemini / Gemmaサポート

    • オプションのgoogle-genai依存関係と、GEMINI_API_KEYを使用してGemini/Gemmaモデルを呼び出せる小さなランナーを追加します。

    • これをリサーチチームデモと評価ジェネレーターの代替バックエンドとして公開します。

  • ダウンロード済み論文のためのMCPリソース

    • list_resources / read_resourceを実装し、ダウンロードしたPDFがMCPクライアント内でarxiv://paper_idリソースとして表示されるようにします。

  • テストと評価の強化

    • メトリック、検索ヘルパー、プロンプトハンドラーのユニットテストを追加します。

    • eval/benchmark.pyの実行を自動化し、経時的な回帰を追跡します。

  • よりリッチなリサーチセッション

    • シンプルなグローバルリサーチコンテキストを、明示的なセッションIDと永続化された状態に置き換え、「セッションXを再開」が再起動をまたいでファーストクラスの機能となるようにします。

Available Tools

4 tools
download_paperC

Download a paper and create a resource for it

ParametersJSON Schema
NameRequiredDescriptionDefault
paper_idYesThe arXiv ID of the paper to download
check_statusNoIf 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
NameRequiredDescriptionDefault

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
NameRequiredDescriptionDefault
paper_idYesThe 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
NameRequiredDescriptionDefault
queryYesSearch 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_resultsNoMaximum number of results to return (default: 10, max: 50). Use 15-20 for comprehensive searches.
date_fromNoStart date for papers (YYYY-MM-DD format). Use to find recent work, e.g., '2023-01-01' for last 2 years.
date_toNoEnd date for papers (YYYY-MM-DD format). Use with date_from to find historical work, e.g., '2020-12-31' for older research.
categoriesNoStrongly 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_byNoSort 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.

  1. 4 tool updatesv0.3.1
    • 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 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

Related MCP Connectors

Related MCP Servers

  • ArXiv MCP Server

    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.
    4
    7
    Apache 2.0

  • ArXiv Paper MCP

    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.
    4
    10 npm
    MIT

  • arXiv MCP Server

    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.
    6
    15
    MIT

  • search-papers

    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.
    29 npm
    Apache 2.0

Appeared in Searches