Skip to main content
Glama

Arxiv Search Papers

arxiv_search_papers
Read-only

Search arXiv papers by query with category and sort filters. Returns paper metadata including title, authors, abstract, categories, and links.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
queryYesSearch query. Field prefixes: ti: (title), au: (author — token-based; quote multi-token names like au:"hinton g" or pair with a topical clause to disambiguate common surnames), abs: (abstract), cat: (category — a leaf code matches exactly, a bare archive code such as cat:astro-ph matches its whole subtree), co: (comment), jr: (journal ref), all: (all fields). Boolean operators: AND, OR, ANDNOT. Examples: "au:bengio AND ti:attention", "all:transformer AND cat:cs.CL".
startNoPagination offset (0-10000). Use with max_results to page through results. E.g., start=10 with max_results=10 returns results 11-20. arXiv serves only the first 10000 results of a query, so a page reaching past result 10000 can come back cut short at it and a start of 10000 can be refused. To reach later matches, carve the search into submitted_from/submitted_to windows and page within each.
sort_byNoSort criterion. Use "submitted" for newest papers, "relevance" for best query matches.relevance
categoryNoRestrict results to an arXiv category. A leaf code ("cs.CL", "math.AG") matches exactly. A bare archive code ("astro-ph", "cond-mat", "cs", "math") matches the whole archive — its subject classes plus the legacy flat papers filed before the archive was subdivided. Note "physics" is the general-physics archive (physics.*), not the wider physics group: astro-ph, cond-mat, hep-*, quant-ph and the rest are separate archive codes. Use arxiv_list_categories to discover subject classes.
sort_orderNoSort direction. "descending" returns newest/most relevant first.descending
max_resultsNoMaximum results to return. Default 10. At most 50 are returned per call: a larger value returns the first 50, and when more matches exist the response says how to reach them — the start of the next page, or date windows once paging cannot reach them all. arXiv serves only the first 10000 results of a query, so a page reaching past result 10000 can come back cut short at it, and the response says so. Each result includes title, authors, abstract, and metadata — keep low to limit response size.
submitted_toNoLatest submission date to include, inclusive, as a UTC YYYY-MM-DD date. Omit for no upper bound. Both bounds are inclusive, so consecutive windows ("2024-01-01".."2024-01-15" then "2024-01-16".."2024-01-31") cover the matches with no gap; a paper submitted at exactly the midnight seam between two windows appears in both, so de-duplicate collected results by paper id. That is the way to reach matches past the start ceiling: split the date range, then page within each window.
submitted_fromNoEarliest submission date to include, inclusive, as a UTC YYYY-MM-DD date. Omit for no lower bound.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
capNoThe page size applied: max_results, or 50 when max_results asks for more — fewer when the page was cut short at result 10000, the last one arXiv serves.
errorNoPresent when the call failed. Absent on success.
shownNoPapers returned on this page.
noticeNoRecovery guidance when results are empty or paging overshot. Absent on successful pages.
papersNoMatching papers with full metadata.
pageStartNoPagination offset of this result page.
truncatedNoTrue when more matching papers exist beyond this page (totalFound > start + shown).
totalFoundNoTotal matching papers reported by arXiv (before pagination).
effectiveQueryNoThe query as actually searched, carrying every filter applied — the category subtree and submitted-date window folded into arXiv syntax alongside the supplied terms. Replaying it as `query` with no other filters reproduces this exact result set.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedOutput schema / properties / error / properties / data / properties / reason / description
      Previous value: -"Machine-readable failure mode. Declared by this tool: `unknown_category`: Provided category code is not part of the arXiv taxonomy. `rate_limited`: arXiv has throttled requests (HTTP 429 or \"Rate exceeded.\" body). `invalid_request`: arXiv rejected the request (HTTP 4xx other than 429), typically malformed query syntax. `unsupported_query_syntax`: Query translates to a mirror FTS5 expression the search engine cannot parse, typically two operands juxtaposed across a parenthesized group without an explicit operator. `invalid_date_range`: submitted_from or submitted_to is not a real UTC calendar date, or the window starts after it ends. `start_beyond_result_limit`: start is 10000 or more on a search arXiv answers, past the first 10000 results it serves for any query. Other values are possible when a failure originates below the handler."New value: +"Machine-readable failure mode. Declared by this tool: `unknown_category`: Provided category code is not part of the arXiv taxonomy. `rate_limited`: arXiv has throttled requests (HTTP 429 or \"Rate exceeded.\" body). `invalid_request`: arXiv rejected the request (HTTP 4xx other than 429), typically malformed query syntax. `unsupported_query_syntax`: The mirror search engine rejected the FTS5 expression the query translated to. Every query the translator accepts is meant to parse, so this marks a translator defect. `invalid_date_range`: submitted_from or submitted_to is not a real UTC calendar date, or the window starts after it ends. `start_beyond_result_limit`: start is 10000 or more on a search arXiv answers, past the first 10000 results it serves for any query. Other values are possible when a failure originates below the handler."
  2. Added

TDQS

B3.2/5.0
Behavior3/5

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

Annotations declare readOnlyHint=true, so the safety profile is already covered. The description adds that results are read-only metadata (title, authors, abstract, categories, links) but omits the operationally important limits documented only in the schema (50 results per call cap, 10000-result ceiling, paging cutoffs), so it adds modest value beyond structured fields.

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?

Two sentences, front-loaded with the action and scope, with no wasted words. It is arguably too terse given the tool's complexity, but nothing is redundant or padded.

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?

With an output schema present, the description need not enumerate return values, and the input schema exhaustively covers pagination, date windows, and category semantics. The gap is the absence of sibling-routing guidance, which is minor for a straightforward search tool.

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

Parameters3/5

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

Schema description coverage is 100%, so every parameter including the rich field-prefix and date-window semantics is already documented. The description only gestures at 'category and sort filters' and the returned fields, adding essentially nothing beyond the schema baseline.

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?

States a specific verb and resource ('Search arXiv papers') plus the filter dimensions (query, category, sort), which clearly separates it from arxiv_get_metadata, arxiv_read_paper, and arxiv_list_categories. It does not, however, explicitly contrast itself with those siblings, so an agent must infer the distinction from names alone.

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 offers no when-to-use or when-not-to-use guidance: it never says to use this tool for discovery and arxiv_get_metadata/arxiv_read_paper for retrieval. The only routing hint ('Use arxiv_list_categories to discover subject classes') lives inside the category parameter schema, not the description.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.