How do I use pmc-pdf-downloader?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@pmc-pdf-downloader 批量下载 input.csv 里的所有 PDF 到 D:/papers" 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.

pmc-pdf-downloader

by oranges7

Overview Schema Source Related Servers Discussions Admin

Python

Local

PMC PDF 下载器 MCP Server

通过 MCP 协议批量下载 PMC 开放获取 PDF，支持 PoW 验证自动绕过、并行下载、失败重试。

快速开始

1. 安装 uv（一次性）

uv 是单一二进制的 Python 包管理工具，安装命令一行：

# Mac/Linux
curl -LsSf https://astral.sh/uv/install.sh | sh

# Windows PowerShell
powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 | iex"

2. 安装 Chromium（一次性）

Playwright 的 chromium 浏览器无法通过 pip 安装，需手动运行一次：

# 方式 A：使用 uvx 直接从 git 仓库运行（推荐，无需克隆）
uvx --from git+https://github.com/oranges7/pmc-pdf-downloader playwright install chromium

# 方式 B：克隆后本地运行
git clone https://github.com/oranges7/pmc-pdf-downloader
cd pmc-pdf-downloader
uv sync
uv run playwright install chromium

3. 配置 MCP 客户端

Trae IDE / Claude Desktop

编辑 MCP 配置文件（如 claude_desktop_config.json），加入：

{
  "mcpServers": {
    "pmc-pdf-downloader": {
      "command": "uvx",
      "args": [
        "--from",
        "git+https://github.com/oranges7/pmc-pdf-downloader",
        "pmc-pdf-downloader"
      ]
    }
  }
}

Cursor

Settings → MCP → Add New MCP Server：

Type: stdio
Command: uvx
Args: --from git+https://github.com/oranges7/pmc-pdf-downloader pmc-pdf-downloader

本地克隆版（不想推 GitHub 时用）

{
  "mcpServers": {
    "pmc-pdf-downloader": {
      "command": "uv",
      "args": [
        "run",
        "--directory",
        "D:/path/to/pmc-pdf-downloader",
        "pmc-pdf-downloader"
      ]
    }
  }
}

4. 使用

配置完成后，LLM 即可调用以下 4 个工具：

工具	用途	关键参数
`lookup_pmcid`	查询 PMID 对应的 PMCID	`pmid`
`download_single_pdf`	下载单个 PMC PDF	`pmcid`, `output_dir`, `pmid?`
`batch_download_pdfs`	批量下载（CSV/TXT 输入）	`input_file`, `output_dir`, `mode?`, `num_workers?`
`get_download_report`	读取下载报告全文	`output_dir`

示例对话：

"帮我查 PMID 42534757 的 PMCID"
"下载 PMC7440785 的 PDF 到 D:/papers"
"批量下载 input.csv 里的所有 PDF 到 D:/papers，CSV 格式"
"看一下 D:/papers 的下载报告"

Related MCP server: Paper Download MCP Server

关于浏览器

默认情况下无需配置浏览器位置。运行 playwright install chromium 后，浏览器会自动安装到用户目录的默认位置，MCP server 启动时自动查找：

Windows: %USERPROFILE%\AppData\Local\ms-playwright\chromium-XXXX
Mac/Linux: ~/.cache/ms-playwright/chromium-XXXX

可选环境变量（特殊场景）：

环境变量	用途	示例
`PLAYWRIGHT_BROWSERS_PATH`	自定义 chromium 安装/查找目录（如系统盘空间不足时）	`D:/playwright-browsers`
`PMC_PDF_EXECUTABLE_PATH`	直接指向系统已装的 Chrome/Edge 可执行文件，跳过 chromium 下载	`C:\Program Files\Google\Chrome\Application\chrome.exe`

本地开发

git clone https://github.com/oranges7/pmc-pdf-downloader
cd pmc-pdf-downloader
uv sync                              # 自动建虚拟环境、装依赖
uv run playwright install chromium   # 一次性
uv run pmc-pdf-downloader            # 启动 MCP server

输入文件格式

CSV 模式

含两列：PMID 和 PMCID：

PMID,PMCID
42534757,PMC7440785
37984867,PMC10787064

TXT 模式

每行一个 PMID，server 会自动调 NCBI elink API 查询 PMCID：

42534757
37984867
38133632

输出

PDF 文件命名：<PMID>_<PMCID>.pdf（如 42534757_PMC7440785.pdf）
已存在文件自动跳过
下载报告：<output_dir>/download_report.txt，含成功/失败统计与失败原因

Available Tools

4 tools

batch_download_pdfsA

批量下载 PMC PDF。自动跳过已存在的文件，失败自动重试 1 次。

Args:
    input_file: 输入文件路径。CSV 需含 PMID+PMCID 两列；TXT 每行一个 PMID（会自动查询 PMCID）
    output_dir: PDF 保存目录的绝对路径
    mode: "csv" 或 "txt"，默认 "csv"
    num_workers: 并行下载线程数，默认 2
Returns:
    汇总信息字符串，如 "完成: 成功 2400, 失败 36, 报告: <path>"

