How do I use OpenPapers MCP?

1. Click on "Install 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., "@OpenPapers MCP Search for the latest papers on climate change and AI" 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.

OpenPapers MCP

by Kaago

Overview Schema Related Servers Score Discussions

Python

Local

OpenPapers MCP

License: MIT Python 3.12+ Tests

A local Model Context Protocol server for scientific paper research — search, metadata, abstracts, and legal Open Access PDF downloads. Runs entirely on your machine over stdio. Works with Claude Desktop, ZCode, Cursor, and any other MCP client.

Why use this instead of hitting the APIs directly? It abstracts three open scholarly APIs into five LLM-callable tools, reconstructs abstracts from OpenAlex's inverted index, finds legal OA copies via Unpaywall, and safely downloads PDFs (SSRF-safe, magic-byte-verified, atomic). No Sci-Hub, no paywall bypass, no institutional license required.

Backed by three free, open APIs

API	Role	Auth
OpenAlex	Search, metadata, abstracts (inverted index), concepts, citations	`mailto` (polite pool)
CrossRef	DOI lookup, reference list, funders, publisher	`mailto` + User-Agent
Unpaywall	Legal Open Access PDFs from repositories & publishers	`email`

What this is not: No Sci-Hub, no paywall bypass, no EBSCO (which needs an institutional license). Only legitimately OA sources via Unpaywall.

Related MCP server: rag-paper

Quick start

git clone https://github.com/Kaago/openpapers-mcp.git
cd OpenPapers
cp .env.example .env        # then edit CONTACT_EMAIL
uv sync                     # install deps
uv run pytest               # 69 offline tests (+ 3 live tests gated on OPENPAPERS_LIVE=1)
uv run openpapers           # start the stdio MCP server

Requirements: Python ≥ 3.12 and uv.

Tools

Tool	Description
`search_papers(query, num_results=10, year_from?, year_to?)`	OpenAlex relevance search. Returns DOI, title, authors, year, venue, citations, OA status, concepts.
`get_paper(doi)`	Full metadata + abstract (reconstructed) + references (CrossRef-enriched) + authors with ORCID/affiliations + funders + publisher.
`find_oa_pdf(doi)`	Unpaywall lookup. Returns `is_oa`, best OA location with direct PDF URL, all OA locations (version, license, host type).
`download_pdf(url, doi?, filename?)`	Streams the PDF to `$PDF_DIR`. SSRF-safe (private/loopback/metadata IPs refused), magic-byte-verified (`%PDF-`), capped at `PDF_MAX_BYTES`, written atomically (no partial files).
`research_topic(query, max_results=5)`	Convenience: searches + enriches top results with OA status concurrently. Compact overview for scoping an area.

Typical workflow

search_papers("transformer attention")              → list of candidates
  └─ get_paper("10.48550/arXiv.1706.03762")         → full record + abstract
  └─ find_oa_pdf("10.48550/arXiv.1706.03762")       → OA URL
       └─ download_pdf("<url>", "10.48550/arXiv.1706.03762")  → local file

Configuration

All configuration lives in .env (git-ignored). See .env.example:

# Your email — sent only as mailto=/User-Agent to the three APIs.
# Set POLITE_POOL=0 to withhold it entirely (privacy mode).
CONTACT_EMAIL=your-email@example.com
POLITE_POOL=1

# Where downloaded PDFs land.
PDF_DIR=./pdfs

# HTTP tuning
HTTP_TIMEOUT=30
HTTP_MAX_RETRIES=3
PDF_MAX_BYTES=104857600   # 100 MB

# Logging
LOG_LEVEL=INFO

If CONTACT_EMAIL is unset, a neutral placeholder is used — the server still works, just with potentially stricter rate limits.

Privacy

Your email is sent only in mailto= query params / User-Agent headers to OpenAlex, CrossRef, and Unpaywall — never to any other party. It is not logged at INFO level (only a masked form, e.g. you***@x.com). Set POLITE_POOL=0 to withhold it entirely.
Search queries and DOIs are sent to those three APIs as part of normal operation. Stderr logs may include them at WARNING level on errors. The stderr stream is captured by your MCP client into a local log file.
Downloaded PDFs persist on disk under PDF_DIR and reveal your research interests. The directory is git-ignored.

Connect your MCP client

