Allows retrieval of full text of medRxiv preprints from the official medRxiv AWS S3 archive (Requester-Pays) using the user's own AWS credentials.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@medrxiv-mcp Search medRxiv for recent preprints on long-COVID and summarize abstracts."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP server that turns a medRxiv DOI into clean markdown full text — plus free, relevance-ranked preprint search.
📄 Full-text retrieval — give it a DOI, get the whole paper as clean markdown (sections, tables, figure captions)
🔍 Free search — relevance-ranked medRxiv search via Europe PMC, returns DOI + title + abstract + date
🩺 Source of truth — full text comes from the official medRxiv .meca Text-and-Data-Mining archive, not scraped HTML
⚡ Lazy local index — a DOI→file index is built on demand and cached in sqlite, so repeat fetches in a month are instant
🔓 Your data, your key — full text reads a Requester-Pays S3 bucket with your own AWS key; nothing is shipped or shared
bioRxiv has its own package:
biorxiv-mcp.
This is a Model Context Protocol (MCP) server that gives AI assistants the full text of medRxiv preprints. Search is free (via the Europe PMC REST API). Full text is resolved from the official s3://medrxiv-src-monthly archive: the server maps a DOI to its month, scans that month's .meca archives once to build a local DOI→file index, downloads the one matching archive, extracts its JATS XML, and converts it to GitHub-flavored markdown with pandoc.
Designed for AI assistants like Claude to read primary literature directly. Works with any MCP-compatible client (Claude Desktop, Claude Code, or custom integrations).
Related MCP server: medRxiv-MCP-Server
uvx --from git+https://github.com/yogsoth-ai/medrxiv-mcp medrxiv-mcpNo manual install needed — uvx fetches and runs it. The bundled pandoc binary ships with the package, so you do not need a system pandoc.
Claude Code — .mcp.json in your project root
Claude Desktop — claude_desktop_config.json (~/Library/Application Support/Claude/ on macOS, %APPDATA%\Claude\ on Windows)
{
"mcpServers": {
"medrxiv": {
"command": "uvx",
"args": ["--from", "git+https://github.com/yogsoth-ai/medrxiv-mcp", "medrxiv-mcp"],
"env": {
"AWS_ACCESS_KEY_ID": "<your key id>",
"AWS_SECRET_ACCESS_KEY": "<your secret>",
"AWS_DEFAULT_REGION": "us-east-1"
}
}
}
}search_preprints is free and needs no key. fetch_fulltext reads a Requester-Pays bucket and does — see below.
The server starts automatically when the client needs it.
medRxiv full text is only reliably reachable through the official s3://medrxiv-src-monthly Text-and-Data-Mining bucket, which is Requester-Pays: you supply an AWS key, and your account pays the (tiny) transfer cost. The package never ships a key — each user brings their own.
Costs are small:
Action | Cost |
| free (Europe PMC, no AWS) |
First | ~$0.03 one-time (indexes that month) |
Each | well under $0.01 |
Setup: in the AWS IAM console, create a user, attach the AmazonS3ReadOnlyAccess policy, create an access key, and put it in the env block above. Deactivate the key whenever you're done.
Optional env:
Variable | Default | Purpose |
|
| where the local DOI→file sqlite cache lives |
|
| threads used when indexing a month |
Tool | Description |
| Search medRxiv by keyword (relevance-ranked, free via Europe PMC). Returns |
| Given a DOI, return the preprint's full text as markdown (reads the Requester-Pays S3 archive). |
The intended workflow: search_preprints to find a paper and get its DOI cheaply, then fetch_fulltext on that DOI when you want to read it.
Ask Claude things like:
"Search medRxiv for recent preprints on long-COVID cardiovascular outcomes and summarize the top 3 abstracts"
"Fetch the full text of a medRxiv DOI and walk me through its statistical methods"
"Find preprints on a vaccine-efficacy trial, then read the most relevant one in full"
git clone https://github.com/yogsoth-ai/medrxiv-mcp.git
cd medrxiv-mcp
pip install -e .
python -m pytest -v # offline suite — no AWS, no network
python -m medrxiv_mcp.server # run the server locally (needs AWS env for fetch)The offline test suite covers the non-trivial logic (JATS→markdown conversion and the .meca DOI parser) against fixtures it builds itself — no AWS spend, no network. Live search and S3 fetch are smoke-tested manually.
🧬 biorxiv-mcp — the bioRxiv twin
Fetch the full text of a preprint as markdown, given its DOI.
Downloads the paper's source package from the Requester-Pays S3 bucket (your AWS account pays a fraction of a cent), extracts the JATS XML, and converts it to markdown. First use of a given month is slower (it indexes that month once); later DOIs in the same month are fast.
| Name | Required | Description | Default |
|---|---|---|---|
| doi | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavioral traits: S3 download cost, extraction process, and caching behavior. This well compensates for missing annotations.
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?
Three sentences, front-loaded with main purpose, each sentence adds value. No wasted words.
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?
Covers inputs, process, and performance. Output schema exists, so return values are not needed. Missing error conditions (e.g., invalid DOI) slightly reduce completeness.
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 0%, so description should add parameter meaning. It indirectly clarifies the 'doi' parameter by stating it's a DOI, but does not provide format, examples, or validation details.
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 it fetches the full text of a preprint as markdown given its DOI. It is distinct from the sibling tool search_preprints, which searches for preprints.
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?
The description provides context on when to use (given a DOI) and performance implications (first use of month slower). However, it lacks explicit 'when not to use' or comparison to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search bioRxiv/medRxiv preprints by keyword (relevance-ranked, free).
Returns a list of {doi, title, abstract, date}. Use the doi with fetch_fulltext to read the full text.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries the burden. It discloses that results are relevance-ranked, free, and returns a structured list (doi, title, abstract, date). However, it doesn't mention possible empty results or error handling, but the output format is well-described.
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 extremely concise with two sentences, no wasted words, and essential information front-loaded: purpose, features (relevance, free), output format, and sibling relationship.
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 the output schema exists (though not shown), the description covers the return structure sufficiently. It addresses integration with the sibling tool. It lacks details on pagination or error cases, but for a simple search tool, it is reasonably complete.
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 0% with no parameter descriptions. The description explains that 'query' is a keyword, and the 'limit' parameter is implied with a default of 20. It adds some meaning beyond the schema but does not fully elaborate on their behavior or constraints.
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 searches bioRxiv/medRxiv preprints by keyword, mentions relevance-ranking and free access, and distinguishes from the sibling fetch_fulltext by advising to use the DOI with that tool.
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 says when to use (by keyword) and provides a link to the sibling tool for full-text retrieval, giving clear guidance on tool choice with no ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v2.0.0fetch_fulltextsearch_preprintsScored across 2 tools
The two tools have completely distinct purposes: one searches for preprints by keyword, the other fetches the full text of a specific preprint by DOI. There is no overlap or ambiguity.
Both tools follow the verb_noun pattern consistently: 'search_preprints' and 'fetch_fulltext'. The naming is clear and predictable.
With only two tools, the server feels minimal but covers the essential use case of finding and reading preprints. However, it is borderline thin and could benefit from additional tools for filtering or listing.
The tool surface covers the core workflow—search and fetch—but lacks features like filtering by date, author, or category, or listing recent preprints. Minor gaps exist that agents can work around.
Auditable MCP server for PubMed, Europe PMC, ClinicalTrials.gov, and bioRxiv/medRxiv queries
MCP server for Altmetric APIs - track research attention across news, policy, social media, and more
PubMed MCP — wraps the NCBI E-utilities API (biomedical literature, free, no auth)
bioRxiv + medRxiv preprint server API
