biorxiv-mcp-server

List Recent Preprints

biorxiv_list_recent

Read-only

List preprints posted or revised within a date interval, optionally scoped to one server or a subject category. Returns 30 preprints per page (fixed by the API); pass cursor as an integer offset (0, 30, 60, …) to step through additional pages. When server="both" (default), per-server pagination state is returned separately — use each server's cursor field for independent advancement. One server failing under server="both" does not abort the call: the other server's page is still returned and the failed one is named in failed[], marking the result set as partial rather than complete. Every attempted server failing is a different case and does abort the call, with a retryable upstream_unavailable (or rate_limited) error — an empty page would otherwise be indistinguishable from an interval that genuinely holds nothing. Call biorxiv_list_categories for valid category strings.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`cursor`	No	Integer page offset (0, 30, 60, …). Defaults to 0 (first page).
`server`	No	Server to query. "both" fans out to bioRxiv and medRxiv in parallel.	both
`category`	No	Subject category filter. Use biorxiv_list_categories for valid values.
`end_date`	Yes	End of the date interval (YYYY-MM-DD).
`start_date`	Yes	Start of the date interval (YYYY-MM-DD).

Output Schema

TableJSON Schema

Name	Required	Description
`error`	No	Present when the call failed. Absent on success.
`failed`	No	Servers that did not answer, so their records are missing from "preprints" and they have no "pagination" entry. Non-empty means this result set is partial — retry to include them. Only populated when server="both", and never holding every attempted server: when none answered, the call fails with upstream_unavailable or rate_limited instead of returning a page. A single-server failure likewise surfaces as a tool error. Distinct from an exhausted pagination entry, where the server answered.
`notice`	No	Guidance on how to read this result set: which servers did not answer, which cursors are past the end, and — when nothing came back — the applied filters and how to broaden them. All applicable qualifications are composed into one string.
`preprints`	No	Preprints in the requested date interval.
`pagination`	No	Per-server pagination state. Advance each server independently.
`categoryNote`	No	Present when server="both" and the category exists in only one server's taxonomy. Explains which server was queried and why the other was excluded.

Schema Changelog

Changes observed during successful MCP inspections.

First observedSep 19, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Goes far beyond the readOnlyHint/openWorldHint annotations: discloses fixed 30-per-page pagination, integer-offset cursor semantics, per-server cursor state under server="both", partial-failure semantics (one server failing yields a partial result with failed[]), and full-failure semantics (abort with retryable upstream_unavailable/rate_limited). Even explains the rationale (empty-page ambiguity), which materially helps an agent interpret results and decide retries. Consistent with annotations — no contradiction.

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?

Six sentences, each earning its place: purpose first, then pagination mechanics, then dual-server pagination, then partial and full failure modes, then category routing. It is front-loaded and logically ordered. The length is fully justified by the genuinely complex behavioral semantics (partial results, per-server cursors, retryable errors) that an agent must understand to use the tool correctly.

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?

Given an output schema exists (return shape need not be described) and annotations cover the safety profile, the description covers every operationally critical aspect: page size, cursor stepping, dual-server pagination, partial vs. aborted failure, retryable error types, and where to obtain valid category strings. Nothing an agent needs to invoke or interpret this tool correctly is missing.

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 coverage is 100%, so baseline is 3; the description adds genuine value on top. For `cursor` it explains the fixed page size and offset stepping (0, 30, 60…); for `server` it details the 'both' fan-out consequences, per-server pagination, and failure behavior; for `category` it routes to the authoritative source. Only start_date/end_date add nothing beyond the schema, which is fine since the schema already specifies YYYY-MM-DD.

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 opens with a specific verb+resource+scope: 'List preprints posted or revised within a date interval, optionally scoped to one server or a subject category.' This clearly distinguishes it from sibling tools: search_preprints (query-based), get_preprint/get_fulltext/get_published_version (single-item retrieval), and list_categories (categories, not preprints).

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 intended use context is clear — browsing preprints by date interval with optional server/category scoping — and it explicitly routes to biorxiv_list_categories for valid category values. However, it never contrasts itself with biorxiv_search_preprints or states when NOT to use this tool, leaving the list-vs-search decision to inference.

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

All biorxiv-mcp-server tools Inspect

Try in Browser

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

Glama MCP Gateway

Add one secure layer between your agents and this server.