Skip to main content
Glama

search_papers

Search arXiv papers with advanced filtering by query, category, date, and author to find relevant academic research efficiently.

Instructions

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

Input Schema

TableJSON 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.
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 describes key behaviors: result sorting (by relevance, not just date), query optimization techniques, and the impact of parameters like categories on relevance. However, it lacks details on rate limits, error handling, or authentication needs, which are common for API tools. The description doesn't contradict any annotations (none exist), so no contradiction flag is triggered.

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

Conciseness3/5

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

The description is front-loaded with the core purpose, but it's lengthy with multiple sections (guidelines, patterns, filtering, examples, tips). While each section adds value, it could be more concise by integrating some details (e.g., merging examples into guidelines). The structure is logical but verbose, making it less efficient for quick scanning by an AI agent compared to a tighter presentation.

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 output schema, no annotations), the description is largely complete: it covers purpose, usage, parameters, and behavioral traits. However, it lacks output details (e.g., result format, pagination) and doesn't address potential errors or limits, leaving some gaps. The rich parameter explanations compensate partially, but for a search tool with no output schema, more on return values would enhance completeness.

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 100%, so the baseline is 3. The description adds significant value beyond the schema by explaining parameter semantics in depth: it provides query construction guidelines with examples, clarifies date filtering formats and use cases, details category options with relevance impacts, and explains sort_by implications ('relevance' vs. 'date'). This goes well beyond the schema's basic descriptions, though it doesn't cover all parameters equally (e.g., max_results gets less attention).

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 immediately states 'Search for papers on arXiv with advanced filtering and query optimization,' which clearly specifies the verb (search), resource (papers on arXiv), and scope (advanced filtering/optimization). It distinguishes from sibling tools like 'list_papers' (likely simpler listing) and 'download_paper'/'read_paper' (post-search actions), making the purpose specific and differentiated.

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

Usage Guidelines5/5

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

The description provides explicit guidance on when to use this tool vs. alternatives through detailed query construction guidelines, category filtering recommendations, and examples. It implicitly positions this as the primary search tool for arXiv papers with advanced capabilities, contrasting with simpler sibling tools like 'list_papers' that likely lack such filtering. The tips for foundational research further clarify usage contexts.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/blazickjp/arxiv-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server