# Reported issues for biorxiv-mcp-server

Pod holds 18 of 40 problems reported by people outside the maintainer team. Issues filed by the project's own owners, members and collaborators are excluded entirely — a maintainer's release checklist is not a warning to a prospective user.

Back to [biorxiv-mcp-server](/mcp/biorxiv-mcp-server).

## Most discussed

### docs(tools): remove implementation details from advertised tool schemas

Several `tools/list` descriptions expose implementation mechanics rather than just caller-facing behavior. This makes the catalog noisier for clients and creates schema text that can drift from the actual implementation.

## Proposal

Tighten the advertised descriptions so they describe what each tool returns and when to use it, without backend/routing details or framework internals.

### Examples from today's `tools/list`

| Surface | Current text | Issue |
|:--|:--|:--|
| `biorxiv_search_prepr

[Read the thread](https://github.com/cyanheads/biorxiv-mcp-server/issues/26) · 2026-06-26 · closed · 3 comments

### bug(outputs): raw upstream abstract markup leaks into tool results

### Server version

0.1.15

### mcp-ts-core version

0.10.9

### Runtime

Bun

### Runtime version

Bun 1.3.11

### Transport

Streamable HTTP

### Description

Several live preprint outputs relay raw upstream abstract artifacts directly into `structuredContent` and rendered `content[]`. This makes the abstract harder to read and can pull figure/export boilerplate into the LLM-facing result body.

### Steps to reproduce

1. Start the built server with `MCP_TRANSPORT_TYPE=http bun ./dist/index.js