ParametersJSON Schema

Name	Required	Default
`mode`	No	csv
`input_file`	Yes
`output_dir`	Yes
`num_workers`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.1/5.0

Behavior4/5

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

No annotations are provided, so the description carries the full burden. It discloses key behaviors: automatic skipping of existing files, a single retry on failure, parallel download via num_workers, and the summary return format. This goes well beyond the tool's name and provides useful operational details, though it omits potential rate limits or permission prerequisites.

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?

The description uses a clear 'Args' list and a 'Returns' line, front-loading the purpose and behavior. It is efficient, with no wasted words, though the return example could be slightly more compact. The structure aids quick parsing.

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

Completeness4/5

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

For a complex batch tool, this is comprehensive: it covers input formats, output directory, mode, concurrency, retry, skip behavior, and the return summary string. The lack of explicit error-handling details is minor, but the description is sufficient for an agent to call the tool 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 description coverage is 0%, so the description must compensate. It explains every parameter: input_file (with format specifics for CSV and TXT), output_dir (absolute path), mode (accepted values and default), and num_workers (thread count and default). This adds significant meaning beyond the schema's bare types and defaults.

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?

The description states a specific verb ('download') with a resource ('PMC PDFs') and clearly identifies a batch operation. It distinguishes itself from siblings like 'download_single_pdf' by the explicit 'batch' scope, so an agent can select it without ambiguity.

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

Usage Guidelines3/5

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

The description explains the two input modes ('csv' and 'txt') and the automatic PMCID query for TXT, giving clear context for when this tool is appropriate. However, it does not explicitly compare against alternatives like 'download_single_pdf' or state exclusion conditions, so the routing is implied rather than stated.

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

download_single_pdfA

下载单个 PMC 文章的 PDF。已存在文件会自动跳过。

Args:
    pmcid: PMCID（如 "PMC7440785"）
    output_dir: PDF 保存目录的绝对路径
    pmid: 可选 PMID，用于文件名前缀（默认空）
Returns:
    成功返回 "OK: <bytes> bytes"，失败返回 "FAIL: <error>"

ParametersJSON Schema

Name	Required	Description	Default
`pmid`	No
`pmcid`	Yes
`output_dir`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.5/5.0

Behavior4/5

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

With no annotations, the description carries the full burden. It discloses the auto-skip existing files behavior and the return format ('OK: <bytes> bytes' or 'FAIL: <error>'), which is useful. It does not cover potential side effects like directory creation, but for a simple download tool this is adequate.

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

Conciseness5/5

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

The description is succinct, front-loaded with the core purpose, then structured Args and Returns sections. Every sentence adds value with no fluff or repetition of schema details.

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

Completeness4/5

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

For a 3-parameter tool with no complex nesting or enums, the description covers all parameters, the auto-skip behavior, and return values. It lacks explicit mention of whether output_dir is created automatically, a minor gap, but overall complete enough.

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

Parameters5/5

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

The Args section explains every parameter with examples and defaults: pmcid with a concrete example, output_dir as an absolute path, and pmid as optional with default empty. This fully compensates for the 0% schema description coverage.

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?

The description explicitly states the tool downloads a single PMC article PDF, using '单个' (single) to clearly distinguish it from batch_download_pdfs. The verb and resource are specific, and the auto-skip behavior adds further clarity.

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?

The description implies a single-article use case via '单个' and the sibling batch_download_pdfs provides an obvious contrast. However, it does not explicitly state when to choose this over batch or mention any exclusions. The context is clear but not fully explicit.

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

get_download_reportA

读取指定目录下的 download_report.txt 下载报告内容。

Args:
    output_dir: 之前批量下载时指定的输出目录
Returns:
    报告文件全文。若文件不存在返回 "报告不存在"

ParametersJSON Schema

Name	Required	Description	Default
`output_dir`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.6/5.0

Behavior4/5

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

With no annotations, the description carries the full burden. It discloses that the tool reads the report file, returns its full text, and returns a specific fallback message when the file does not exist. This is sufficient for a simple read-only retrieval tool.

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

Conciseness5/5

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

The description is short, well-structured with Args and Returns sections, and every sentence adds useful information. There is no redundancy or unnecessary detail.

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 one-parameter, read-only tool with an output schema, the description covers the input semantics, the return value, and the missing-file behavior. Nothing essential is left out.

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

Parameters5/5

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

Schema coverage is 0%, so the description fully compensates. It explains that output_dir is the output directory from a previous batch download, giving the agent the needed context to supply the correct path, which the bare schema does not provide.

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?

The description states a specific verb and resource: it reads the download_report.txt file in a given directory. This clearly distinguishes it from the sibling download tools, which perform downloads rather than report retrieval.

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?

The description explains that output_dir refers to the output directory previously used during a batch download, which implicitly signals that this tool is meant to be used after batch_download_pdfs. It gives clear context but does not explicitly state when not to use it or mention alternative tools.

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

lookup_pmcidA

通过 NCBI elink API 查询 PMID 对应的 PMCID。

Args:
    pmid: PubMed ID（如 "42534757"）
