biorxiv-mcp-server
Server Details
Search and retrieve bioRxiv and medRxiv preprints — by DOI, date interval, or keyword — via MCP.
- Status
- Healthy
- Uptime
- 99.9% over 43 days
- Last Tested
- Transport
- Streamable HTTP · MCP 2025-11-25
- URL
- Repository
- cyanheads/biorxiv-mcp-server
- GitHub Stars
- 4
- Server Listing
- @cyanheads/biorxiv-mcp-server
TDQS
Scored across 7 tools
Each tool targets a distinct resource+action: full text extraction, preprint metadata, journal crosswalk, category listing, two clearly differentiated date-based listings (posting vs journal publication), and keyword/author search. The descriptions explicitly cross-reference each other (e.g. get_published_version is framed as what to call after get_preprint reveals a publishedJournalDoi), resolving the only plausible confusions around DOI-based lookups.
All seven tools use a uniform biorxiv_ prefix followed by a verb_noun pattern (get_fulltext, get_preprint, get_published_version, list_categories, list_published_versions, list_recent, search_preprints). No mixed conventions or stylistic drift.
Seven tools map cleanly onto a preprint server's core jobs: metadata, full text, publication crosswalk, categories, recent listings, published-version listings, and search. Nothing feels redundant or missing at the count level.
The surface covers the full lifecycle well — discovery, metadata, full text, and preprint-to-journal crosswalk in both directions, with batch and pagination handling. Minor gaps: table cells must be fetched from an external URL outside the tool set, and there is no tool for retrieving a journal version's full text, which the description hints at as a richer alternative.
Available Tools
7 toolsbiorxiv_get_fulltextGet Preprint Full TextARead-onlyInspect
Retrieve a preprint's full text as best-effort Markdown, extracted from its rendered HTML article page. Reads the latest version unless one is requested (the version input, or a vN suffix on the DOI), confirms it via the details API, then fetches and extracts the body — abstract, sections, inline citation labels, and the reference list. Table cells are not on the article page: each table appears as its caption, and omittedTables names it with the URL that serves its cells. bioRxiv and medRxiv share the 10.1101/ DOI prefix, so server="both" (the default) resolves the DOI against both in parallel and the response reports which server answered. This is HTML-to-Markdown extraction, not structured JATS: section structure is approximate and not guaranteed. Long articles exceed a single response, so use offset and limit to page through them (the response reports totalChars, remainingChars, and hasMore); paging is cheap because the extracted article is cached per version for an hour after the first read, so only the first chunk pays for a fetch. Not every preprint has an extractable HTML page — some are PDF-only and some origins block programmatic access — in which case a fulltext_unavailable error routes you to biorxiv_get_preprint for the title, metadata, and current abstract. For a preprint that has been published in a journal, the journal's version may have richer full text elsewhere.
| Name | Required | Description | Default |
|---|---|---|---|
| doi | Yes | Preprint DOI (e.g. 10.1101/2024.05.28.596311 or 10.64898/2026.05.07.723463). A doi.org or biorxiv.org/medrxiv.org article URL, a doi: prefix, or a .full suffix is accepted and stripped; a trailing vN (…596311v2) requests that version. Without one, the latest version is resolved automatically. | |
| limit | No | Maximum number of characters to return in this chunk. Default 20,000; a value past the remaining text returns the rest of the article. Check the length field for the actual count returned. | |
| offset | No | Character offset into the full extracted text at which to start reading. 0 returns the beginning. To read the next chunk, use offset = prior_offset + prior_length (the length field from the previous response). | |
| server | No | Server the preprint was posted on. "both" (default) checks bioRxiv and medRxiv in parallel to resolve the DOI — the full-text fetch itself only ever targets whichever server resolved, and the output server field names it. | both |
| version | No | Preprint version to read (1, 2, …) — the revision numbers biorxiv_get_preprint lists. Omit for the latest version. Must match a vN suffix on the DOI when both are given. |
Output Schema
| Name | Required | Description |
|---|---|---|
| cap | No | The limit (max characters) applied to this chunk. |
| doi | No | The resolved preprint DOI, in bare form. |
| error | No | Present when the call failed. Absent on success. |
| shown | No | Characters returned in this chunk. |
| title | No | Article title detected during extraction. Absent when the page exposed none. |
| length | No | Number of characters returned in this chunk. |
| notice | No | Paging guidance when the content was truncated — how to fetch the next chunk. |
| offset | No | Character offset into the full extracted text where this chunk begins. |
| server | No | Server the preprint was resolved on. |
| content | No | The requested chunk of full text as best-effort Markdown extracted from the rendered HTML page. Section structure is approximate — this is not JATS. |
| hasMore | No | True when more text follows this chunk. When true, call again with offset = offset + length. |
| version | No | Preprint version whose full text was retrieved — the requested one, or the latest revision when none was requested. Pass it back as version when paging. |
| sourceUrl | No | The full-text HTML page the content was extracted from. |
| truncated | No | True when this chunk was capped by limit and more text remains. |
| wordCount | No | Approximate word count of the FULL extracted article, not just the returned chunk — whitespace-delimited tokens of the same Markdown text that totalChars measures, so Markdown markers such as # and - count too. |
| totalChars | No | Total characters in the full extracted text. Use with offset and length to page through long articles. |
| contentFormat | No | How content was produced: Markdown extracted from the rendered HTML article page (constant). |
| omittedTables | No | Tables the article page names without their cells — content keeps each one's caption, and the cells live on a separate page at url. The same list on every chunk. Absent when the article has none. |
| remainingChars | No | Characters remaining after this chunk (totalChars - offset - length). 0 means this chunk reaches the end. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Rich beyond annotations: HTML-to-Markdown not JATS, approximate section structure, per-version one-hour cache, offset/limit paging with totalChars/hasMore, table cells omitted with omittedTables URLs, and parallel server resolution. Annotations already declare readOnly/openWorld, so safety needs no restating. Slightly docks for not stating return shape explicitly, though output schema may cover it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core action, then progressively elaborates paging, caching, and failure modes. Dense but every clause carries meaning; long, yet justified by a 5-param tool with several caveats.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an output schema exists and return values needn't be re-explained, the description is complete: it covers extraction fidelity, paging, caching, table-cell omission, error routing, and version handling — everything an agent needs to call and interpret it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 value by explaining offset/limit paging strategy, the caching that makes paging cheap, version resolution order, and the server='both' parallel resolution. Much is duplicative of the schema, keeping it below 5.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Retrieve a preprint's full text as best-effort Markdown') plus the extraction method, and explicitly distinguishes itself from biorxiv_get_preprint (metadata/abstract) and the journal's version. An agent can tell exactly what this returns vs. siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit routing: fulltext_unavailable error -> use biorxiv_get_preprint; published preprints -> journal version may be richer elsewhere. Covers the PDF-only/blocked-origin exclusions and when to page with offset/limit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
biorxiv_get_preprintGet Preprint by DOIARead-onlyIdempotentInspect
Fetch full metadata, the abstract, all revision history, JATS XML full-text links, and published-journal DOI for one or more preprints by DOI. Each DOI returns all revisions in one response, with the abstract on the latest revision only — the API keeps one abstract per preprint. Each call looks up the first 10 distinct DOIs and returns the rest, never looked up, in unprocessed[] — pass that list as dois in another call to continue; a repeated DOI is looked up once and an unparseable entry is reported in failed[], so neither counts toward the 10. When server="both" (default), each DOI is checked against both bioRxiv and medRxiv; the response includes which server the preprint was found on. Failed lookups are reported per-DOI in failed[] rather than aborting the batch, each carrying a reason (not_found, invalid_doi_format, upstream_unavailable, rate_limited) and a retryable flag; a rate_limited entry also carries the wait in seconds the origin asked for. preprints[], failed[], and unprocessed[] follow input order. DOIs must match the pattern 10.NNNN/…; a doi.org or article URL, a doi: label, and a trailing vN / .full suffix are stripped first, and results report the bare DOI.
| Name | Required | Description | Default |
|---|---|---|---|
| dois | Yes | Preprint DOIs to look up, up to 200 entries. The first 10 distinct DOIs are looked up; the rest are returned in unprocessed. | |
| server | No | Server to query. "both" checks bioRxiv and medRxiv in parallel for each DOI. | both |
Output Schema
| Name | Required | Description |
|---|---|---|
| cap | No | The most distinct DOIs one call looks up. |
| error | No | Present when the call failed. Absent on success. |
| shown | No | Distinct DOIs looked up in this call. |
| failed | No | DOIs that could not be resolved, with per-DOI error details. |
| notice | No | How to look up the DOIs left in unprocessed, and how many failed[] entries are retryable alongside them. |
| preprints | No | Successfully resolved preprints with their full revision history. |
| truncated | No | True when DOIs past the first 10 were left in unprocessed. |
| unprocessed | No | Valid, distinct DOIs past the first 10, in input order — not looked up, so neither found nor failed. Pass this list as dois in another call to continue. Empty when every DOI was looked up. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes far beyond the readOnly/idempotent/openWorld annotations: documents the 10-distinct-DOI lookup cap, dedup and unparseable handling, per-DOI failure reasons (not_found, invalid_doi_format, upstream_unavailable, rate_limited) with retryable flags, and rate-limit wait seconds. It also discloses abstract-on-latest-revision-only and result ordering — behavioral facts an agent cannot infer from annotations or schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with what is returned, then batch semantics, then failure modes — a sensible order with no filler. Sentences are long and heavily packed with clauses, which slightly taxes scanning but every clause carries information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return-value detail is not required, and the description still covers batching limits, continuation flow, error surface, and server resolution. Nothing an agent needs to invoke this correctly — including how to page through >10 DOIs — is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 earns above that by adding semantics not in the schema fields: a repeated DOI is looked up once, unparseable entries land in failed[], and neither counts toward the 10. DOI normalization rules and server parallel lookup largely duplicate schema text, capping the score at 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb (fetch) plus a precise resource enumeration (metadata, abstract, revision history, JATS links, published DOI) scoped to one or more DOIs. The inclusion of 'published-journal DOI' alongside the sibling biorxiv_get_published_version and 'JATS XML full-text links' next to biorxiv_get_fulltext signals what this tool consolidates rather than merely restating the title.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Clearly explains operational usage: pass unprocessed[] back as dois to continue, and server="both" checks both repositories by default. It does not explicitly state when to prefer this over biorxiv_get_fulltext or biorxiv_get_published_version, so no explicit exclusions/alternatives routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
biorxiv_get_published_versionGet Published Journal VersionARead-onlyIdempotentInspect
Resolve a DOI to its preprint-to-journal crosswalk record — preprint DOI, journal DOI, journal name, published date, and corresponding author details — from either side: a preprint DOI (10.1101/ or 10.64898/) finds the journal article it was published as, and any other DOI is read as a journal article's and finds the bioRxiv or medRxiv preprint it was posted as. Use when biorxiv_get_preprint shows a publishedJournalDoi and you need the journal details, or when you hold a journal article and want its preprint. bioRxiv and medRxiv share their DOI prefixes, so server="both" (the default) checks both in parallel and the response reports which server answered. When the crosswalk holds no record for a published preprint, the journal DOI still comes back from the preprint's own record, without journal name or date, and a notice says so. Returns a not-found error when no server holds the preprint, it lists no journal version, or no preprint is recorded for the journal DOI.
| Name | Required | Description | Default |
|---|---|---|---|
| doi | Yes | DOI to resolve: a preprint DOI (e.g. 10.1101/2024.01.15.575123 or 10.64898/2026.05.07.723463) or a journal article DOI (e.g. 10.1016/j.cell.2020.01.001). A doi.org or biorxiv.org/medrxiv.org article URL or a doi: prefix is accepted and stripped to the bare DOI, as is a vN, .full, or .pdf suffix; a journal DOI keeps its own components (10.7554/eLife.55185.sa1 is not 10.7554/eLife.55185). Cold Spring Harbor Laboratory Press journal DOIs (10.1101/gr.…, 10.1101/gad.…, 10.1101/lm.…) share the preprint prefix and cannot be resolved by DOI. | |
| server | No | Server the preprint was posted on. "both" (default) checks bioRxiv and medRxiv in parallel — use it when the DOI alone does not tell you which server holds the preprint. | both |
Output Schema
| Name | Required | Description |
|---|---|---|
| error | No | Present when the call failed. Absent on success. |
| notice | No | Present when publishedDoi came from the preprint's own record because the crosswalk had none: says why publishedJournal and publishedDate are absent. |
| server | No | The server that returned this published record — never "both". |
| preprintDoi | No | The preprint DOI, in bare form: the input itself when it was a preprint DOI, or the preprint the crosswalk links to the input when it was a journal DOI. |
| preprintDate | No | Preprint posting date (YYYY-MM-DD) from the crosswalk record, or from the preprint's first revision when the crosswalk has none — the first posting for most preprints. medRxiv records some 10.64898/ preprints twice with different posting dates; this is the first record listed. |
| publishedDoi | No | The journal publication DOI. |
| preprintTitle | No | Title of the preprint. |
| publishedDate | No | Journal publication date (YYYY-MM-DD). Absent when the crosswalk holds no record for this preprint — see notice. |
| preprintAuthors | No | Preprint author list. |
| preprintAbstract | No | Preprint abstract. |
| preprintCategory | No | Subject category. |
| publishedJournal | No | Name of the publishing journal. Absent when the crosswalk holds no record for this preprint — see notice. |
| preprintAuthorCorresponding | No | Corresponding author name. |
| preprintAuthorCorrespondingInstitution | No | Corresponding author institution. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only cover readOnly/openWorld/idempotent, but the description adds real operational context: server="both" queries both servers in parallel and the response reports which one answered, the degraded case where a journal DOI returns without journal name or date plus an explanatory notice, and the exact not-found conditions. It also flags a genuine edge case (CSHL Press 10.1101/gr., gad., lm. DOIs sharing the preprint prefix).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single dense block, but front-loaded with the action and return shape before moving to usage, server behavior, and error semantics. Almost every clause carries information; the field enumeration is slightly redundant given an output schema exists.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter read tool with full schema coverage and an output schema, nothing an agent needs is missing: direction rules, default server behavior, partial-result semantics, and failure modes are all stated. The field list is a bonus rather than a necessity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3; the description goes beyond it by explaining the direction semantics tied to DOI prefix (10.1101/ and 10.64898/ mean preprint, anything else means journal) and by explaining why the default server="both" exists and what the response reports. It doesn't restate the normalization rules, but the schema already owns those.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource — 'Resolve a DOI to its preprint-to-journal crosswalk record' — and enumerates the returned fields (preprint DOI, journal DOI, journal name, published date, author details). It also clarifies the bidirectional resolution (preprint DOI → journal article, any other DOI → preprint), which makes it unmistakable versus the sibling list/search tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Names an explicit trigger and its alternative: 'Use when biorxiv_get_preprint shows a `publishedJournalDoi` and you need the journal details, or when you hold a journal article and want its preprint.' That is a concrete when-to-use routed through a named sibling rather than an inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
biorxiv_list_categoriesList bioRxiv/medRxiv CategoriesARead-onlyIdempotentInspect
List valid subject category strings for bioRxiv and medRxiv — the categories the listing API actually filters on. Use these strings as the category filter in biorxiv_list_recent to narrow results to a specific field; case, and "_" or "-" in place of a space, do not matter there. Run this tool before filtering to get the current valid values.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| error | No | Present when the call failed. Absent on success. |
| biorxiv | No | bioRxiv subject categories |
| medrxiv | No | medRxiv subject categories |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=false, and idempotentHint=true, covering safety and idempotency. The description adds valuable context: these are the actual filter values the API uses, and they represent 'current valid values,' implying they may change over time. This goes beyond the annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, information-dense sentence that front-loads the core purpose and then provides usage guidance. It avoids redundancy and every clause adds value, though it could be slightly more compact by splitting into two sentences. It earns a 4 for efficiency without being overly terse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and the presence of an output schema (which likely describes the list format), the description fully covers what the tool does, how to use it, and its role relative to siblings. It includes the important nuance that these are the authoritative filter values and that they are current, making it complete for an agent to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description doesn't need to explain parameter semantics. Per the rubric, a baseline of 4 is appropriate when there are no parameters; the description correctly omits any parameter discussion, and the schema coverage is 100% (trivially, since there are none).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists valid subject category strings for bioRxiv and medRxiv, and explicitly identifies these as the categories the listing API filters on. It distinguishes itself from sibling tools that fetch or search content, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly instructs the agent to use the returned strings as the `category` filter in biorxiv_list_recent, notes that case and separators are irrelevant, and advises running this tool before filtering. This gives clear when-to-use and how-to-use guidance, and implicitly tells the agent when not to use it (i.e., when needing content rather than categories).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
biorxiv_list_published_versionsList Published Journal VersionsARead-onlyInspect
List preprints that appeared as journal articles within a journal publication-date interval, each with its journal DOI, journal name, publication date, and preprint metadata — the same record biorxiv_get_published_version returns for one DOI. The dates filter on journal publication, not preprint posting, so most rows were posted months or years earlier; use biorxiv_list_recent for preprints posted in an interval. publisher, a journal DOI prefix such as 10.7554 for eLife, limits the listing to the bioRxiv preprints published under it; those rows carry no journal name, authors, or abstract, and a prefix api.biorxiv.org does not recognize raises invalid_publisher. Returns limit publications per server (default 25, up to 100 — the page api.biorxiv.org serves; a larger limit returns 100 and says so). Continue at the nextCursor a page returns rather than stepping cursor by a fixed amount; limit: 100 walks an interval in the fewest calls. When server="both" (default), per-server pagination state is returned separately, since one cursor can be past the end of one server and inside the other — to continue a single server, pass its nextCursor with server set to that server. 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[]. Every attempted server failing raises a retryable upstream_unavailable (or rate_limited) error rather than an empty page. Abstracts are omitted by default to keep the page small — pass include_abstract: true for the whole page. Every preprintDoi, 10.1101/ and 10.64898/ alike, is accepted by biorxiv_get_preprint and the other DOI tools.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Rows to return per queried server, starting at cursor. Defaults to 25. Up to 100, the page api.biorxiv.org serves: a larger value returns 100 rows per server and says so in the notice. limit: 100 walks an interval in the fewest calls. | |
| cursor | No | Integer row offset, applied to each queried server. Defaults to 0 (first page). To continue, pass the nextCursor the previous page returned for that server — it advances by the rows actually served. | |
| server | No | Preprint server to list. "both" lists bioRxiv and medRxiv in parallel; their rows do not overlap. | both |
| end_date | Yes | End of the journal publication-date interval (YYYY-MM-DD), inclusive. | |
| publisher | No | Journal publisher filter: the DOI prefix its journal articles share, the part before the slash — "10.7554" for eLife, "10.1016" for Elsevier. Lists only the bioRxiv preprints published under that prefix: medRxiv has no publisher listing, so server="both" queries bioRxiv alone and server="medrxiv" is rejected. Rows listed this way carry no journal name, authors, corresponding author, or abstract. | |
| start_date | Yes | Start of the journal publication-date interval (YYYY-MM-DD), inclusive. | |
| include_abstract | No | Include each preprint's abstract. Defaults to false: abstracts make up about three quarters of a page, and every other field is returned either way. |
Output Schema
| Name | Required | Description |
|---|---|---|
| cap | No | Most publications this page can hold: rows per server (limit, or 100 when limit asked for more) times the servers queried. Set with truncated. |
| error | No | Present when the call failed. Absent on success. |
| shown | No | Publications on this page, across every server queried. Set with truncated. |
| failed | No | Servers that did not answer, so their rows are missing from "publications" and they have no "pagination" entry. Non-empty means this result set is partial — retry to include them. Only populated under server="both", and never holding every attempted server: when none answered, the call fails with upstream_unavailable or rate_limited instead. 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, that a publisher filter limited server="both" to bioRxiv and which fields its rows lack, a limit above the 100-row page, which cursors are past the end, which servers have rows past this page, and — when nothing came back — the interval and how to broaden it. All applicable qualifications are composed into one string. |
| truncated | No | True when at least one server has rows past this page — continue at that server's nextCursor. Absent when every server queried is on its last page. |
| pagination | No | Per-server pagination state. Advance each server independently. |
| publications | No | Publications in the interval, in upstream order: bioRxiv rows first, then medRxiv rows. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Well beyond the readOnlyHint/openWorldHint annotations, it discloses limit clamping to 100 with a notice, cursor semantics, per-server pagination state under server="both", partial-failure behavior via failed[], retryable upstream_unavailable/rate_limited when all servers fail, invalid_publisher on unrecognized prefixes, and that abstracts are omitted by default for page size.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose and alternatives, and nearly every sentence carries operational information, but it is a single very dense paragraph mixing purpose, filtering, pagination, error handling, and output shape. Light structure (e.g., separating pagination and error semantics) would improve scanability without losing content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 7-parameter tool with an output schema, it covers everything an agent needs: date semantics, server scope, publisher restrictions, page-size ceiling, continuation strategy, and failure modes. Return shape is summarized rather than restated, appropriate given the output schema exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, yet the description still adds meaning: publisher is a DOI prefix (10.7554 for eLife) and its rows carry no journal name, authors, or abstract; a larger limit returns 100 rather than the schema's 1000 maximum; and continue from nextCursor rather than stepping cursor by a fixed amount.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The opening clause names a specific verb and resource — listing preprints that became journal articles within a journal publication-date interval — and immediately disambiguates from biorxiv_get_published_version (single DOI) and biorxiv_list_recent (preprint posting dates). An agent can pick the right tool without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit routing: 'The dates filter on journal publication, not preprint posting, so most rows were posted months or years earlier; use biorxiv_list_recent for preprints posted in an interval.' It also states when publisher is applicable (bioRxiv only, medrxiv rejected) and how to continue per server under server="both".
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
biorxiv_list_recentList Recent PreprintsARead-onlyInspect
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. Abstracts are omitted by default to keep the page small — pass include_abstract: true for the whole page (each row carries the latest-revision abstract of its preprint, whichever revision the row is), or call biorxiv_get_preprint (up to 10 DOIs per call) for a few. 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; a server that answers a category filter with its unfiltered listing is left out with a notice, and invalid_category is raised when no server applied it. funder limits the listing to bioRxiv preprints funded by that organization, given its ROR ID; an ID api.biorxiv.org has no funder record for raises invalid_funder rather than returning an empty page.
| Name | Required | Description | Default |
|---|---|---|---|
| cursor | No | Integer page offset (0, 30, 60, …). Defaults to 0 (first page). | |
| funder | No | Funder filter: the funder's ROR ID, bare ("021nxhr62" for the US National Science Foundation) or as a URL ("https://ror.org/021nxhr62"). bioRxiv only — medRxiv records carry no funder data, so server="both" queries bioRxiv alone and server="medrxiv" is rejected. Combines with category. Look the ID up by name at ror.org. | |
| server | No | Server to query. "both" fans out to bioRxiv and medRxiv in parallel. | both |
| category | No | Subject category filter, matched case-insensitively with "_" and "-" read as a space — "Cell Biology", "cell biology", "cell_biology", and "cell-biology" are the same 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). | |
| include_abstract | No | Include each preprint's abstract. Defaults to false: abstracts make up about three quarters of a page, and every other field is returned either way. |
Output 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 ignored the category filter (their unfiltered records are left out), that a funder filter limited server="both" to bioRxiv, 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. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, so safety profile is covered; the description still adds substantial value beyond that: fixed 30-per-page size, per-server cursor advance under server="both", partial results via failed[], and distinct error semantics (upstream_unavailable, rate_limited, invalid_category, invalid_funder). With annotations present the bar is lower, but the disclosure here is richer than a 3 usually implies — the justification for 3 rather than 4 is that return shape details are partly delegated to the output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core purpose and scoping, and nearly every sentence carries operational information (page size, cursor stepping, failure semantics). It is dense as a single paragraph and would scan faster with bullets, but nothing is filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values needn't be spelled out, and the description still covers the non-obvious gaps: pagination limits, partial-failure handling, error codes, and funder/category validation paths. An agent has everything needed to call it correctly and interpret degraded results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 earns above baseline by explaining cross-parameter interactions the schema does not: per-server cursor state under server="both", funder's incompatibility with medRxiv, and the category-filter fallback notice. The include_abstract rationale ("three quarters of a page") gives practical meaning to a boolean the schema only defines literally.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ("List preprints") bounded by a date interval and optional server/category scope, which cleanly separates it from biorxiv_search_preprints. It also names siblings it is not (biorxiv_get_preprint for per-DOI abstracts, biorxiv_list_categories for valid category strings).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit routing guidance: use biorxiv_get_preprint when only a few abstracts are needed, biorxiv_list_categories for valid category values, and include_abstract when the whole page's abstracts are wanted. It also states when results are partial (<code>server="both"</code> with a failing server) vs. when the call aborts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
biorxiv_search_preprintsSearch Preprints by KeywordARead-onlyInspect
Search preprints by keyword and/or author using EuropePMC for relevance ranking, then enrich matching DOIs with full bioRxiv/medRxiv metadata. Provide a keyword query, an author name, or both — author maps to an EuropePMC AUTH: field query and is ANDed with the keyword query. Covers both servers by default. EuropePMC indexes new preprints within 1–2 days of posting; for preprints posted within the last day, prefer biorxiv_list_recent. Abstracts are included by default; include_abstract: false omits them from every result for a response about a third the size, and biorxiv_get_preprint returns the abstract for up to 10 DOIs per call. A EuropePMC rate limit (HTTP 429) fails the call with a retryable rate_limited error carrying the wait in seconds — a rate-limited metadata enrichment does not, and instead marks the affected record enrichment_error: "rate_limited".
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum results to return. Defaults to 25. Up to 100 per call: a larger value returns the first 100 and says so, and nextCursorMark continues the ranked list. | |
| query | No | Keyword search query. Optional when author is provided — supply at least one of query or author. | |
| author | No | Author name to filter by, mapped to an EuropePMC AUTH:"…" field query and ANDed with the keyword query. Optional when query is provided (e.g. "Jennifer Doudna"). | |
| server | No | Server scope for the search and its enrichment: "biorxiv" or "medrxiv" returns only that server's preprints; "both" searches both and checks each matching DOI on both servers. | both |
| date_to | No | Latest first-publication date filter (YYYY-MM-DD). | |
| date_from | No | Earliest first-publication date filter (YYYY-MM-DD). | |
| cursor_mark | No | Opaque page token for ranked EuropePMC results. Omit for the first page; pass the nextCursorMark returned by a prior call to fetch the next page. Pages through the same ranked list rather than raising limit. A token EuropePMC does not recognize fails with invalid_cursor_mark. | |
| include_abstract | No | Include each result's abstract. Defaults to true. false omits the abstract from every result, enriched and EuropePMC-fallback alike, and keeps every other field. |
Output Schema
| Name | Required | Description |
|---|---|---|
| cap | No | Results one call returns at most (100). Set with truncated. |
| error | No | Present when the call failed. Absent on success. |
| shown | No | Results on this page. Set with truncated. |
| notice | No | Present when zero results are returned: on a cursor_mark page past the last match, says the list is exhausted; otherwise echoes the query and suggests how to broaden it. Also present when limit was above the 100-result cap per call, and when abstracts for results shown with EuropePMC metadata only could not be retrieved, which leaves those results without one. |
| preprints | No | Search results, ranked by EuropePMC relevance. |
| queryEcho | No | Echo of the parameters used to produce this result set — lets callers verify what was sent. |
| truncated | No | True when limit asked for more than the 100 results one call returns and this page holds all 100 — continue with nextCursorMark. |
| totalCount | No | Total preprints matching the query in EuropePMC (hitCount) — the true upstream grand total, not the number of results returned. |
| nextCursorMark | No | Opaque token for the next page of ranked results. Present only when more results exist beyond this page; pass it back as cursor_mark. Absent on the last page. |
| partial_results | No | True when one or more DOIs failed bioRxiv enrichment and fell back to EuropePMC metadata. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered and the description's remaining job is failure and cost behavior, which it does well: HTTP 429 becomes a retryable rate_limited error with a wait in seconds, while an enrichment-side 429 degrades gracefully to enrichment_error: "rate_limited" on the record. It also discloses the 1–2 day EuropePMC indexing lag. It stops short of describing result ordering or what the enrichment fields look like, so it sits at a solid but not exceptional 3 given the annotation floor.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose and the query/author contract, then layered cost, latency, and error behavior — a sensible ordering with almost no filler. A few clauses restate schema content (abstract omission, server default), costing a point on strict economy for an otherwise dense paragraph.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an 8-parameter, open-world search tool with an output schema, the description covers everything an agent needs before calling: input contract, pagination via cursor_mark, indexing recency limits, two distinct 429 failure modes, and a response-size lever. Return-value shape is correctly delegated to the output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 earns an extra point by adding semantics the schema does not carry, notably that author is mapped to an EuropePMC AUTH: field query ANDed with the keyword query, that omitting abstracts yields roughly a third the response size, and that include_abstract applies uniformly to enriched and fallback records. The duplicated limit/server explanations overlap with the schema rather than extending it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Names a specific verb and resource ("search preprints by keyword and/or author") and explains the two-stage retrieval model: EuropePMC relevance ranking plus bioRxiv/medRxiv metadata enrichment on matching DOIs. It explicitly separates itself from the sibling biorxiv_list_recent and points to biorxiv_get_preprint, so an agent can route correctly without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
States the input combinations that trigger the tool (keyword, author, or both), gives the exact exclusion condition ("for preprints posted within the last day, prefer biorxiv_list_recent"), and names biorxiv_get_preprint as the alternate path for abstracts. Both when-to-use and when-not-to-use are present with named alternatives.
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 tool update
- Changed
biorxiv_list_recent4 fields changed- added
Output schema / properties / pagination / properties / biorxiv / properties / newPreprintsAdded value: +{ + "description": "Preprints whose first version posted on bioRxiv in the interval, for these filters — the rows with version \"1\" across every page of the listing, as bioRxiv counts them. Absent when bioRxiv reports no count, as on an exhausted entry; never a 0 standing in for an unknown count.", + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" +} - changed
Output schema / properties / pagination / properties / biorxiv / properties / total / descriptionPrevious value: -"Total preprints available on bioRxiv for these filters."New value: +"Rows bioRxiv lists in the interval for these filters — one per revision posted in it, so a preprint revised in the interval counts once per version. For the number of new preprints, read newPreprints." - added
Output schema / properties / pagination / properties / medrxiv / properties / newPreprintsAdded value: +{ + "description": "Preprints whose first version posted on medRxiv in the interval, for these filters — the rows with version \"1\" across every page of the listing, as medRxiv counts them. Absent when medRxiv reports no count, as on an exhausted entry; never a 0 standing in for an unknown count.", + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" +} - changed
Output schema / properties / pagination / properties / medrxiv / properties / total / descriptionPrevious value: -"Total preprints available on medRxiv for these filters."New value: +"Rows medRxiv lists in the interval for these filters — one per revision posted in it, so a preprint revised in the interval counts once per version. For the number of new preprints, read newPreprints."
1 tool update
- Changed
biorxiv_search_preprints1 field changed- changed
Input schema / properties / server / descriptionPrevious value: -"Server scope for enrichment. \"both\" checks all matching DOIs on both servers."New value: +"Server scope for the search and its enrichment: \"biorxiv\" or \"medrxiv\" returns only that server's preprints; \"both\" searches both and checks each matching DOI on both servers."
5 tool updates
- Changed
biorxiv_get_preprint4 fields changed- changed
Output schema / properties / preprints / items / properties / revisions / items / properties / abstract / descriptionPrevious value: -"Abstract text."New value: +"The preprint's current abstract, present on the latest revision only: api.biorxiv.org keeps one abstract per preprint and repeats it on every revision. For an earlier revision's own abstract, read that revision with biorxiv_get_fulltext and its version input; medRxiv blocks its article pages to some hosts, and there that request fails as fulltext_unavailable." - changed
Output schema / properties / preprints / items / properties / revisions / items / properties / server / descriptionPrevious value: -"Source server (biorxiv or medrxiv)."New value: +"Server the revision was found on — accepted as the server input of every tool." - added
Output schema / properties / preprints / items / properties / revisions / items / properties / server / enumAdded value: +[ + "biorxiv", + "medrxiv" +] - changed
Output schema / properties / preprints / items / properties / revisions / items / requiredPrevious value: -[ - "doi" -]New value: +[ + "doi", + "server" +]
- Changed
biorxiv_get_published_version3 fields changed- changed
Input schema / properties / doi / descriptionPrevious value: -"Preprint DOI to resolve (e.g. 10.1101/2024.01.15.575123 or 10.64898/2026.05.07.723463). A doi.org or biorxiv.org/medrxiv.org article URL, a doi: prefix, or a vN / .full suffix is accepted and stripped to the bare DOI."New value: +"DOI to resolve: a preprint DOI (e.g. 10.1101/2024.01.15.575123 or 10.64898/2026.05.07.723463) or a journal article DOI (e.g. 10.1016/j.cell.2020.01.001). A doi.org or biorxiv.org/medrxiv.org article URL or a doi: prefix is accepted and stripped to the bare DOI, as is a vN, .full, or .pdf suffix; a journal DOI keeps its own components (10.7554/eLife.55185.sa1 is not 10.7554/eLife.55185). Cold Spring Harbor Laboratory Press journal DOIs (10.1101/gr.…, 10.1101/gad.…, 10.1101/lm.…) share the preprint prefix and cannot be resolved by DOI." - changed
Output schema / properties / error / properties / data / properties / reason / descriptionPrevious value: -"Machine-readable failure mode. Declared by this tool: `doi_not_found`: No attempted server holds the preprint, or neither the crosswalk nor its preprint record lists a journal version. `invalid_doi_format`: The input DOI does not match the 10.NNNN/ pattern, even after URL, doi:, and suffix stripping. `upstream_unavailable`: No published record was established and at least one crosswalk or preprint lookup failed against api.biorxiv.org. `rate_limited`: No published record was established and at least one crosswalk or preprint lookup was rejected with HTTP 429 by api.biorxiv.org. Other values are possible when a failure originates below the handler."New value: +"Machine-readable failure mode. Declared by this tool: `doi_not_found`: No attempted server holds the preprint, neither the crosswalk nor its preprint record lists a journal version, or the crosswalk links no preprint to the journal DOI given. `invalid_doi_format`: The input does not match the 10.NNNN/ DOI pattern, even after URL, doi:, and suffix stripping. `upstream_unavailable`: No published record was established and at least one crosswalk or preprint lookup failed against api.biorxiv.org. `rate_limited`: No published record was established and at least one crosswalk or preprint lookup was rejected with HTTP 429 by api.biorxiv.org. Other values are possible when a failure originates below the handler." - changed
Output schema / properties / preprintDoi / descriptionPrevious value: -"The preprint DOI that was resolved, in bare form."New value: +"The preprint DOI, in bare form: the input itself when it was a preprint DOI, or the preprint the crosswalk links to the input when it was a journal DOI."
- Changed
biorxiv_list_published_versions9 fields changed- added
Input schema / properties / publisherAdded value: +{ + "description": "Journal publisher filter: the DOI prefix its journal articles share, the part before the slash — \"10.7554\" for eLife, \"10.1016\" for Elsevier. Lists only the bioRxiv preprints published under that prefix: medRxiv has no publisher listing, so server=\"both\" queries bioRxiv alone and server=\"medrxiv\" is rejected. Rows listed this way carry no journal name, authors, corresponding author, or abstract.", + "pattern": "^10\\.\\d{4,}$", + "type": "string" +} - changed
Output schema / properties / error / properties / data / properties / reason / descriptionPrevious value: -"Machine-readable failure mode. Declared by this tool: `invalid_date_range`: start_date or end_date is not a real calendar date (2024-02-30, 2024-13-01), or end_date is before start_date. `upstream_unavailable`: Every attempted server failed against api.biorxiv.org, so no page was retrieved and an empty interval could not be established. `rate_limited`: Every attempted server failed and at least one was rejected with HTTP 429 by api.biorxiv.org. Other values are possible when a failure originates below the handler."New value: +"Machine-readable failure mode. Declared by this tool: `invalid_date_range`: start_date or end_date is not a real calendar date (2024-02-30, 2024-13-01), or end_date is before start_date. `invalid_publisher`: publisher is combined with server=\"medrxiv\", or is a prefix api.biorxiv.org does not recognize. `upstream_unavailable`: Every attempted server failed against api.biorxiv.org, so no page was retrieved and an empty interval could not be established. `rate_limited`: Every attempted server failed and at least one was rejected with HTTP 429 by api.biorxiv.org. Other values are possible when a failure originates below the handler." - changed
Output schema / properties / error / properties / data / properties / reason / examplesPrevious value: -[ - "invalid_date_range", - "upstream_unavailable", - "rate_limited" -]New value: +[ + "invalid_date_range", + "invalid_publisher", + "upstream_unavailable", + "rate_limited" +] - changed
Output schema / properties / notice / descriptionPrevious value: -"Guidance on how to read this result set: which servers did not answer, a limit above the 100-row page, which cursors are past the end, which servers have rows past this page, and — when nothing came back — the interval and how to broaden it. All applicable qualifications are composed into one string."New value: +"Guidance on how to read this result set: which servers did not answer, that a publisher filter limited server=\"both\" to bioRxiv and which fields its rows lack, a limit above the 100-row page, which cursors are past the end, which servers have rows past this page, and — when nothing came back — the interval and how to broaden it. All applicable qualifications are composed into one string." - changed
Output schema / properties / publications / items / properties / preprintAbstract / descriptionPrevious value: -"Preprint abstract. Present only when include_abstract is true."New value: +"Preprint abstract. Present only when include_abstract is true, and never under a publisher filter." - changed
Output schema / properties / publications / items / properties / preprintAuthorCorresponding / descriptionPrevious value: -"Corresponding author name."New value: +"Corresponding author name. Absent under a publisher filter." - changed
Output schema / properties / publications / items / properties / preprintAuthorCorrespondingInstitution / descriptionPrevious value: -"Corresponding author institution."New value: +"Corresponding author institution. Absent under a publisher filter." - changed
Output schema / properties / publications / items / properties / preprintAuthors / descriptionPrevious value: -"Preprint author list."New value: +"Preprint author list. Absent under a publisher filter." - changed
Output schema / properties / publications / items / properties / publishedJournal / descriptionPrevious value: -"Name of the publishing journal."New value: +"Name of the publishing journal. Absent under a publisher filter, whose rows carry none."
- Changed
biorxiv_list_recent7 fields changed- added
Input schema / properties / end_date / patternAdded value: +"^\\d{4}-\\d{2}-\\d{2}$" - added
Input schema / properties / start_date / patternAdded value: +"^\\d{4}-\\d{2}-\\d{2}$" - changed
Output schema / properties / error / properties / data / properties / reason / descriptionPrevious value: -"Machine-readable failure mode. Declared by this tool: `invalid_date_range`: end_date is before start_date, or either date is malformed. `invalid_category`: The category is not in the requested server's taxonomy, or api.biorxiv.org ignored it and returned the unfiltered listing on every server that answered. `invalid_funder`: funder is not a well-formed ROR ID (pattern or checksum), is combined with server=\"medrxiv\", or is a ROR ID api.biorxiv.org has no funder record for. `upstream_unavailable`: Every attempted server failed against api.biorxiv.org, so no page was retrieved and an empty interval could not be established. `rate_limited`: Every attempted server failed and at least one was rejected with HTTP 429 by api.biorxiv.org. Other values are possible when a failure originates below the handler."New value: +"Machine-readable failure mode. Declared by this tool: `invalid_date_range`: end_date is before start_date, or either date names no calendar day (2024-02-30, 2024-13-01). `invalid_category`: The category is not in the requested server's taxonomy, or api.biorxiv.org ignored it and returned the unfiltered listing on every server that answered. `invalid_funder`: funder is not a well-formed ROR ID (pattern or checksum), is combined with server=\"medrxiv\", or is a ROR ID api.biorxiv.org has no funder record for. `upstream_unavailable`: Every attempted server failed against api.biorxiv.org, so no page was retrieved and an empty interval could not be established. `rate_limited`: Every attempted server failed and at least one was rejected with HTTP 429 by api.biorxiv.org. Other values are possible when a failure originates below the handler." - changed
Output schema / properties / preprints / items / properties / abstract / descriptionPrevious value: -"Abstract text. Present only when include_abstract is true."New value: +"The preprint's latest-revision abstract, which differs from this row's own revision when a later one exists — api.biorxiv.org keeps one abstract per preprint. Present only when include_abstract is true." - changed
Output schema / properties / preprints / items / properties / server / descriptionPrevious value: -"Source server (biorxiv or medrxiv)."New value: +"Server the preprint was listed on — accepted as the server input of every tool." - added
Output schema / properties / preprints / items / properties / server / enumAdded value: +[ + "biorxiv", + "medrxiv" +] - changed
Output schema / properties / preprints / items / requiredPrevious value: -[ - "doi" -]New value: +[ + "doi", + "server" +]
- Changed
biorxiv_search_preprints3 fields changed- changed
Output schema / properties / error / properties / data / properties / reason / descriptionPrevious value: -"Machine-readable failure mode. Declared by this tool: `invalid_date_range`: date_from or date_to is not a real calendar date (2024-02-30, 2024-13-01), or date_from is after date_to. `search_unavailable`: EuropePMC search endpoint is unreachable, returns a server error, or answers a first-page search without a result list on every retry. `invalid_cursor_mark`: EuropePMC answers a cursor_mark page request without a result list on every retry — the token is malformed or not one EuropePMC issued. `rate_limited`: The EuropePMC search endpoint rejected the keyword search with HTTP 429. Distinct from a rate-limited enrichment call, which degrades to EuropePMC-only metadata instead of failing. Other values are possible when a failure originates below the handler."New value: +"Machine-readable failure mode. Declared by this tool: `invalid_date_range`: date_from or date_to is not a real calendar date (2024-02-30, 2024-13-01), or date_from is after date_to. `search_unavailable`: EuropePMC search endpoint is unreachable, returns a server error, or answers without a result list on every retry. On a cursor_mark page, HTTP 503 or a missing result list on every retry is this reason only when the first page of the same query fails too, or no time is left to check it. `invalid_cursor_mark`: EuropePMC answers a cursor_mark page with HTTP 503 or without a result list on every retry while the first page of the same query answers — the token is malformed or not one EuropePMC issued. `rate_limited`: The EuropePMC search endpoint rejected the keyword search with HTTP 429. Distinct from a rate-limited enrichment call, which degrades to EuropePMC-only metadata instead of failing. Other values are possible when a failure originates below the handler." - changed
Output schema / properties / preprints / items / properties / server / descriptionPrevious value: -"Source server (biorxiv or medrxiv)."New value: +"Server the preprint was found on — accepted as the server input of every tool. Present on enriched records only." - added
Output schema / properties / preprints / items / properties / server / enumAdded value: +[ + "biorxiv", + "medrxiv" +]
5 tool updates
- Changed
biorxiv_get_fulltext1 field changed- changed
Output schema / properties / error / properties / data / properties / reason / descriptionPrevious value: -"Machine-readable failure mode. Declared by this tool: `invalid_doi_format`: The input DOI does not match the 10.NNNN/ pattern, even after URL, doi:, and suffix stripping. `version_conflict`: The DOI carries a vN suffix and the version input names a different version. `version_not_found`: The preprint exists but has no revision with the requested version number. `doi_not_found`: The DOI resolves to an empty collection on every attempted server. `upstream_unavailable`: No attempted server resolved the DOI and at least one lookup failed against api.biorxiv.org. `rate_limited`: Either origin returned HTTP 429 for this host — the article page (www.biorxiv.org / www.medrxiv.org) during the full-text fetch, or api.biorxiv.org during version resolution. `fulltext_unavailable`: The preprint exists but its full-text HTML page is blocked, missing, or yields no extractable text (PDF-only). `offset_out_of_range`: offset is greater than or equal to the total character length of the extracted text. Other values are possible when a failure originates below the handler."New value: +"Machine-readable failure mode. Declared by this tool: `invalid_doi_format`: The input DOI does not match the 10.NNNN/ pattern, even after URL, doi:, and suffix stripping. `version_conflict`: The DOI carries a vN suffix and the version input names a different version. `version_not_found`: The preprint exists but has no revision with the requested version number. `doi_not_found`: The DOI resolves to an empty collection on every attempted server. `upstream_unavailable`: No attempted server resolved the DOI and at least one lookup failed against api.biorxiv.org; the version lookup used most of the call's time budget, so the article page was never requested or had not answered when the budget ran out; or the article page (www.biorxiv.org / www.medrxiv.org) did not answer within the call. `rate_limited`: Either origin returned HTTP 429 for this host — the article page (www.biorxiv.org / www.medrxiv.org) during the full-text fetch, or api.biorxiv.org during version resolution. `fulltext_unavailable`: The preprint exists but its full-text HTML page is blocked, missing, or yields no extractable text (PDF-only). `offset_out_of_range`: offset is greater than or equal to the total character length of the extracted text. Other values are possible when a failure originates below the handler."
- Changed
biorxiv_get_preprint9 fields changed- changed
Input schema / properties / dois / descriptionPrevious value: -"One or more preprint DOIs to look up (max 10)."New value: +"Preprint DOIs to look up, up to 200 entries. The first 10 distinct DOIs are looked up; the rest are returned in unprocessed." - changed
Input schema / properties / dois / maxItemsPrevious value: -10New value: +200 - changed
Output schema / anyOfPrevious value: -[ - { - "not": { - "required": [ - "error" - ] - }, - "required": [ - "preprints", - "failed" - ] - }, - { - "required": [ - "error" - ] - } -]New value: +[ + { + "not": { + "required": [ + "error" + ] + }, + "required": [ + "preprints", + "failed", + "unprocessed" + ] + }, + { + "required": [ + "error" + ] + } +] - added
Output schema / properties / capAdded value: +{ + "description": "The most distinct DOIs one call looks up.", + "type": "number" +} - changed
Output schema / properties / error / properties / data / properties / reason / descriptionPrevious value: -"Machine-readable failure mode. Declared by this tool: `doi_not_found`: ALL requested DOIs resolve to empty collections on all requested servers, with every server answering. `invalid_doi_format`: Every input DOI fails to match the 10.NNNN/ pattern, even after URL, doi:, and suffix stripping. `upstream_unavailable`: No DOI resolved and at least one lookup failed against api.biorxiv.org, so absence could not be established for any requested DOI. `rate_limited`: No DOI resolved and at least one lookup was rejected with HTTP 429 by api.biorxiv.org. Other values are possible when a failure originates below the handler."New value: +"Machine-readable failure mode. Declared by this tool: `doi_not_found`: Every DOI looked up resolves to empty collections on all requested servers, with every server answering, and no DOI was left in unprocessed. `invalid_doi_format`: Every input entry fails to match the 10.NNNN/ pattern, even after URL, doi:, and suffix stripping. `upstream_unavailable`: No DOI resolved, none was left in unprocessed, and at least one lookup failed against api.biorxiv.org, so absence could not be established for any requested DOI. `rate_limited`: No DOI resolved, none was left in unprocessed, and at least one lookup was rejected with HTTP 429 by api.biorxiv.org. Other values are possible when a failure originates below the handler." - added
Output schema / properties / noticeAdded value: +{ + "description": "How to look up the DOIs left in unprocessed, and how many failed[] entries are retryable alongside them.", + "type": "string" +} - added
Output schema / properties / shownAdded value: +{ + "description": "Distinct DOIs looked up in this call.", + "type": "number" +} - added
Output schema / properties / truncatedAdded value: +{ + "description": "True when DOIs past the first 10 were left in unprocessed.", + "type": "boolean" +} - added
Output schema / properties / unprocessedAdded value: +{ + "description": "Valid, distinct DOIs past the first 10, in input order — not looked up, so neither found nor failed. Pass this list as dois in another call to continue. Empty when every DOI was looked up.", + "items": { + "description": "A bare DOI that was not looked up.", + "type": "string" + }, + "type": "array" +}
- Changed
biorxiv_get_published_version1 field changed- changed
Output schema / properties / preprintDate / descriptionPrevious value: -"Date the preprint was first posted."New value: +"Preprint posting date (YYYY-MM-DD) from the crosswalk record, or from the preprint's first revision when the crosswalk has none — the first posting for most preprints. medRxiv records some 10.64898/ preprints twice with different posting dates; this is the first record listed."
- Changed
biorxiv_list_published_versions9 fields changed- changed
Input schema / properties / cursor / descriptionPrevious value: -"Integer row offset (0, 100, 200, …), applied to each queried server. Defaults to 0 (first page)."New value: +"Integer row offset, applied to each queried server. Defaults to 0 (first page). To continue, pass the nextCursor the previous page returned for that server — it advances by the rows actually served." - added
Input schema / properties / limitAdded value: +{ + "default": 25, + "description": "Rows to return per queried server, starting at cursor. Defaults to 25. Up to 100, the page api.biorxiv.org serves: a larger value returns 100 rows per server and says so in the notice. limit: 100 walks an interval in the fewest calls.", + "maximum": 1000, + "minimum": 1, + "type": "integer" +} - added
Output schema / properties / capAdded value: +{ + "description": "Most publications this page can hold: rows per server (limit, or 100 when limit asked for more) times the servers queried. Set with truncated.", + "type": "number" +} - changed
Output schema / properties / notice / descriptionPrevious value: -"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 interval and how to broaden it. All applicable qualifications are composed into one string."New value: +"Guidance on how to read this result set: which servers did not answer, a limit above the 100-row page, which cursors are past the end, which servers have rows past this page, and — when nothing came back — the interval and how to broaden it. All applicable qualifications are composed into one string." - changed
Output schema / properties / pagination / properties / biorxiv / properties / nextCursor / descriptionPrevious value: -"Cursor for the next page, when rows remain past this one."New value: +"Cursor for the next page, when rows remain on bioRxiv past this one: this page's cursor plus the rows it served. Pass it as cursor to continue, at any limit." - changed
Output schema / properties / pagination / properties / medrxiv / properties / nextCursor / descriptionPrevious value: -"Cursor for the next page, when rows remain past this one."New value: +"Cursor for the next page, when rows remain on medRxiv past this one: this page's cursor plus the rows it served. Pass it as cursor to continue, at any limit." - changed
Output schema / properties / publications / items / properties / preprintDate / descriptionPrevious value: -"Date the preprint was first posted (YYYY-MM-DD). Not derivable from the DOI."New value: +"Preprint posting date (YYYY-MM-DD) as this row records it — the first posting for most preprints. medRxiv lists some 10.64898/ preprints on two rows that differ in this date, and sometimes in title or authors; both rows are returned. Not derivable from the DOI." - added
Output schema / properties / shownAdded value: +{ + "description": "Publications on this page, across every server queried. Set with truncated.", + "type": "number" +} - added
Output schema / properties / truncatedAdded value: +{ + "description": "True when at least one server has rows past this page — continue at that server's nextCursor. Absent when every server queried is on its last page.", + "type": "boolean" +}
- Changed
biorxiv_search_preprints7 fields changed- changed
Input schema / properties / limit / descriptionPrevious value: -"Maximum results to return (1–100). Defaults to 25."New value: +"Maximum results to return. Defaults to 25. Up to 100 per call: a larger value returns the first 100 and says so, and nextCursorMark continues the ranked list." - changed
Input schema / properties / limit / maximumPrevious value: -100New value: +1000 - added
Output schema / properties / capAdded value: +{ + "description": "Results one call returns at most (100). Set with truncated.", + "type": "number" +} - changed
Output schema / properties / notice / descriptionPrevious value: -"Present when zero results are returned: on a cursor_mark page past the last match, says the list is exhausted; otherwise echoes the query and suggests how to broaden it. Also present when abstracts for results shown with EuropePMC metadata only could not be retrieved, which leaves those results without one."New value: +"Present when zero results are returned: on a cursor_mark page past the last match, says the list is exhausted; otherwise echoes the query and suggests how to broaden it. Also present when limit was above the 100-result cap per call, and when abstracts for results shown with EuropePMC metadata only could not be retrieved, which leaves those results without one." - changed
Output schema / properties / queryEcho / properties / limit / descriptionPrevious value: -"Maximum results requested."New value: +"Maximum results requested from EuropePMC: the limit input, capped at 100 per call." - added
Output schema / properties / shownAdded value: +{ + "description": "Results on this page. Set with truncated.", + "type": "number" +} - added
Output schema / properties / truncatedAdded value: +{ + "description": "True when limit asked for more than the 100 results one call returns and this page holds all 100 — continue with nextCursorMark.", + "type": "boolean" +}
3 tool updates
- Changed
biorxiv_get_fulltext3 fields changed- changed
Input schema / properties / limit / descriptionPrevious value: -"Maximum number of characters to return in this chunk. Default 20,000; increase toward 50,000 for large context windows. Check the length field for the actual count returned."New value: +"Maximum number of characters to return in this chunk. Default 20,000; a value past the remaining text returns the rest of the article. Check the length field for the actual count returned." - changed
Input schema / properties / limit / maximumPrevious value: -50000New value: +9007199254740991 - added
Output schema / properties / omittedTablesAdded value: +{ + "description": "Tables the article page names without their cells — content keeps each one's caption, and the cells live on a separate page at url. The same list on every chunk. Absent when the article has none.", + "items": { + "additionalProperties": false, + "description": "One table whose cells content does not include.", + "properties": { + "label": { + "description": "The table label as the article prints it, e.g. \"Table 1\".", + "type": "string" + }, + "url": { + "description": "The article origin's page that serves this table's cells. Not fetched by this tool.", + "type": "string" + } + }, + "required": [ + "label", + "url" + ], + "type": "object" + }, + "type": "array" +}
- Added
biorxiv_list_published_versions - Changed
biorxiv_search_preprints3 fields changed- added
Input schema / properties / date_from / patternAdded value: +"^\\d{4}-\\d{2}-\\d{2}$" - added
Input schema / properties / date_to / patternAdded value: +"^\\d{4}-\\d{2}-\\d{2}$" - changed
Output schema / properties / error / properties / data / properties / reason / descriptionPrevious value: -"Machine-readable failure mode. Declared by this tool: `invalid_date_range`: date_from or date_to is malformed, or date_from is after date_to. `search_unavailable`: EuropePMC search endpoint is unreachable, returns a server error, or answers a first-page search without a result list on every retry. `invalid_cursor_mark`: EuropePMC answers a cursor_mark page request without a result list on every retry — the token is malformed or not one EuropePMC issued. `rate_limited`: The EuropePMC search endpoint rejected the keyword search with HTTP 429. Distinct from a rate-limited enrichment call, which degrades to EuropePMC-only metadata instead of failing. Other values are possible when a failure originates below the handler."New value: +"Machine-readable failure mode. Declared by this tool: `invalid_date_range`: date_from or date_to is not a real calendar date (2024-02-30, 2024-13-01), or date_from is after date_to. `search_unavailable`: EuropePMC search endpoint is unreachable, returns a server error, or answers a first-page search without a result list on every retry. `invalid_cursor_mark`: EuropePMC answers a cursor_mark page request without a result list on every retry — the token is malformed or not one EuropePMC issued. `rate_limited`: The EuropePMC search endpoint rejected the keyword search with HTTP 429. Distinct from a rate-limited enrichment call, which degrades to EuropePMC-only metadata instead of failing. Other values are possible when a failure originates below the handler."
3 tool updates
- Changed
biorxiv_get_preprint2 fields changed- added
Output schema / properties / preprints / items / properties / revisions / items / properties / awardsAdded value: +{ + "description": "Grant award numbers from the funding statement, verbatim and deduplicated — one value can hold several grants run together without a separator. Absent when none. Funder names are not included: api.biorxiv.org attributes them to unrelated organizations.", + "items": { + "description": "One award value as upstream records it.", + "type": "string" + }, + "type": "array" +} - removed
Output schema / properties / preprints / items / properties / revisions / items / properties / funderRemoved value: -{ - "description": "Funder information.", - "type": "string" -}
- Changed
biorxiv_list_recent9 fields changed- added
Input schema / properties / funderAdded value: +{ + "description": "Funder filter: the funder's ROR ID, bare (\"021nxhr62\" for the US National Science Foundation) or as a URL (\"https://ror.org/021nxhr62\"). bioRxiv only — medRxiv records carry no funder data, so server=\"both\" queries bioRxiv alone and server=\"medrxiv\" is rejected. Combines with category. Look the ID up by name at ror.org.", + "type": "string" +} - added
Input schema / properties / include_abstractAdded value: +{ + "default": false, + "description": "Include each preprint's abstract. Defaults to false: abstracts make up about three quarters of a page, and every other field is returned either way.", + "type": "boolean" +} - changed
Output schema / properties / error / properties / data / properties / reason / descriptionPrevious value: -"Machine-readable failure mode. Declared by this tool: `invalid_date_range`: end_date is before start_date, or either date is malformed. `invalid_category`: The category is not in the requested server's taxonomy, or api.biorxiv.org ignored it and returned the unfiltered listing on every server that answered. `upstream_unavailable`: Every attempted server failed against api.biorxiv.org, so no page was retrieved and an empty interval could not be established. `rate_limited`: Every attempted server failed and at least one was rejected with HTTP 429 by api.biorxiv.org. Other values are possible when a failure originates below the handler."New value: +"Machine-readable failure mode. Declared by this tool: `invalid_date_range`: end_date is before start_date, or either date is malformed. `invalid_category`: The category is not in the requested server's taxonomy, or api.biorxiv.org ignored it and returned the unfiltered listing on every server that answered. `invalid_funder`: funder is not a well-formed ROR ID (pattern or checksum), is combined with server=\"medrxiv\", or is a ROR ID api.biorxiv.org has no funder record for. `upstream_unavailable`: Every attempted server failed against api.biorxiv.org, so no page was retrieved and an empty interval could not be established. `rate_limited`: Every attempted server failed and at least one was rejected with HTTP 429 by api.biorxiv.org. Other values are possible when a failure originates below the handler." - changed
Output schema / properties / error / properties / data / properties / reason / examplesPrevious value: -[ - "invalid_date_range", - "invalid_category", - "upstream_unavailable", - "rate_limited" -]New value: +[ + "invalid_date_range", + "invalid_category", + "invalid_funder", + "upstream_unavailable", + "rate_limited" +] - changed
Output schema / properties / notice / descriptionPrevious value: -"Guidance on how to read this result set: which servers did not answer, which ignored the category filter (their unfiltered records are left out), 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."New value: +"Guidance on how to read this result set: which servers did not answer, which ignored the category filter (their unfiltered records are left out), that a funder filter limited server=\"both\" to bioRxiv, 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." - changed
Output schema / properties / pagination / properties / medrxiv / descriptionPrevious value: -"medRxiv pagination state. Present when server is \"medrxiv\" or \"both\"."New value: +"medRxiv pagination state. Present when server is \"medrxiv\" or \"both\", except under a funder filter, which queries bioRxiv only." - changed
Output schema / properties / preprints / items / properties / abstract / descriptionPrevious value: -"Abstract text."New value: +"Abstract text. Present only when include_abstract is true." - added
Output schema / properties / preprints / items / properties / awardsAdded value: +{ + "description": "Grant award numbers from the funding statement, verbatim and deduplicated — one value can hold several grants run together without a separator. Absent when none. Funder names are not included: api.biorxiv.org attributes them to unrelated organizations.", + "items": { + "description": "One award value as upstream records it.", + "type": "string" + }, + "type": "array" +} - removed
Output schema / properties / preprints / items / properties / funderRemoved value: -{ - "description": "Funder information.", - "type": "string" -}
- Changed
biorxiv_search_preprints5 fields changed- added
Input schema / properties / include_abstractAdded value: +{ + "default": true, + "description": "Include each result's abstract. Defaults to true. false omits the abstract from every result, enriched and EuropePMC-fallback alike, and keeps every other field.", + "type": "boolean" +} - changed
Output schema / properties / notice / descriptionPrevious value: -"Present when zero results are returned. On a cursor_mark page past the last match, says the list is exhausted; otherwise echoes the query and suggests how to broaden it."New value: +"Present when zero results are returned: on a cursor_mark page past the last match, says the list is exhausted; otherwise echoes the query and suggests how to broaden it. Also present when abstracts for results shown with EuropePMC metadata only could not be retrieved, which leaves those results without one." - changed
Output schema / properties / preprints / items / properties / abstract / descriptionPrevious value: -"Abstract text."New value: +"Abstract text. Omitted when include_abstract is false. On a EuropePMC-fallback record, absent when EuropePMC holds none or the abstract lookup failed — the notice says when it failed." - added
Output schema / properties / preprints / items / properties / awardsAdded value: +{ + "description": "Grant award numbers from the funding statement, verbatim and deduplicated — one value can hold several grants run together without a separator. Absent when none, and on EuropePMC-only fallback records. Funder names are not included: api.biorxiv.org attributes them to unrelated organizations.", + "items": { + "description": "One award value as upstream records it.", + "type": "string" + }, + "type": "array" +} - removed
Output schema / properties / preprints / items / properties / funderRemoved value: -{ - "description": "Funder information.", - "type": "string" -}
5 tool updates
- Changed
biorxiv_get_fulltext8 fields changed- changed
Input schema / properties / doi / descriptionPrevious value: -"Preprint DOI (e.g. 10.1101/2024.05.28.596311 or 10.64898/2026.05.07.723463). The latest version is resolved automatically."New value: +"Preprint DOI (e.g. 10.1101/2024.05.28.596311 or 10.64898/2026.05.07.723463). A doi.org or biorxiv.org/medrxiv.org article URL, a doi: prefix, or a .full suffix is accepted and stripped; a trailing vN (…596311v2) requests that version. Without one, the latest version is resolved automatically." - added
Input schema / properties / versionAdded value: +{ + "description": "Preprint version to read (1, 2, …) — the revision numbers biorxiv_get_preprint lists. Omit for the latest version. Must match a vN suffix on the DOI when both are given.", + "maximum": 9007199254740991, + "minimum": 1, + "type": "integer" +} - changed
Output schema / anyOfPrevious value: -[ - { - "not": { - "required": [ - "error" - ] - }, - "required": [ - "doi", - "server", - "version", - "content", - "contentFormat", - "sourceUrl", - "offset", - "length", - "totalChars", - "remainingChars", - "hasMore" - ] - }, - { - "required": [ - "error" - ] - } -]New value: +[ + { + "not": { + "required": [ + "error" + ] + }, + "required": [ + "doi", + "server", + "version", + "content", + "contentFormat", + "wordCount", + "sourceUrl", + "offset", + "length", + "totalChars", + "remainingChars", + "hasMore" + ] + }, + { + "required": [ + "error" + ] + } +] - changed
Output schema / properties / doi / descriptionPrevious value: -"The resolved preprint DOI."New value: +"The resolved preprint DOI, in bare form." - changed
Output schema / properties / error / properties / data / properties / reason / descriptionPrevious value: -"Machine-readable failure mode. Declared by this tool: `invalid_doi_format`: The input DOI does not match the 10.NNNN/ pattern. `doi_not_found`: The DOI resolves to an empty collection on every attempted server. `upstream_unavailable`: No attempted server resolved the DOI and at least one lookup failed against api.biorxiv.org. `rate_limited`: Either origin returned HTTP 429 for this host — the article page (www.biorxiv.org / www.medrxiv.org) during the full-text fetch, or api.biorxiv.org during version resolution. `fulltext_unavailable`: The preprint exists but its full-text HTML page is blocked, missing, or yields no extractable text (PDF-only). `offset_out_of_range`: offset is greater than or equal to the total character length of the extracted text. Other values are possible when a failure originates below the handler."New value: +"Machine-readable failure mode. Declared by this tool: `invalid_doi_format`: The input DOI does not match the 10.NNNN/ pattern, even after URL, doi:, and suffix stripping. `version_conflict`: The DOI carries a vN suffix and the version input names a different version. `version_not_found`: The preprint exists but has no revision with the requested version number. `doi_not_found`: The DOI resolves to an empty collection on every attempted server. `upstream_unavailable`: No attempted server resolved the DOI and at least one lookup failed against api.biorxiv.org. `rate_limited`: Either origin returned HTTP 429 for this host — the article page (www.biorxiv.org / www.medrxiv.org) during the full-text fetch, or api.biorxiv.org during version resolution. `fulltext_unavailable`: The preprint exists but its full-text HTML page is blocked, missing, or yields no extractable text (PDF-only). `offset_out_of_range`: offset is greater than or equal to the total character length of the extracted text. Other values are possible when a failure originates below the handler." - changed
Output schema / properties / error / properties / data / properties / reason / examplesPrevious value: -[ - "invalid_doi_format", - "doi_not_found", - "upstream_unavailable", - "rate_limited", - "fulltext_unavailable", - "offset_out_of_range" -]New value: +[ + "invalid_doi_format", + "version_conflict", + "version_not_found", + "doi_not_found", + "upstream_unavailable", + "rate_limited", + "fulltext_unavailable", + "offset_out_of_range" +] - changed
Output schema / properties / version / descriptionPrevious value: -"Preprint version whose full text was retrieved (the latest revision)."New value: +"Preprint version whose full text was retrieved — the requested one, or the latest revision when none was requested. Pass it back as version when paging." - changed
Output schema / properties / wordCount / descriptionPrevious value: -"Approximate word count of the FULL extracted article as reported by the extractor (not just the returned chunk). Absent when the extractor reported none."New value: +"Approximate word count of the FULL extracted article, not just the returned chunk — whitespace-delimited tokens of the same Markdown text that totalChars measures, so Markdown markers such as # and - count too."
- Changed
biorxiv_get_preprint4 fields changed- changed
Input schema / properties / dois / items / descriptionPrevious value: -"Preprint DOI (e.g. 10.1101/2024.01.15.575123 or 10.64898/2026.05.07.723463)."New value: +"Preprint DOI (e.g. 10.1101/2024.01.15.575123 or 10.64898/2026.05.07.723463). A doi.org or biorxiv.org/medrxiv.org article URL, a doi: prefix, or a vN / .full suffix is accepted and stripped to the bare DOI; every revision is returned either way." - changed
Output schema / properties / error / properties / data / properties / reason / descriptionPrevious value: -"Machine-readable failure mode. Declared by this tool: `doi_not_found`: ALL requested DOIs resolve to empty collections on all requested servers, with every server answering. `invalid_doi_format`: One or more input DOIs do not match the 10.NNNN/ pattern. `upstream_unavailable`: No DOI resolved and at least one lookup failed against api.biorxiv.org, so absence could not be established for any requested DOI. `rate_limited`: No DOI resolved and at least one lookup was rejected with HTTP 429 by api.biorxiv.org. Other values are possible when a failure originates below the handler."New value: +"Machine-readable failure mode. Declared by this tool: `doi_not_found`: ALL requested DOIs resolve to empty collections on all requested servers, with every server answering. `invalid_doi_format`: Every input DOI fails to match the 10.NNNN/ pattern, even after URL, doi:, and suffix stripping. `upstream_unavailable`: No DOI resolved and at least one lookup failed against api.biorxiv.org, so absence could not be established for any requested DOI. `rate_limited`: No DOI resolved and at least one lookup was rejected with HTTP 429 by api.biorxiv.org. Other values are possible when a failure originates below the handler." - changed
Output schema / properties / failed / items / properties / doi / descriptionPrevious value: -"DOI that failed to resolve."New value: +"DOI that failed to resolve — in bare form, or exactly as sent for invalid_doi_format." - changed
Output schema / properties / preprints / items / properties / doi / descriptionPrevious value: -"The requested DOI."New value: +"The requested DOI in bare form (any URL, doi: prefix, or suffix removed)."
- Changed
biorxiv_get_published_version6 fields changed- changed
Input schema / properties / doi / descriptionPrevious value: -"Preprint DOI to resolve (e.g. 10.1101/2024.01.15.575123 or 10.64898/2026.05.07.723463)."New value: +"Preprint DOI to resolve (e.g. 10.1101/2024.01.15.575123 or 10.64898/2026.05.07.723463). A doi.org or biorxiv.org/medrxiv.org article URL, a doi: prefix, or a vN / .full suffix is accepted and stripped to the bare DOI." - changed
Output schema / properties / error / properties / data / properties / reason / descriptionPrevious value: -"Machine-readable failure mode. Declared by this tool: `doi_not_found`: Crosswalk endpoint returns an empty collection on every attempted server. `invalid_doi_format`: The input DOI does not match the 10.NNNN/ pattern. `upstream_unavailable`: No attempted server returned a record and at least one lookup failed against api.biorxiv.org. `rate_limited`: No attempted server returned a record and at least one lookup was rejected with HTTP 429 by api.biorxiv.org. Other values are possible when a failure originates below the handler."New value: +"Machine-readable failure mode. Declared by this tool: `doi_not_found`: No attempted server holds the preprint, or neither the crosswalk nor its preprint record lists a journal version. `invalid_doi_format`: The input DOI does not match the 10.NNNN/ pattern, even after URL, doi:, and suffix stripping. `upstream_unavailable`: No published record was established and at least one crosswalk or preprint lookup failed against api.biorxiv.org. `rate_limited`: No published record was established and at least one crosswalk or preprint lookup was rejected with HTTP 429 by api.biorxiv.org. Other values are possible when a failure originates below the handler." - added
Output schema / properties / noticeAdded value: +{ + "description": "Present when publishedDoi came from the preprint's own record because the crosswalk had none: says why publishedJournal and publishedDate are absent.", + "type": "string" +} - changed
Output schema / properties / preprintDoi / descriptionPrevious value: -"The preprint DOI that was resolved."New value: +"The preprint DOI that was resolved, in bare form." - changed
Output schema / properties / publishedDate / descriptionPrevious value: -"Journal publication date (YYYY-MM-DD)."New value: +"Journal publication date (YYYY-MM-DD). Absent when the crosswalk holds no record for this preprint — see notice." - changed
Output schema / properties / publishedJournal / descriptionPrevious value: -"Name of the publishing journal."New value: +"Name of the publishing journal. Absent when the crosswalk holds no record for this preprint — see notice."
- Changed
biorxiv_list_recent3 fields changed- changed
Input schema / properties / category / descriptionPrevious value: -"Subject category filter. Use biorxiv_list_categories for valid values."New value: +"Subject category filter, matched case-insensitively with \"_\" and \"-\" read as a space — \"Cell Biology\", \"cell biology\", \"cell_biology\", and \"cell-biology\" are the same filter. Use biorxiv_list_categories for valid values." - changed
Output schema / properties / error / properties / data / properties / reason / descriptionPrevious value: -"Machine-readable failure mode. Declared by this tool: `invalid_date_range`: end_date is before start_date, or either date is malformed. `invalid_category`: The supplied category string is not in the taxonomy. `upstream_unavailable`: Every attempted server failed against api.biorxiv.org, so no page was retrieved and an empty interval could not be established. `rate_limited`: Every attempted server failed and at least one was rejected with HTTP 429 by api.biorxiv.org. Other values are possible when a failure originates below the handler."New value: +"Machine-readable failure mode. Declared by this tool: `invalid_date_range`: end_date is before start_date, or either date is malformed. `invalid_category`: The category is not in the requested server's taxonomy, or api.biorxiv.org ignored it and returned the unfiltered listing on every server that answered. `upstream_unavailable`: Every attempted server failed against api.biorxiv.org, so no page was retrieved and an empty interval could not be established. `rate_limited`: Every attempted server failed and at least one was rejected with HTTP 429 by api.biorxiv.org. Other values are possible when a failure originates below the handler." - changed
Output schema / properties / notice / descriptionPrevious value: -"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."New value: +"Guidance on how to read this result set: which servers did not answer, which ignored the category filter (their unfiltered records are left out), 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."
- Changed
biorxiv_search_preprints4 fields changed- changed
Input schema / properties / cursor_mark / descriptionPrevious value: -"Opaque page token for ranked EuropePMC results. Omit for the first page; pass the nextCursorMark returned by a prior call to fetch the next page. Pages through the same ranked list rather than raising limit."New value: +"Opaque page token for ranked EuropePMC results. Omit for the first page; pass the nextCursorMark returned by a prior call to fetch the next page. Pages through the same ranked list rather than raising limit. A token EuropePMC does not recognize fails with invalid_cursor_mark." - changed
Output schema / properties / error / properties / data / properties / reason / descriptionPrevious value: -"Machine-readable failure mode. Declared by this tool: `invalid_date_range`: date_from or date_to is malformed, or date_from is after date_to. `search_unavailable`: EuropePMC search endpoint is unreachable or returns a server error. `rate_limited`: The EuropePMC search endpoint rejected the keyword search with HTTP 429. Distinct from a rate-limited enrichment call, which degrades to EuropePMC-only metadata instead of failing. Other values are possible when a failure originates below the handler."New value: +"Machine-readable failure mode. Declared by this tool: `invalid_date_range`: date_from or date_to is malformed, or date_from is after date_to. `search_unavailable`: EuropePMC search endpoint is unreachable, returns a server error, or answers a first-page search without a result list on every retry. `invalid_cursor_mark`: EuropePMC answers a cursor_mark page request without a result list on every retry — the token is malformed or not one EuropePMC issued. `rate_limited`: The EuropePMC search endpoint rejected the keyword search with HTTP 429. Distinct from a rate-limited enrichment call, which degrades to EuropePMC-only metadata instead of failing. Other values are possible when a failure originates below the handler." - changed
Output schema / properties / error / properties / data / properties / reason / examplesPrevious value: -[ - "invalid_date_range", - "search_unavailable", - "rate_limited" -]New value: +[ + "invalid_date_range", + "search_unavailable", + "invalid_cursor_mark", + "rate_limited" +] - changed
Output schema / properties / notice / descriptionPrevious value: -"Recovery hint when zero results are returned — echoes query and suggests how to broaden."New value: +"Present when zero results are returned. On a cursor_mark page past the last match, says the list is exhausted; otherwise echoes the query and suggests how to broaden it."
6 tool updates
- First observed
biorxiv_get_fulltext - First observed
biorxiv_get_preprint - First observed
biorxiv_get_published_version - First observed
biorxiv_list_categories - First observed
biorxiv_list_recent - First observed
biorxiv_search_preprints
Related MCP Connectors
Crossref MCP — wraps the Crossref REST API (academic papers, free, no auth)
PubMed MCP — wraps the NCBI E-utilities API (biomedical literature, free, no auth)
Search PubMed/Europe PMC, fetch articles and full text (PMC/EPMC/Unpaywall), citations, MeSH terms.
IEEE Xplore MCP — BYOK wrapper over the IEEE Xplore Metadata Search API…
Related MCP Servers
- AlicenseAqualityDmaintenanceMCP server that turns a medRxiv DOI into clean markdown full text and provides free, relevance-ranked preprint search via Europe PMC.21Apache 2.0
- AlicenseAqualityDmaintenanceProvides access to bioRxiv and medRxiv preprints via a unified tool with seven methods, including keyword search, metadata retrieval, and statistics.11MIT
- AlicenseNot gradedqualityAmaintenanceEnables searching bioRxiv preprints by topic, date window, or field, looking up any DOI's latest version, publication status, journal and retraction flag, browsing the newest preprints, and exporting results or digests as JSON, Markdown, CSV, or BibTeX. All tools return a stable JSON envelope with request metadata and structured error codes.MIT
- AlicenseNot gradedqualityBmaintenanceEnables querying bioRxiv and medRxiv preprints, including metadata, publication status, and submission counts, through natural language or direct tool calls.236 npmMIT
Glama MCP Gateway
Add one secure layer between your agents and this server.