Skip to main content
Glama
yeyuan98

BioMCP

by yeyuan98
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

preprint_fulltext

Read-only

Fetch complete bioRxiv or medRxiv preprint full text by DOI (latest or specified version), parsed into sections and returned as a file or inline text for reading and analysis.

Instructions

On-demand bioRxiv/medRxiv preprint full text (JATS XML, parsed to sections). Input: a preprint DOI (e.g. "10.1101/2025.03.05.641768"), optional version (default: latest). Downloads are strictly on-demand (never run during search), paced, and cached per (doi, version) — JATS per version is immutable, so repeat calls are served from cache without re-downloading. www.biorxiv.org rate-limits aggressively: on a 429/Cloudflare verdict this tool pauses downloads for >=60s (Retry-After honored) and every call during the cooldown returns an honest unavailable/rate_limited envelope with retry_after_sec — cached copies are still served instantly. The per-article license (cc by, cc by-nc-nd, na, ...) rides on every reply and governs reuse; for corpus-scale text mining use the bioRxiv/medRxiv monthly S3 buckets (see https://www.biorxiv.org/tdm). Output "file" (default): complete text written to a server-side markdown file, reply carries file_path + outline (Read/Grep selectively); "inline": capped text sections (fulltext_max_chars, default 40000).

Input Schema

NameRequiredDescriptionDefault
idYesbioRxiv/medRxiv preprint DOI (e.g. "10.1101/2021.10.25.465764", "10.64898/2026.08.11.744243"); journal-article identifiers are rejected — use article_get for those
outputNo"file" (default): complete text in a server-side markdown file; the reply carries file_path + outline. "inline": text sections returned inline, capped by fulltext_max_chars.
versionNoPreprint version to fetch (default: latest). Pinned versions are served from cache with zero network when already fetched.
fulltext_max_charsNoInline-mode only (output="inline"); default 40000. Ignored in file mode — files carry the complete text (2MB safety cap).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.6.0-alpha.10
    • removedInput schema / additionalProperties
      Removed value: -false
    • addedInput schema / properties / version / maximum
      Added value: +9007199254740991
  2. Changed2 schema fields changedv1.6.0-alpha.7
    • addedInput schema / properties / id / minLength
      Added value: +1
    • addedInput schema / properties / id / pattern
      Added value: +"^10\\.1101\\/\\d{4}\\.\\d{2}\\.\\d{2}\\.\\d+$|^10\\.64898\\/\\S+$"
  3. Addedv1.6.0-alpha.3

TDQS

A4.6/5.0
Behavior5/5

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

Annotations only declare readOnly/openWorld, but the description adds substantial operational context: per-(doi,version) caching, immutability of JATS per version, aggressive rate limiting with >=60s cooldown, 429/Cloudflare handling, retry_after_sec envelopes, and per-article license carriage. This is exactly the kind of behavior an agent needs and cannot get from annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Dense but front-loaded: purpose, input, on-demand policy, rate-limit behavior, license, output modes in a logical order. It is longer than strictly necessary — the rate-limit and caching points are each stated with some redundancy — but nearly every sentence carries operational value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with no output schema, the description fully explains both return shapes (file_path + outline vs. capped inline sections) and the failure envelope. Combined with the four fully documented parameters, an agent has everything needed to invoke it correctly.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3; the description goes further by explaining why version is cacheable (immutable JATS per version), that fulltext_max_chars is inline-only and ignored in file mode, and that pinned versions serve with zero network. Sibling-tool rejection of journal DOIs is also reinforced.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ("preprint full text" from bioRxiv/medRxiv, JATS XML parsed to sections) and names the DOI input format. It is clearly distinguishable from article_get, which the schema explicitly routes journal-article identifiers to.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says downloads are strictly on-demand and never run during search, and redirects corpus-scale text mining to the bioRxiv/medRxiv S3 buckets. It does not, however, directly name the sibling to use for journal articles or for metadata-only lookups within the description text itself.

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

Deploy Server

Other Tools