Skip to main content
Glama
emi-dm

ArxivSearcher MCP Server

by emi-dm
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

🚀 ArxivSearcher MCP Server

An MCP server for intelligent searching of Software Engineering papers on arXiv, with advanced filtering and sorting.

Updated to v2.0! — This repository has been updated to v2.0: new remote entrypoint, prompt templates, remote-accessible PDF resources, and an upgrade to fastmcp==2.9.2.

📝 Getting Started

  1. Clone the repository

    git clone https://github.com/emi-dm/Arxiv-MCP.git
cd Arxiv-MCP

  2. Choose your setup method:

Related MCP server: arxiv-reader-mcp

🖱️ Using with Cursor

If you use Cursor, you can integrate this MCP server as follows:

  1. Open Settings in Cursor.

  2. Go to Tools & Integrations.

  3. In the MCP section, add a new server configuration.

  4. Use the same configuration as described for VS Code:

    • For Docker, use the Docker configuration block from the VS Code section.

    • For local development, use the uv configuration block from the VS Code section.

The process is analogous to the VS Code setup—just copy the relevant configuration and paste it into Cursor's MCP server settings.

📋 Prerequisites

Before you begin, make sure you have installed:

  • Python (3.11 or higher)

  • uv (a fast Python package installer and resolver)

  • Node.js and npm (for debugging with MCP Inspector)

Or alternatively:

  • Docker (for containerized deployment)

⚡️ Quickstart in VS Code