The server is a standard stdio MCP server. Add it to your client's config, replacing /path/to/OpenPapers with your checkout path.

Claude Desktop

~/Library/Application Support/Claude/claude_desktop_config.json (macOS):

{
  "mcpServers": {
    "openpapers": {
      "command": "uv",
      "args": ["run", "--directory", "/path/to/OpenPapers", "openpapers"]
    }
  }
}

ZCode

~/.zcode/config.toml (or workspace .zcode/config.toml):

[[mcp_servers]]
name = "openpapers"
transport = "stdio"

[mcp_servers.stdio]
command = "uv"
args = ["run", "--directory", "/path/to/OpenPapers", "openpapers"]

Cursor

.cursor/mcp.json:

{
  "mcpServers": {
    "openpapers": {
      "command": "uv",
      "args": ["run", "--directory", "/path/to/OpenPapers", "openpapers"]
    }
  }
}

After editing, restart the client. The five openpapers tools should appear.

Development

# Tests (offline — uses respx mocks, no network needed)
uv run pytest

# Lint & format
uv run ruff check .
uv run ruff format --check .

# Type check
uv run mypy

# Optional: live smoke test against the real APIs
OPENPAPERS_LIVE=1 uv run pytest -m live

See CONTRIBUTING.md for the full developer guide, including the offline-tests-only convention.

Project layout

src/openpapers/
├── __main__.py        # entry point: `uv run openpapers`
├── server.py          # FastMCP + 5 tool registrations
├── config.py          # .env loading, paths, constants, version source-of-truth
├── http_client.py     # httpx client w/ retry, polite headers, safe download
├── security.py        # SSRF & path-traversal guards
├── models.py          # Pydantic models (public tool contract)
└── services/
    ├── openalex.py    # search, get_by_doi, abstract reconstruction
    ├── crossref.py    # DOI metadata, references, funders, publisher
    ├── unpaywall.py   # OA lookup
    ├── downloader.py  # PDF download with atomic writes & magic-byte check
    └── util.py        # DOI normalization, abstract rebuild, name parsing
tests/                 # 69 offline tests via respx + 3 live smoke tests

Design notes

Polite by default. mailto/User-Agent headers are set on every request, with a POLITE_POOL=0 escape hatch for privacy mode.
Abstract reconstruction. OpenAlex stores abstracts as {word: [positions]} to avoid redistributing full text; the original is rebuilt losslessly.
PDF safety. Content-type must be application/pdf and bytes must start with %PDF-. URLs are validated for scheme and resolved host (loopback, RFC1918, link-local 169.254/16, CGNAT, ULA all refused). Filenames are sanitized and paths must stay inside PDF_DIR. Downloads write to <name>.pdf.part and rename atomically on success.
DOI normalization. Accepts bare DOIs, doi:..., https://doi.org/..., or DOIs embedded in surrounding text. The regex excludes URL-significant chars (?#&[]) to prevent API-URL injection.
CrossRef enrichment is best-effort. If CrossRef is down or has no record, get_paper still returns the OpenAlex record with empty references.
Single source of truth for version. __version__ lives in config.py; pyproject.toml mirrors it.

Limitations & alternatives

No paywalled full text. If a paper isn't OA, you'll get metadata + abstract but no PDF. For paywalled content, use your institution's VPN / library proxy, or an EBSCO Discovery Service integration (requires license).
Abstract coverage. OpenAlex has abstracts for most recent papers, but older works (pre-~2000, some publishers) may have abstract: null.
Rate limits. The three APIs are generous but not unlimited. On 429/5xx the server retries with exponential backoff, honoring Retry-After (both seconds and HTTP-date forms). For bulk work, throttle your calls or self-host OpenAlex snapshots.

Data licensing & attribution

This server is a thin client over three upstream APIs. Each has its own terms:

OpenAlex — metadata is CC0; they request attribution. See openalex.org.
CrossRef — metadata is CC0; the REST API has terms of use.
Unpaywall — see their terms.

PDFs you download come from the publishers/repositories that Unpaywall identifies; each has its own license (CC-BY, paywalled-but-OA-copy, etc.). Respect the individual paper's license.

Getting help

🐛 Bugs & feature requests: open an issue
🔒 Security issues: see SECURITY.md — do not open a public issue
💬 Discussion: GitHub Discussions (if enabled) or the issue tracker

License

