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.

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

Read the thread · 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 · 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 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 · 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 · 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 · 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 · 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 · 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 · 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 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 · 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 · 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 · 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 · 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 · 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:

{ "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).