Summary

The stored-search layer is what separates this from a plain PubMed wrapper: a result set is addressable by search_id and paged later, rather than re-queried.

That matters over a long session — retrieve_pubmed_results takes `page` and results_per_page against a stored search_id, and list_pubmed_searches shows what is on hand, so a large result set never has to come back into context at once. Full text is a separate route from abstracts: search_pubmed and get_full_abstract work on PubMed records, while search_pmc_fulltext goes to PubMed Central's open-access set. That get_abstract_help exists at all, purely to explain get_full_abstract, suggests the PMID-to-abstract step is where callers get stuck.

What it is

A PubMed and PubMed Central search server that keeps its result sets: a search is stored under a search_id and paged back later instead of being re-run.

What you get

Abstracts that arrive whole: search_pubmed retrieves complete abstracts with its results, and get_full_abstract returns the entire abstract for a single pmid.
Open-access full text as its own search: search_pmc_fulltext queries PubMed Central for full-text open-access articles under its own max_results.
Result sets you can come back to: retrieve_pubmed_results pages a stored search by search_id with `page` and results_per_page, and list_pubmed_searches returns the stored PubMed and PMC searches.
Usage guidance in-band: get_abstract_help returns help and examples for get_full_abstract.

Requirements

No credentials are configured. Paging a result set back needs the search_id of the run that produced it, which list_pubmed_searches returns.

Setup effort

One command — npx -y enhanced-pubmed-mcp-server

Enhanced PubMed Search