MIT © Philipp Polte. See CONTRIBUTING.md for the contribution agreement and CODE_OF_CONDUCT.md for community standards.

Available Tools

5 tools

download_pdfA

Download a PDF to the local PDF directory. Use find_oa_pdf first to obtain a URL. The URL is validated for SSRF safety (private/loopback/metadata IPs are refused) and the bytes are verified to start with the %PDF- magic marker. Downloads are capped at PDF_MAX_BYTES (default 100 MB) and written atomically — a failed download never leaves a partial file at the final path.

ParametersJSON Schema

Name	Required	Description
`doi`	No	DOI used to derive the filename (optional).
`url`	Yes	Direct PDF URL (typically best_oa_location.url_for_pdf from find_oa_pdf).
`filename`	No	Explicit filename override (sanitized; will be .pdf-suffixed).

Output Schema

ParametersJSON Schema

Name	Required	Description
`doi`	No
`url`	Yes
`local_path`	Yes
`content_type`	No
`bytes_written`	Yes

TDQS

A4.4/5.0

Behavior5/5

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

With no annotations provided, the description carries the full behavioral burden and does so excellently. It discloses SSRF safety validation, PDF magic-marker verification, a 100 MB size cap, and atomic writes that prevent partial files. This goes well beyond typical descriptions and addresses security and reliability concerns.

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 two sentences, front-loaded with the primary purpose, and then efficiently packs usage guidance and safety details. Every sentence earns its place, with no filler or redundancy.

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?

The description covers purpose, prerequisite, safety, size limits, and failure behavior. The existence of an output schema means return values need no description. A slight gap is that it doesn't mention error handling for non-PDF content beyond the magic-marker check, but the given details are otherwise comprehensive for this tool's complexity.

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

Parameters3/5

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

Schema description coverage is 100%, and the schema already explains each parameter (url, doi, filename) with useful context. The description adds no new parameter-level semantics; it only reinforces that the URL should come from find_oa_pdf. Per calibration, a baseline of 3 is appropriate when the schema covers parameters well.

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 clearly states the tool's function: 'Download a PDF to the local PDF directory.' This is a specific verb+resource+location combination. It also implicitly differentiates from siblings like find_oa_pdf by focusing on the download step, and explicitly references the typical prerequisite workflow.

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 provides explicit workflow guidance by instructing 'Use find_oa_pdf first to obtain a URL.' This tells the agent when to use this tool in sequence with a sibling. It lacks an explicit 'when not to use' clause, but the context is clear enough for a download tool.

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

find_oa_pdfA

Find a legal Open Access PDF for a DOI via Unpaywall. Returns the OA status, the best OA location (with direct PDF URL if available), and a list of all OA locations (repository vs publisher, version, license).

ParametersJSON Schema

Name	Required	Description	Default
`doi`	Yes	DOI of the paper (bare, URL, or 'doi:' prefix accepted).

Output Schema

ParametersJSON Schema

Name	Required	Description
`doi`	No
`genre`	No
`is_oa`	Yes
`pdf_url`	No
`oa_status`	No
`journal_name`	No
`oa_locations`	No
`journal_is_oa`	No
`best_oa_location`	No
`journal_is_in_doaj`	No

TDQS

A4/5.0

Behavior3/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 return values (OA status, best location, list of locations) and the data source, but does not mention read-only behavior, failure handling, or authorization requirements. This is adequate but not thorough.

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 two sentences, front-loaded with the main purpose, and every word adds value. 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.

Completeness4/5

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

Given the simple single-parameter signature and the presence of an output schema, the description provides a complete account of the tool's function and return structure. It lacks explicit usage guidance relative to siblings, but that is not critical for this simple tool.

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

Parameters3/5

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

The schema provides 100% coverage for the 'doi' parameter, including acceptable formats. The description adds no extra parameter-specific meaning beyond the schema, so the baseline score of 3 applies.

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 clearly states the tool's function: find a legal Open Access PDF for a given DOI via Unpaywall. It uses a specific verb and resource, and the distinction from sibling tools like search_papers and download_pdf is clear.

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 the tool is used when you have a DOI and need a legal Open Access PDF. It does not explicitly mention alternatives or exclusions, but the context is clear enough for an agent to decide when to invoke it.

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

get_paperA