Returns:
    PMCID（如 "PMC7440785"）；若文章未在 PMC 开放获取则返回空字符串

ParametersJSON Schema

Name	Required	Description	Default
`pmid`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.7/5.0

Behavior3/5

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

With no annotations provided, the description carries the burden of behavioral disclosure. It mentions the use of the NCBI elink API (implying network call) and specifies the return behavior for not-found cases (empty string). However, it does not disclose potential errors, rate limits, or authentication requirements. For a simple lookup tool, this is moderately transparent.

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

Conciseness5/5

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

The description is concise and well-structured: a one-sentence function summary followed by clearly labeled Args and Returns sections. Every sentence earns its place, and the format is easy to parse.

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

Completeness4/5

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

For a single-parameter lookup tool, the description covers the input, output, and the special case of empty return. It does not mention error handling or prerequisites, but those are not critical for this simple operation. The presence of an output schema (though not shown) may also cover return details.

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

Parameters5/5

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

The schema for 'pmid' has no description (0% coverage), so the description must compensate. It clearly explains the parameter as 'PubMed ID' and provides an example ('42534757'), fully adding meaning beyond the schema. This meets the high-bar requirement.

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

Purpose4/5

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

The description clearly states the tool's function: querying a PMCID for a given PMID via the NCBI elink API. It specifies the resource (PMCID), the input (PMID), and the API used. While it doesn't explicitly contrast with siblings, the siblings are download tools, so the purpose is distinct enough.

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

Usage Guidelines2/5

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

The description provides no explicit guidance on when to use this tool versus alternatives. It only describes the function without stating conditions such as 'use when you need to convert a PMID to a PMCID' or when not to use other tools. Usage context is implied but not articulated.

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.

4 tool updatesv0.1.0Sep 1, 2026
- First observedbatch_download_pdfs
- First observeddownload_single_pdf
- First observedget_download_report
- First observedlookup_pmcid

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.3/5.0

Scored 2026-09-01 07:30 across 4 tools

Disambiguation5/5

Each tool handles a distinct stage of the PDF download workflow: identifier lookup, single download, batch download, and report retrieval. There is no functional overlap between them, so an agent can clearly select the right tool for a given task.

Naming Consistency5/5

All tool names follow a predictable snake_case pattern with action-first naming: lookup_pmcid, download_single_pdf, batch_download_pdfs, get_download_report. The naming clearly communicates both the action and the target, making the set easy to navigate.

Tool Count5/5

Four tools is well-scoped for a focused PDF downloader server. Each tool serves a necessary part of the workflow without unnecessary redundancy or excessive surface area.

Completeness5/5

The tool set covers the full end-to-end workflow: converting PMIDs to PMCIDs, downloading individual PDFs, handling batch downloads with retries, and retrieving a final report. No obvious gaps exist for the stated purpose of downloading PMC PDFs.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

Biolab MCP Server
io.github.srikarjy
Auditable MCP server for PubMed, Europe PMC, ClinicalTrials.gov, and bioRxiv/medRxiv queries
Biology & Medicine Search Open Data
1
Pubmed A
io.github.pipeworx-io
PubMed MCP — wraps the NCBI E-utilities API (biomedical literature, free, no auth)
Research & Data Biology & Medicine Search
21
Folklore Clinical Variant Interpretation MCP A
io.github.helena-bioinformatics
Bioinformatics MCP for genomic variant interpretation, gene-disease evidence and literature.
Bioinformatics Biology & Medicine Research & Data
711
PapersFlowOAuth
io.github.papersflow-ai
Academic research MCP server for paper search, citation checks, graphs, and deep research.
Research & Data Search Documentation Access
214

Related MCP Servers

PubMed MCP Server
Research & Data Open Data Search
rikachu225
-
license
Not graded
quality
Not graded
maintenance
An MCP server implementation that enables searching and retrieving research articles from PubMed with specific focus on open access content filtering and full-text link retrieval.
Updated 2 years ago (2024-12-12 16:47 UTC)
8 npm
3
-
Paper Download MCP Server
Research & Data Search Developer Tools
Oxidane-bot
A
license
A
quality
B
maintenance
An MCP server for downloading academic papers from multiple sources using intelligent routing and year-aware priority selection. It enables users to retrieve metadata and download single or batch PDFs by DOI or URL.
Updated 6 months ago (2026-03-17 01:23 UTC)
3
27 PyPI
2
MIT
PubMed MCP Server
Search Biology & Medicine Research & Data
masa061580
A
license
A
quality
D
maintenance
A local MCP server enabling PubMed, PMC, and iCite API access via stdio for tools like search, fetch, full text, and citation counts.
Updated 4 months ago (2026-05-18 11:35 UTC)
10
59 npm
2
MIT
scipdf-mcp
Research & Data Open Data
gjjisadog
A
license
A
quality
A
maintenance
MCP server for downloading academic papers from DOI or title, resolving references, and generating citations. Supports batch downloads, multiple mirrors, and optional Unpaywall integration.
Updated 2 months ago (2026-07-31 00:25 UTC)
11
2
MIT