[Read the thread](https://github.com/cyanheads/biorxiv-mcp-server/issues/25) · 2026-06-26 · closed · 3 comments

### bug(EuropePmcService): a 429 from EuropePMC fails the search as search_unavailable, dropping the origin's Retry-After

### Server version

0.2.2

### mcp-ts-core version

0.11.1

### Runtime

Bun

### Runtime version

Bun 1.3.x

### Transport

HTTP

### Description

Related: #41

`EuropePmcService` has no HTTP 429 handling, so a rate limit from the [EuropePMC](https://europepmc.org/) REST endpoint reaches `biorxiv_search_preprints` as `search_unavailable` — the reason declared for "unreachable or returns a server error". A 429 is neither, and the `Retry-After` the origin sent is dropped on the way out, so the ca

[Read the thread](https://github.com/cyanheads/biorxiv-mcp-server/issues/42) · 2026-08-09 · closed · 2 comments

### bug(BiorxivApiService): a 429 from api.biorxiv.org arrives untyped with the upstream body attached

`BiorxivApiService` (the `api.biorxiv.org` JSON path, backing `biorxiv_get_preprint`, `biorxiv_search_preprints`, `biorxiv_list_recent`, `biorxiv_get_published_version`) has no HTTP 429 handling. It carries only a `detectHtmlError` heuristic that maps an HTML response body to "likely rate-limited" — a guess that fires on a 2xx-with-HTML, not on the status code that actually says so.

A real 429 from this origin bubbles as a bare `RateLimited` error with no `data.reason`, no recovery hint, and — 

[Read the thread](https://github.com/cyanheads/biorxiv-mcp-server/issues/41) · 2026-08-09 · closed · 2 comments

### bug(biorxiv_list_recent): a total upstream failure returns an empty success, where biorxiv_get_preprint throws a retryable error

When both servers fail under `server: "both"`, `biorxiv_list_recent` returns a successful result with an empty `preprints` array, a `failed[]` entry per server, and a notice saying nothing was retrieved. `biorxiv_get_preprint`, given the same condition — nothing resolved and every attempted server failed — throws the declared retryable error `upstream_unavailable`.

Two tools in the same server answer the same situation with opposite response shapes. An agent caller that branches on success-vs-e

[Read the thread](https://github.com/cyanheads/biorxiv-mcp-server/issues/40) · 2026-08-09 · closed · 2 comments

### bug(biorxiv_list_recent): a failed server in server="both" is dropped from pagination with no notice, so a partial result reads as complete

With `server: "both"`, `biorxiv_list_recent` fans out across bioRxiv and medRxiv. When one server's `getListing` rejects, the handler logs a warning server-side and omits that server's entry from `pagination` entirely. The response is otherwise indistinguishable from a healthy single-server result: no notice, no error, nothing in `structuredContent` or `content[]` marking that a server was attempted and failed.

A caller asking for both servers and receiving only bioRxiv records has no way to te

[Read the thread](https://github.com/cyanheads/biorxiv-mcp-server/issues/39) · 2026-08-09 · closed · 2 comments

### bug(biorxiv_get_fulltext): medRxiv preprints miss at the default server because the DOI prefix does not identify the server

`biorxiv_get_fulltext` declares `server: z.enum(['biorxiv', 'medrxiv']).default('biorxiv')`. bioRxiv and medRxiv share the `10.1101/` DOI prefix, so a caller holding a bare DOI cannot tell from it which value to pass. At the default, a medRxiv preprint returns `doi_not_found` even though the article exists and its full text is retrievable one enum value away.

This is the same DOI-prefix-is-not-a-discriminator failure mode tracked for `biorxiv_get_published_version` in #34 and fixed for `biorxiv

[Read the thread](https://github.com/cyanheads/biorxiv-mcp-server/issues/38) · 2026-08-09 · closed · 2 comments

### bug(biorxiv_get_fulltext): origin rate limiting surfaces as an untyped error with no recovery, after four retries against the limiter

### Server version

0.2.0

### mcp-ts-core version

0.10.14

### Runtime

Bun

### Runtime version

Bun 1.3.14

### Transport

Streamable HTTP

### Description

`BiorxivFullTextService` classifies deterministic access failures via `DETERMINISTIC_UNAVAILABLE_STATUSES` = `{401, 403, 404, 410, 451}`. HTTP 429 is absent, so a Cloudflare rate-limit response takes the transient path: `withRetry` burns four attempts against an active limiter with plain exponential backoff from `baseDelayMs: 500` — a fe

[Read the thread](https://github.com/cyanheads/biorxiv-mcp-server/issues/37) · 2026-08-09 · closed · 2 comments

## Most recent

### feat(biorxiv_get_fulltext): cache extracted full text so offset paging does not refetch the origin per chunk

`biorxiv_get_fulltext` refetches and re-extracts the entire article on every call. `fetchFullText()` runs unconditionally before `offset`/`limit` are applied, so paging is a full origin round-trip plus a full [Defuddle](https://github.com/kepano/defuddle) extraction per chunk. bioRxiv and medRxiv sit behind a Cloudflare edge that rate-limits within a handful of requests, so the tool's own documented paging mechanism reliably rate-limits the tool out of service partway through a long article.

##

[Read the thread](https://github.com/cyanheads/biorxiv-mcp-server/issues/36) · 2026-08-09 · closed · 2 comments

### bug(biorxiv_list_recent): server="both" reports total 0 for the server whose cursor overshot, with no notice

### Server version

0.2.0

### mcp-ts-core version

0.10.14

### Runtime

Bun

### Runtime version

Bun 1.3.14

### Transport

Streamable HTTP

### Description

With `server: "both"`, the two servers hold different result counts for the same date interval, so a single `cursor` can be valid for one and past the end for the other. The bioRxiv API returns `total: 0` for an out-of-range cursor, and that 0 is passed straight through as `pagination.<server>.total` — an authoritative-looking count that

[Read the thread](https://github.com/cyanheads/biorxiv-mcp-server/issues/35) · 2026-08-09 · closed · 2 comments

### bug(biorxiv_get_published_version): medRxiv preprints are unreachable at the default server, and the not-found recovery asserts they are unpublished

### Server version

0.2.0

### mcp-ts-core version

0.10.14

### Runtime

Bun

### Runtime version

Bun 1.3.14

### Transport

Streamable HTTP

### Description

`biorxiv_get_published_version` accepts only `server: "biorxiv" | "medrxiv"` and defaults to `biorxiv`. Both servers share the `10.1101/` DOI prefix, so a caller holding a medRxiv DOI has no way to tell from the DOI which value to pass. At the default, a published medRxiv preprint returns `doi_not_found` with a recovery hint that states 

[Read the thread](https://github.com/cyanheads/biorxiv-mcp-server/issues/34) · 2026-08-09 · closed · 2 comments

### feat(biorxiv_search_preprints): preserve complete latest-revision metadata during enrichment

`biorxiv_search_preprints` advertises enrichment with full bioRxiv/medRxiv metadata, but the enriched result projection drops `type`, `license`, `funder`, and `authorCorrespondingInstitution` from the latest revision. The same DOI returns these fields through `biorxiv_get_preprint`, so search clients lose available metadata even when `enriched: true`.

## Proposal

Carry every latest-revision metadata field already exposed by `biorxiv_get_preprint` into enriched search results, and render each f

[Read the thread](https://github.com/cyanheads/biorxiv-mcp-server/issues/33) · 2026-07-13 · closed · 2 comments

### bug(biorxiv_get_preprint): upstream failures are misreported as DOI not found

### Server version

0.2.0

### mcp-ts-core version

0.10.14

### Runtime

Bun

### Runtime version

Bun 1.3.14

### Transport

Streamable HTTP

### Description

`biorxiv_get_preprint` converts upstream connection failures into the non-retryable `doi_not_found` contract when every requested lookup fails. A valid DOI is reported as nonexistent, so callers receive the wrong recovery action instead of retry guidance.

### Steps to reproduce

1. Start the server with an unreachable API origin: `BIORX

[Read the thread](https://github.com/cyanheads/biorxiv-mcp-server/issues/32) · 2026-07-13 · closed · 2 comments

### bug(biorxiv_get_preprint): content output omits revision metadata

### Server version

0.1.15

### mcp-ts-core version

0.10.9

### Runtime

Bun

### Runtime version

Bun 1.3.14

### Transport

HTTP (Streamable HTTP)

### Description

`biorxiv_get_preprint` returns complete revision objects in `structuredContent`, but its rendered `content[]` omits revision-level metadata. Clients that consume text see less data than clients that consume structured results.

### Steps to reproduce

1. Call `biorxiv_get_preprint` with:

```json
{ "dois": ["10.1101/2023.09.16.558

[Read the thread](https://github.com/cyanheads/biorxiv-mcp-server/issues/31) · 2026-07-11 · closed · 1 comment

### feat(biorxiv_search_preprints): add pagination for EuropePMC search results

`biorxiv_search_preprints` now surfaces EuropePMC `hitCount` through `totalCount`, but the tool still only exposes the first page of results. When `totalCount` exceeds `limit`, callers can see that more matches exist but have no way to request the next page.

Related: #22

## Proposal

Add opaque pagination support for the EuropePMC-backed search path. EuropePMC already returns `nextCursorMark`, and the service currently always sends `cursorMark=*`; thread that cursor through the service and too

[Read the thread](https://github.com/cyanheads/biorxiv-mcp-server/issues/30) · 2026-07-04 · closed · 1 comment

### bug(date-validation): reject impossible calendar dates before upstream calls

### Server version

0.1.15

### mcp-ts-core version

0.10.9

### Runtime

Bun

### Runtime version

Bun 1.3.11

### Transport

Streamable HTTP

### Description

`biorxiv_list_recent` and `biorxiv_search_preprints` validate date inputs with a `YYYY-MM-DD` regex only. Calendar-impossible dates such as `2024-13-01` pass validation and reach upstream APIs, which either return an empty page or ignore the date filter.

Related: #2, #9

### Steps to reproduce

1. Call `biorxiv_list_recent` with input:

[Read the thread](https://github.com/cyanheads/biorxiv-mcp-server/issues/29) · 2026-07-04 · closed · 1 comment

### feat(biorxiv_list_recent): avoid mixed filtered and unfiltered results for cross-server category filters

Related: #17

`biorxiv_list_recent` currently accepts `server=\"both\"` plus a category that exists on only one server, applies the filter to that server, and returns unfiltered results from the other server. The response includes `categoryNote`, but the result set still mixes filtered and unfiltered records under a single filtered-looking request.

## Proposal

When `server=\"both\"` and `category` belongs to only one taxonomy, return only the matching server's filtered page by default, or add 

[Read the thread](https://github.com/cyanheads/biorxiv-mcp-server/issues/27) · 2026-06-26 · closed · 1 comment

### bug(metadata): server version surfaces drift from package.json

### Server version

0.1.15

### mcp-ts-core version

0.10.9

### Runtime

Bun

### Runtime version

Bun 1.3.11

### Transport

stdio and Streamable HTTP

### Description

Version-related surfaces have drifted from `package.json`. `package.json`, `server.json`, and `manifest.json` report `0.1.15`, but outbound User-Agent headers use `SERVER_VERSION = '0.1.11'`, and the README version badge still says `0.1.14`.

### Steps to reproduce

1. Inspect `package.json`: version is `0.1.15`.
2. Inspect `sr

[Read the thread](https://github.com/cyanheads/biorxiv-mcp-server/issues/28) · 2026-06-26 · closed · 1 comment

The remaining reports are on [the project's issue tracker](https://github.com/cyanheads/biorxiv-mcp-server/issues).