Fetch full metadata for a single paper by DOI, including the abstract (reconstructed from OpenAlex), authors with ORCID/affiliations, concepts, and references (enriched from CrossRef).

ParametersJSON Schema

Name	Required	Description	Default
`doi`	Yes	DOI as bare string ('10.1038/nature12373'), URL form, or 'doi:...' — all accepted.

Output Schema

ParametersJSON Schema

Name	Required	Description
`doi`	No
`is_oa`	No
`title`	Yes
`venue`	No
`authors`	No
`funders`	No
`license`	No
`pdf_url`	No
`abstract`	No
`concepts`	No
`keywords`	No
`language`	No
`oa_status`	No
`publisher`	No
`references`	No
`venue_type`	No
`openalex_id`	No
`cited_by_count`	No
`landing_page_url`	No
`publication_date`	No
`publication_year`	No
`references_count`	No

TDQS

A4.2/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 transparency burden. It discloses non-obvious behaviors: the abstract is 'reconstructed from OpenAlex' and references are 'enriched from CrossRef.' It does not mention error handling or rate limits, but the provenance details add meaningful context.

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 a single, front-loaded sentence with no wasted words. It efficiently conveys the action, scope, and included metadata fields while keeping provenance details concise.

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?

Given the tool's simplicity (one parameter) and the presence of an output schema, the description covers the essential context: what it fetches and by which identifier. It does not explicitly expand on usage relative to siblings, but the sibling names and the 'single paper by DOI' scope provide sufficient context.

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

Parameters3/5

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

The input schema fully documents the doi parameter with examples and accepted formats (bare string, URL, or prefixed). The description adds no extra parameter semantics beyond restating 'by DOI,' and with 100% schema coverage the baseline score of 3 is appropriate.

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 clearly states the tool fetches full metadata for a single paper by DOI, listing specific content areas (abstract, authors, concepts, references). It distinguishes itself from sibling tools like search_papers and download_pdf by specifying 'single paper' and 'by DOI'.

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 use when you have a DOI and want full metadata, and the sibling tool list makes the alternative contexts obvious. However, it does not explicitly name alternatives or provide when-not-to-use guidance, so it falls short of a 5.

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

research_topicA

Convenience workflow: search OpenAlex for query, then for each top result fetch OA status (Unpaywall). Returns a compact overview suitable for quickly assessing a research area. Abstracts are taken from the search response itself — no extra OpenAlex calls.

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes	Research topic or free-text query.
`max_results`	No	Number of top results to enrich (1..10).

Output Schema

ParametersJSON Schema

Name	Required	Description
`query`	Yes
`papers`	No
`total_results`	Yes
`oa_available_count`	No

TDQS

A4.2/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 of behavioral disclosure. It explains the workflow steps (search, then OA status lookup), the data source (Unpaywall), and a key optimization: 'Abstracts are taken from the search response itself — no extra OpenAlex calls.' This adds valuable behavioral context, though it doesn't address error handling or what happens if Unpaywall fails.

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 two sentences, front-loaded with the core workflow. Every word earns its place, with no redundant phrasing.

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?

Given the tool's moderate complexity (2 params, output schema present), the description adequately covers the workflow, the data source, and the intended output. The existence of an output schema removes the need to describe return values. It could mention limitations, but the schema already handles constraints, making this sufficient.

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

Parameters3/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 references the 'query' parameter in the first sentence, clarifying its role, but does not add details beyond the schema's own parameter descriptions. No additional semantics are needed.

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 clearly states its purpose as a 'Convenience workflow' that searches OpenAlex, enriches results with OA status from Unpaywall, and returns a compact overview. This is a specific verb+resource combination that differentiates it from siblings like search_papers (search only) and find_oa_pdf (find PDFs).

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 provides clear usage context, calling it a 'Convenience workflow' 'suitable for quickly assessing a research area.' This implies when to use it but does not explicitly name alternatives or exclusions. Since sibling tools are listed, the context is clear enough for an agent to infer the intended use case.

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

search_papersA

Search academic papers by relevance via OpenAlex. Returns a compact list with DOI, title, authors, year, venue, citation count, OA status, and top concepts. Use year_from/year_to to constrain the publication year.

ParametersJSON Schema

Name	Required	Description
`query`	Yes	Free-text search query, e.g. 'transformer attention mechanism'.
`year_to`	No	Inclusive upper publication year bound.
`year_from`	No	Inclusive lower publication year bound.
`num_results`	No	Max number of results (1..50).

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4/5.0