You can run the server in VS Code using Docker (recommended, you don't need the code locally), locally with uv, or consume it directly from the cloud.

Option 3: Consume the MCP server in the cloud (Recommended for quick testing!)

You don't need to install anything or clone the repository. You can consume the MCP server directly using the following configuration in .vscode/mcp.json or in your compatible MCP client:

{
  "servers": {
    "arxiv-mcp": {
      "url": "https://arxiv-mcp-sq0a.onrender.com/mcp/"
    }
  }
}

This works in both VS Code and Cursor and other compatible MCP clients.

Option 1: Using Docker (Recommended)

Note: If you use Docker, you do not need to have the code in your local directory. The container will run everything needed.

  1. Build the Docker image (only needed once or when you update the code):

    docker build -t arxiv-searcher-mcp .

  2. Create .vscode/mcp.json: In your project root, create the .vscode folder if it doesn't exist. Inside, create a file named mcp.json.

  3. Add the Docker server configuration: Copy and paste the following configuration into .vscode/mcp.json:

    {
  "mcpServers": {
    "arxiv-search": {
      "type": "stdio",
      "command": "docker",
      "args": [
        "run",
        "-i",
        "--rm",
        "arxiv-searcher-mcp"
      ]
    }
  }
}

  4. Start the server from VS Code

Option 2: Local configuration with uv (requires code locally)

  1. Create .vscode/mcp.json: In your project root, create the .vscode folder if it doesn't exist. Inside, create un archivo llamado mcp.json.

  2. Agrega la configuración local del servidor: Copia y pega la siguiente configuración en .vscode/mcp.json:

    {
  "servers": {
    "arxiv-search": {
      "command": "uv",
      "args": [
        "run",
        "${workspaceFolder}/arxiv_searcher/arxiv_mcp.py"
      ]
    }
  }
}

  3. Inicia el servidor desde VS Code

✨ Features

🛠️ Available Tools

This MCP server exposes several useful tools for searching, analyzing, and exporting arXiv papers in the field of software engineering:

  • search_papers: Searches arXiv papers filtered by the Software Engineering category (cs.SE).

    • Parameters: query, max_results, start_date, end_date, sort_by_relevance, category

    • Returns: Dictionary with the query used and the results.

  • get_paper_details: Gets detailed information about a paper by its arXiv ID.

    • Parameters: arxiv_id

    • Returns: Title, authors, abstract, dates, categories, DOI, etc.

  • search_by_author: Searches for papers by author, with optional category and date filters.

    • Parameters: author_name, max_results, category, start_date, end_date

    • Returns: List of found papers.

  • analyze_paper_trends: Analyzes trends in a collection of papers (authors, keywords, timeline, categories).

    • Parameters: papers, analysis_type

    • Returns: Statistics and analysis according to the requested type.

  • find_related_papers: Finds related papers based on the title of a reference paper, using keyword similarity.

    • Parameters: paper_title, max_results, similarity_threshold, category

    • Returns: List of similar papers.

  • download_paper_pdf: Downloads the PDF of an arXiv paper.

    • Parameters: pdf_url, save_path, filename

    • Returns: Path and status of the download.

  • export_search_results: Exports search results to various formats (bibtex, csv, json, markdown).

    • Parameters: results, format, filename, save_path

    • Returns: Path to the exported file and a preview of the content.

  • get_arxiv_categories: Returns the list of arXiv categories and their descriptions.

    • Parameters: None

    • Returns: Dictionary of categories and usage notes.

🧑‍💻 Example Usage

Here's how you can call the tool from a compatible MCP client:

@arxiv-search.search_papers(query="secure software development lifecycle from 2022", max_results=5)

This will search for the 5 most relevant papers since 2022 in the software engineering category.

🛠️ Development

📦 Install dependencies

Set up your virtual environment and install the required packages:

uv sync

Or using Docker:

docker build -t arxiv-searcher-mcp .

▶️ Run for development

Start the server directly from your terminal:

uv run --directory arxiv_searcher/ arxiv_mcp.py

🐞 Debugging

For an interactive debugging experience, use MCP Inspector:

# Option 1: Using MCP Inspector
npx @modelcontextprotocol/inspector uv run --directory arxiv_searcher/arxiv_mcp.py

# Option 2: Using fastmcp CLI
fastmcp dev arxiv_searcher/arxiv_mcp.py

When launched, the Inspector will provide a URL to view and debug server communications in your browser. Don't forget to copy the session token!

👤 Author

Developed by emi-dm.

💡 Contributions and improvements are welcome! Feel free to open a Pull Request (PR) if you have suggestions or enhancements.

Version 2.0

  • Remote-accessible resources: Added MCP resources that allow the server to expose downloaded PDF files and their extracted text (accessible via the data://downloaded_papers resource). This enables remote agents/clients to query the MCP about articles that have been downloaded to the server.

  • Prompt templates: Included a set of @mcp.prompt templates in the codebase to improve prompt quality and make it easier to craft searches (e.g., search_by_author, search_by_recent_topic, get_paper_by_id, etc.). These templates are available to clients and the Inspector to generate clearer and more consistent requests.

  • fastmcp update: The project has been updated to use fastmcp==2.9.2 (see requirements.txt / uv.lock). If you manage environments manually, please sync your environment to pick up the new fastmcp release.

Upgrade notes

  • To query downloaded papers remotely, call the data://downloaded_papers resource from your MCP client or use the provided read helpers in the MCP tools.

  • Use the prompt templates via the MCP client to get consistent, high-quality queries (the template function names are exported as prompts in the server code).

  • Run uv sync (or your preferred environment sync command) to install the pinned dependency versions after pulling this release.

📚 License

This project is licensed under the MIT License.

Available Tools

7 tools
download_paperA

Downloads the PDF of a paper to a local directory on the server. NOTE: In a stateless/free hosting environment, this file is temporary and will be deleted when the server restarts or sleeps.

:param arxiv_id: The ArXiv ID of the paper to download (e.g., '2301.12345'). :param directory: The local directory where the paper will be saved.

ParametersJSON Schema
NameRequiredDescriptionDefault
arxiv_idYes
directoryNodownloaded_papers

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4.3/5.0
Behavior4/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively explains key behaviors: the file is saved locally, and in stateless environments, it's temporary and will be deleted on server restart/sleep. This covers important operational constraints, though it doesn't mention error handling, rate limits, or authentication needs.

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 front-loaded with the core purpose in the first sentence, followed by a critical behavioral note, then parameter details. Every sentence adds value: the purpose, the temporary file warning, and parameter explanations. No wasted words, and the structure logically progresses from what to why to how.

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 2 parameters with 0% schema coverage and no annotations, the description does an excellent job explaining parameters and key behavioral traits (temporary files). The presence of an output schema means return values don't need description. It could slightly improve by mentioning error cases (e.g., invalid IDs) or success confirmation, but it's largely complete for this tool's complexity.

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 0%, so the description must fully compensate. It adds crucial semantic context for both parameters: 'arxiv_id' is explained with an example format ('e.g., '2301.12345''), and 'directory' specifies the save location and includes a default value mention. This goes well beyond the bare schema, making parameter usage clear.

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 clearly states the specific action ('Downloads the PDF of a paper') and resource ('paper'), distinguishing it from sibling tools like 'get_paper_details' (which likely retrieves metadata) or 'search_papers' (which searches). It explicitly mentions the output format (PDF) and destination (local directory), making the purpose unambiguous.

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 when a PDF download is needed, but provides no explicit guidance on when to use this tool versus alternatives like 'get_paper_details' (which might return metadata without download) or 'export_search_results' (which could export search data). The note about temporary files in stateless environments offers some context but doesn't address tool selection.

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

export_search_resultsB

Export search results to various formats.

:param results: Results from search_papers or other search functions :param format: Export format ('bibtex', 'csv', 'json', 'markdown') :param filename: Output filename (without extension) :param save_path: Directory to save the file (default: current directory)

ParametersJSON Schema
NameRequiredDescriptionDefault
resultsYes
formatNobibtex
filenameNo
save_pathNo

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

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 describes the tool as an exporter with format options and save locations, but lacks details on permissions, rate limits, error handling, or what happens during export (e.g., file creation, overwriting). For a tool with no annotations and potential side effects (file system writes), this is inadequate.

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?

The description is appropriately sized and front-loaded with the main purpose. The parameter explanations are concise and directly relevant. However, the colon-prefixed format for parameters is slightly unconventional and could be more integrated, but it doesn't waste space. Every sentence earns its place.

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?

Given the tool's complexity (4 parameters, nested objects, no annotations, but has an output schema), the description is moderately complete. It covers input semantics well but lacks behavioral context and usage guidelines. The output schema exists, so return values needn't be explained, but overall completeness is adequate with clear 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?

Schema description coverage is 0%, so the description must compensate. It adds significant meaning beyond the schema by explaining each parameter's purpose: 'results' as search results, 'format' with specific options, 'filename' as output name, and 'save_path' as directory. This clarifies semantics well, though it doesn't cover all nuances like default behaviors or constraints.

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 tool's purpose: 'Export search results to various formats.' It specifies the verb ('export') and resource ('search results'), but doesn't explicitly differentiate from sibling tools like 'download_paper' or 'analyze_paper_trends', which might have overlapping functionality. The purpose is clear but lacks sibling differentiation.

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 minimal usage guidance. It mentions that 'results' should come from 'search_papers or other search functions,' which gives some context, but doesn't specify when to use this tool versus alternatives like 'download_paper' or how it relates to other export or analysis tools. No explicit when/when-not scenarios or alternatives are provided.

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

get_paper_detailsB

Get detailed information about a specific paper by ArXiv ID.

:param arxiv_id: The ArXiv ID (e.g., '2301.12345')

ParametersJSON Schema
NameRequiredDescriptionDefault
arxiv_idYes

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

B3.2/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 states what the tool does but doesn't describe any behavioral traits such as whether it's read-only, potential rate limits, authentication needs, error handling, or what 'detailed information' entails beyond the basic operation. This leaves significant gaps in understanding how the tool behaves.

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 extremely concise and well-structured: the first sentence clearly states the purpose, and the second sentence provides essential parameter details with an example. Every sentence earns its place with no wasted words, making it easy to parse quickly.

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?

Given that there's an output schema (which handles return values), a single parameter with good semantic coverage in the description, and no annotations, the description is minimally adequate. However, it lacks context on behavioral aspects and usage guidelines relative to siblings, leaving room for improvement in completeness for effective tool selection.

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?

The description adds meaningful context for the single parameter 'arxiv_id' by explaining it's an ArXiv ID and providing an example format ('e.g., '2301.12345''). Since schema description coverage is 0% and there's only one parameter, this effectively compensates by clarifying the parameter's purpose and format, though it doesn't cover edge cases or validation rules.

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 verb ('Get detailed information') and resource ('about a specific paper by ArXiv ID'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'search_papers' or 'find_related_papers' that might also retrieve paper information but with different scopes or methods.

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. With siblings like 'search_papers' and 'find_related_papers' available, there's no indication that this tool is specifically for retrieving details when you already have an ArXiv ID, versus searching or finding related papers through other means.

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

search_by_authorB

Search papers by a specific author.

:param author_name: Name of the author to search for :param max_results: Maximum number of results :param category: Optional category filter (e.g., 'cs.SE', 'cs.AI') :param start_date: Optional start date filter (YYYY-MM-DD or YYYY) :param end_date: Optional end date filter (YYYY-MM-DD or YYYY)

ParametersJSON Schema
NameRequiredDescriptionDefault
author_nameYes
max_resultsNo
categoryNo
start_dateNo
end_dateNo

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

B3.2/5.0
Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. While 'search' implies a read-only operation, the description doesn't address important behavioral aspects: whether authentication is required, rate limits, pagination behavior, what happens when no results are found, or the format/structure of returned results. The description only states what the tool does, not how it behaves.

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 perfectly structured and concise. The purpose is stated clearly in the first sentence, followed by a well-organized parameter documentation section. Every sentence earns its place - no redundant information, no unnecessary elaboration. The parameter documentation uses a consistent format that's easy to parse.

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?

Given that there's an output schema (which handles return values), no annotations, and the description provides excellent parameter documentation, the main gap is behavioral context. The description adequately covers what the tool does and how to use its parameters, but doesn't address operational aspects like authentication, error conditions, or performance characteristics that would help an agent use it effectively.

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 0% schema description coverage, the description provides excellent parameter semantics that fully compensate. Each parameter is clearly documented with its purpose and format examples (e.g., 'YYYY-MM-DD or YYYY' for dates, 'cs.SE', 'cs.AI' for categories). The description adds substantial value beyond what the bare schema provides, explaining what each parameter means and how to format values.

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 tool's purpose: 'Search papers by a specific author.' This is a specific verb ('search') with a clear resource ('papers') and target ('by a specific author'). However, it doesn't explicitly differentiate from sibling tools like 'search_papers' - the agent must infer that this tool is author-specific while 'search_papers' might be more general.

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. With sibling tools like 'search_papers' and 'find_related_papers' available, the agent receives no explicit direction about when author-based searching is preferred over other search methods or when this tool should be avoided.

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. It can parse natural language queries, extracting keywords and years for filtering.

:param query: The base search query. Can be natural language. :param max_results: The maximum number of results to return. :param start_date: The start date for the search period (YYYY-MM-DD or YYYY). Overrides years in query. :param end_date: The end date for the search period (YYYY-MM-DD or YYYY). Overrides years in query. :param sort_by_relevance: If True, sorts by relevance. If False, sorts by submission date. :param category: The arXiv category to search in (e.g., 'cs.AI', 'cs.CL', 'cs.SE').

ParametersJSON Schema
NameRequiredDescriptionDefault
queryYes
max_resultsNo
start_dateNo
end_dateNo
sort_by_relevanceNo
categoryNocs.SE

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A3.6/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 burden of behavioral disclosure. It adds some context: it mentions natural language query parsing and date/year overriding behavior, which are useful beyond basic search functionality. However, it doesn't cover important aspects like rate limits, authentication needs, error handling, or pagination behavior, leaving gaps for a tool with 6 parameters.

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?

The description is appropriately sized and front-loaded with the core purpose. The parameter explanations are organized clearly with :param notation, though this format is more technical than natural language. Every sentence adds value, with no wasted words.

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 complexity (6 parameters, no annotations, but with output schema), the description is reasonably complete. It explains all parameters thoroughly and mentions natural language processing capabilities. The output schema existence means return values don't need explanation, but behavioral aspects like rate limits or errors could be more detailed.

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 0%, so the description must fully compensate. It provides detailed semantic explanations for all 6 parameters, including query parsing behavior, date format options, sorting logic, and category examples. This adds significant value beyond the bare schema, making parameter purposes clear.

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 tool's purpose: 'Search for papers on arXiv.' It specifies the resource (papers) and the platform (arXiv), but doesn't explicitly differentiate it from sibling tools like 'search_by_author' or 'find_related_papers' in terms of search scope or methodology.

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 'search_by_author' or 'find_related_papers.' It mentions natural language query parsing, which hints at usage context, but lacks explicit when/when-not instructions or comparisons to sibling tools.

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. 9 tool updatesv1.0.0
    • Changedanalyze_paper_trends2 fields changed
      • removedInput schema / properties / analysis_type / title
        Removed value: -"Analysis Type"
      • removedInput schema / properties / papers / title
        Removed value: -"Papers"
    • Addeddownload_paper
    • Removeddownload_paper_pdf
    • Changedexport_search_results4 fields changed
      • removedInput schema / properties / filename / title
        Removed value: -"Filename"
      • removedInput schema / properties / format / title
        Removed value: -"Format"
      • removedInput schema / properties / results / title
        Removed value: -"Results"
      • removedInput schema / properties / save_path / title
        Removed value: -"Save Path"
    • Changedfind_related_papers4 fields changed
      • removedInput schema / properties / category / title
        Removed value: -"Category"
      • removedInput schema / properties / max_results / title
        Removed value: -"Max Results"
      • removedInput schema / properties / paper_title / title
        Removed value: -"Paper Title"
      • removedInput schema / properties / similarity_threshold / title
        Removed value: -"Similarity Threshold"
    • Removedget_arxiv_categories
    • Changedget_paper_details1 field changed
      • removedInput schema / properties / arxiv_id / title
        Removed value: -"Arxiv Id"
    • Changedsearch_by_author5 fields changed
      • removedInput schema / properties / author_name / title
        Removed value: -"Author Name"
      • removedInput schema / properties / category / title
        Removed value: -"Category"
      • removedInput schema / properties / end_date / title
        Removed value: -"End Date"
      • removedInput schema / properties / max_results / title
        Removed value: -"Max Results"
      • removedInput schema / properties / start_date / title
        Removed value: -"Start Date"
    • Changedsearch_papers6 fields changed
      • removedInput schema / properties / category / title
        Removed value: -"Category"
      • removedInput schema / properties / end_date / title
        Removed value: -"End Date"
      • removedInput schema / properties / max_results / title
        Removed value: -"Max Results"
      • removedInput schema / properties / query / title
        Removed value: -"Query"
      • removedInput schema / properties / sort_by_relevance / title
        Removed value: -"Sort By Relevance"
      • removedInput schema / properties / start_date / title
        Removed value: -"Start Date"
  2. 8 tool updates
    • First observedanalyze_paper_trends
    • First observeddownload_paper_pdf
    • First observedexport_search_results
    • First observedfind_related_papers
    • First observedget_arxiv_categories
    • First observedget_paper_details
    • First observedsearch_by_author
    • 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 7 tools

Disambiguation5/5

Each tool has a clearly distinct purpose with no ambiguity: search_papers and search_by_author handle different search methods, get_paper_details retrieves metadata, download_paper fetches PDFs, find_related_papers finds similar papers, analyze_paper_trends performs analysis on results, and export_search_results handles export. The boundaries are well-defined and non-overlapping.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern with snake_case throughout: search_papers, search_by_author, get_paper_details, download_paper, find_related_papers, analyze_paper_trends, export_search_results. This uniformity makes the toolset predictable and easy to navigate.

Tool Count5/5

With 7 tools, this server is well-scoped for arXiv paper searching and management. Each tool serves a specific function in the workflow (search, retrieve, analyze, export), and none feel redundant or missing, fitting within the typical 3-15 tool range for a focused domain.

Completeness4/5

The toolset covers core arXiv operations comprehensively: searching (by query and author), retrieving details and PDFs, finding related papers, analyzing trends, and exporting results. A minor gap is the lack of tools for user account management (e.g., saving favorites) or paper submission, but these are outside the primary search-focused scope, so agents can work effectively with the provided tools.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

Appeared in Searches