Search arXiv preprints, supporting fielded queries and returning metadata such as title, authors, and links.
Search PubMed scholarly literature, supporting fielded queries and returning publication metadata.
Search Semantic Scholar for academic papers, returning metadata and summaries.
Click on "Install 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., "@literature-search-mcp Search for open-access papers on climate change adaptation"
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.
A standalone Node.js 22 TypeScript MCP server that searches seven scholarly metadata providers over stdio, normalizes records, deduplicates them, and applies deterministic reciprocal-rank fusion.
For ZIP packaging, recipient installation, Claude Code registration, permissions, updates, troubleshooting, and uninstallation, see the Chinese guide: INSTALL_ZH.md.
The server registers exactly three tools:
literature_search — search selected providers or all providers by default.
literature_sources — list supported providers, limitations, and whether optional environment variables are configured.
literature_get_fulltext — fetch open-access full text from Europe PMC (PMC Open Access subset) for a paper identified by pmcid, pmid, or doi, returning title, abstract, structured sections, a joined plain-text full_text, and metadata.
literature_search accepts:
Input | Type | Default | Notes |
| string | required | Search expression. Rich syntax (fielded, wildcard, Boolean) is passed through to providers that support it natively (PubMed |
| integer 1–50 |
| Maximum fused results returned. |
| source ID array | all seven |
|
| integer | unset | Inclusive lower publication year. |
| integer | unset | Inclusive upper publication year. |
| boolean | unset | Require positive open-access or PDF evidence. |
| integer 1–3000 |
| Maximum characters returned for each provider-supplied abstract or summary. |
Results include title, cleaned provider-supplied abstracts or summaries capped at abstract_max_chars, normalized identifiers, canonical/PDF URLs, year, authors and venue when available, reciprocal-rank score, source evidence, and per-source statuses. literature_search never downloads full text, fetches citation graphs, or retrieves references/citations. Open-access full text is available through the separate literature_get_fulltext tool (Europe PMC OA subset only; input pmcid/pmid/doi; output title, abstract, structured sections, and a joined plain-text full_text capped by max_chars).
literature_get_fulltext accepts:
Input | Type | Default | Notes |
| string | unset | PubMed Central identifier (e.g. |
| string | unset | PubMed identifier; resolved to a PMCID via Europe PMC search. |
| string | unset | DOI; resolved to a PMCID via Europe PMC search. |
| integer 1000–1000000 |
| Maximum characters in the joined |
Papers without open-access full text in Europe PMC return a structured status: "not_found" with empty content; transport or server failures return status: "error" with a sanitized error detail. Full text is never persisted to search history.
Related MCP server: scholar-toolkit-mcp
Node.js 22 or newer is required. Dependencies are pinned in package-lock.json.
npm run typecheck
npm test
npm run build
npm startThe build emits dist/server.js and dist/cli.js. npm start runs the stdio server; stdout is reserved for MCP protocol messages and operational logging goes to stderr.
An MCP client can launch the built server with a command equivalent to:
{
"command": "node",
"args": ["/absolute/path/to/literature-search-mcp/dist/server.js"]
}This project does not modify or register MCP client configuration itself.
The server starts and searches without credentials. Optional environment variables improve provider etiquette or rate limits:
OPENALEX_MAILTO
OPENALEX_API_KEY
SEMANTIC_SCHOLAR_API_KEY
CROSSREF_MAILTO
NCBI_TOOL
NCBI_EMAIL
NCBI_API_KEYNo Synthetic Sciences contact address is used as a fallback. PubMed always sends a tool name (literature-search-mcp unless NCBI_TOOL is set); email parameters are sent only when explicitly configured.
See PROVIDERS.md for API-specific behavior and limitations.
Providers are always processed in this fixed order:
PubMed
Europe PMC
bioRxiv/medRxiv
Crossref
OpenAlex
Semantic Scholar
arXiv
Deduplication checks normalized DOI, PMID, versionless arXiv ID, then normalized title. Records with conflicting values for the same strong identifier type are never merged. Ranking uses reciprocal-rank fusion with a fixed constant (k = 60), followed by stable source/rank/title tie-breakers; provider-native scores do not affect ordering.
All provider traffic uses Node's native fetch with:
30-second per-attempt timeout;
three retries after the initial attempt for HTTP 408, 429, 5xx, network failures, and internal timeouts;
numeric and HTTP-date Retry-After support;
exponential backoff;
caller cancellation propagation;
per-host request pacing and concurrency controls;
a maximum five-minute, 256-entry in-memory GET cache;
typed, sanitized errors that omit query strings and response bodies.
Each completed search appends one JSON object to:
${XDG_STATE_HOME:-~/.local/state}/literature-search-mcp/history.jsonlHistory records query parameters, source statuses, result identifiers, ranks, evidence, and URLs. It does not store abstracts, authors, provider credentials, or secrets.
Clear history with the compiled CLI:
node dist/cli.js clear-history
# or
npm run history:clearnpm test is offline and uses node:test, fixtures, fake fetch implementations, and an in-memory MCP transport. It covers HTTP behavior, every provider parser, aggregation/deduplication, history, the search service, and exact MCP tool registration.
The live smoke test is opt-in:
npm run test:liveIt performs a small Crossref query and is not part of the offline suite.
Apache License 2.0. See LICENSE and NOTICE. This project adapts concepts from OpenScience literature connectors but does not import the OpenScience runtime.
Fetch open-access full text from Europe PMC (PMC Open Access subset) for a paper identified by at least one of pmcid, pmid, or doi. Returns title, abstract, structured sections, a joined plain-text full_text, and metadata (identifiers, source, url, license, word/character counts, truncated flag). Papers without open-access full text return a structured status of "not_found".
| Name | Required | Description | Default |
|---|---|---|---|
| doi | No | Digital Object Identifier | |
| pmid | No | PubMed identifier | |
| pmcid | No | PubMed Central identifier, e.g. PMC1234567 | |
| max_chars | No | Maximum characters in the joined full_text string; sections and abstract are returned in full |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and non-destructive behavior. The description adds valuable context: the exact return fields (title, abstract, full_text, metadata), the truncated flag, and the not_found status for papers without open access. This goes beyond the 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?
The description is two sentences, front-loaded with the primary purpose, and includes return details without redundancy. Every sentence earns its place.
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 no output schema, the description sufficiently explains return values and the not_found case. It covers the main behavioral aspects needed for invocation, though it could mention error handling for invalid/missing identifiers.
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 covers all parameters with descriptions (100% coverage), so baseline is 3. The description adds meaning by explaining that at least one of the three IDs is required and by mentioning the truncated flag, which relates to max_chars. This enriches parameter understanding.
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 states the specific action (fetch full text from Europe PMC) and resource (open-access subset), and distinguishes it from sibling tools like literature_search (search) and literature_sources (sources). It clearly identifies the expected identifier inputs.
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 provides clear context for when to use the tool (when you have at least one of pmcid, pmid, or doi) but does not explicitly mention alternatives or when not to use it. The condition is clear enough for an agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search PubMed, Europe PMC, bioRxiv/medRxiv, Crossref, OpenAlex, Semantic Scholar, and arXiv. Sources fan out in parallel by default; results are normalized, deduplicated, and fused deterministically. Returns provider-supplied metadata abstracts or summaries capped at 3,000 characters by default, never full text or citation graphs.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum fused results to return | |
| query | Yes | Literature query | |
| sources | No | Optional source subset; default is all sources | |
| year_to | No | ||
| year_from | No | ||
| open_access | No | When true, retain results with positive open-access or PDF evidence | |
| abstract_max_chars | No | Maximum characters returned for each abstract or summary |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable behavioral context beyond annotations: sources fan out in parallel, results are normalized/deduplicated/fused deterministically, and abstracts are capped at 3,000 characters. It also clarifies it never returns full text or citation graphs. No contradiction with annotations is present.
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 with front-loaded action and no filler. Each sentence adds distinct information: sources covered, processing behavior, and return limitations. Efficient and well-structured.
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 tool's complexity (multi-source search) and lack of output schema, the description covers the essential behavior: what sources, how results are fused, and output constraints. It does not mention pagination or error handling, but for a search tool this is reasonably complete. Could add a bit more on result structure but not required.
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 description coverage is 71%, so most parameters already have descriptions. The description adds that the abstract cap defaults to 3,000 characters (already in schema) and explains source behavior, but does not add meaning for year_from/year_to or query syntax. It provides marginal value beyond what the schema already documents.
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 searches across seven named scholarly databases with specific actions like parallel fan-out and deterministic fusion. It does not explicitly distinguish from sibling tools literature_sources and literature_get_fulltext, but the verb 'search' plus the source list makes the purpose unambiguous.
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?
Usage context is implied: use this tool to search literature. No explicit guidance on when to use this versus literature_sources or literature_get_fulltext, nor any exclusions or prerequisites. The description does not mention that literature_get_fulltext should be used for full text, though the 'never full text' hint indirectly suggests it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the seven supported literature sources, optional credential environment variables, and provider limitations.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, so the read-only nature is covered. The description adds useful context beyond that: the exact count (seven), inclusion of credential environment variables, and provider limitations. It doesn't describe output structure, but for a simple read-only tool this is sufficient credit.
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 a single, compact sentence that clearly enumerates the three items the tool lists. No wasted words or redundancy.
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 tool's simplicity (no parameters, no output schema, read-only), the description is complete: it tells exactly what will be listed (seven sources, credential env vars, provider limitations). An agent can invoke and interpret the result without further context.
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?
The tool has zero parameters, so schema coverage is trivially 100%. With no parameters, the description doesn't need to explain parameter meanings; baseline is 4.
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 a specific action ('List') and resource ('the seven supported literature sources'), and goes further by mentioning credential environment variables and provider limitations. This distinguishes it from sibling tools that search or fetch fulltext.
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 implies usage (e.g., to see available sources before searching) but does not explicitly state when to use this versus siblings. It mentions credential env vars and limitations, which hints at configuration setup, but no explicit when-to-use or when-not-to-use guidance is given.
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. Dates show when Glama detected each change.
v1.2.1literature_get_fulltextliterature_searchliterature_sourcesEach tool serves a clearly distinct purpose: searching across sources, listing sources, and fetching full text. No functional overlap exists between them.
Tools generally follow a verb_noun pattern with a shared 'literature_' prefix, but 'literature_sources' is a noun phrase rather than a verb action, creating a minor deviation from the otherwise consistent style.
Three tools is a well-scoped set for a literature search server, covering the essential operations without redundancy or bloat.
The set covers searching, source enumeration, and open-access full-text retrieval, but lacks a direct metadata lookup by identifier (e.g., PMID/DOI) when full text is unavailable, which is a minor gap.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
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)
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/PHoenixs57/literature-search-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