Behavior4/5

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

With no annotations provided, the description takes on the burden of explaining behavior. It discloses that the tool 'Returns a compact list' with specific fields (DOI, title, authors, year, venue, citation count, OA status, top concepts), and mentions relevance-based search. This goes beyond a mere definition, though it omits details like rate limits or authentication requirements.

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 two sentences long, front-loaded with the main purpose, and contains no redundant or filler content. Every sentence provides distinct value: purpose, return contents, and a filtering hint.

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?

Given the tool's moderate complexity (4 parameters) and the presence of an output schema, the description supplies key information about search behavior and return fields. It lacks explicit usage guidance for when to use this tool over siblings, but overall covers the essential context well.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents all parameters. The description adds a minor clarification for year_from/year_to ('constrain the publication year'), but this does not significantly exceed the schema's existing descriptions. Baseline 3 is appropriate.

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 starts with 'Search academic papers by relevance via OpenAlex', which clearly identifies the verb (search), resource (academic papers), and scope (relevance, OpenAlex). This distinguishes it from sibling tools like get_paper (specific paper retrieval), find_oa_pdf, and download_pdf, which have different purposes.

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 implies usage for searching academic papers by relevance, and gives a parameter hint ('Use year_from/year_to to constrain the publication year'), but does not explicitly state when to choose this tool over siblings or provide exclusions. The guidance is implied rather than explicit.

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

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.4/5.0

Disambiguation5/5

Each tool serves a distinct function: searching, fetching metadata, locating OA PDFs, downloading, and a convenience workflow. Even though research_topic wraps search and OA status, its composite nature is clearly documented, leaving no ambiguity.

Naming Consistency5/5

Tool names follow a consistent verb_noun pattern in snake_case: search_papers, get_paper, find_oa_pdf, download_pdf, research_topic. The verbs are all distinct and aptly describe the action, making the set predictable and easy to navigate.

Tool Count5/5

Five tools is a well-scoped count for a paper retrieval server. Each tool earns its place, covering the essential discovery-to-download pipeline without unnecessary bloat or omissions.

Completeness5/5

The surface covers the full lifecycle for the domain: search, detailed metadata retrieval, OA PDF location, and local download. The research_topic workflow adds a convenient aggregation layer. No obvious dead ends or critical missing operations for the stated purpose.

Maintenance

ActivitySlowing

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

PapersFlow
io.github.papersflow-ai
Academic research MCP server for paper search, citation checks, graphs, and deep research.
Research & Data Search Documentation Access
214
altmetric-mcp
com.altmetric.mcp
MCP server for Altmetric APIs - track research attention across news, policy, social media, and more
Research & Data Social Media
27
Mirror Memory MCP Server
io.github.Tr1ckyMag1ca1
Personal knowledge base MCP server with semantic search, auto-categorization, metadata extraction
Knowledge & Memory Search Note Taking
2
Biolab MCP Server
io.github.srikarjy
Auditable MCP server for PubMed, Europe PMC, ClinicalTrials.gov, and bioRxiv/medRxiv queries
Biology & Medicine Search Open Data
11

Related MCP Servers

Crossref Academic MCP Server
Research & Data Search Open Data
AiAgentKarl
A
license
A
quality
D
maintenance
MCP server enabling AI agents to search and retrieve scientific papers, citations, and author profiles from Crossref, OpenAlex, and Semantic Scholar with no API keys required.
Updated 5 months ago (2026-03-20 11:46 UTC)
5
3
MIT
rag-paper
RAG Systems Research & Data
i1ight
A
license
Not graded
quality
A
maintenance
A local-first paper RAG server that enables searching and managing academic PDFs via MCP tools, supporting metadata enrichment and citation graphs.
Updated 25 days ago (2026-08-09 15:11 UTC)
1
MIT
research-mcp
Research & Data Search
niol-zh
A
license
A
quality
A
maintenance
An MCP server for academic literature research that integrates Scopus, CrossRef, OpenAlex, and Unpaywall to search documents, get abstracts, author profiles, citing papers, and open-access PDF links.
Updated a month ago (2026-07-29 10:51 UTC)
6
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 a month ago (2026-07-31 00:25 UTC)
2
11
1
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Kaago/openpapers-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server