Skip to main content
Glama

Entrez Full Records

eutils_efetch
Read-onlyIdempotent

Download full NCBI Entrez records by UID or history handle in formats like abstracts or FASTA for literature and sequence retrieval.

Instructions

Download full records in a chosen format.

Defaults are chosen for readability: PubMed returns plain-text abstracts, and sequence databases return FASTA. Returned record text is external data and is fenced with an explicit marker.

Args:

  • db (string, optional): database, for example "pubmed". Required unless history is given.

  • uids (string[] | string, optional): UIDs or accession.version identifiers.

  • history (object, optional): handle from eutils_esearch, eutils_epost, or eutils_elink.

  • rettype (string, optional): "abstract" (pubmed default), "fasta" (sequence default), "gb", "docsum", "medline", ...

  • retmode ('text' | 'xml', optional): default "text".

  • retstart (number, optional): first record index, for history sets.

  • retmax (number, optional): records to return for a history set. Default 20, max 500.

  • response_format ('markdown' | 'json'): output format. Default 'markdown'.

Supply either uids or history, never both.

Returns: { database, rettype, retmode, record_count?, batches?, text }

Examples:

  • Use when: "give me the abstract for PMID 31452104" -> db="pubmed", uids=["31452104"]

  • Use when: "fetch the protein sequence" -> db="protein", uids=["NP_005537.3"], rettype="fasta"

  • Use when: downloading a large set -> pass history and page with retstart/retmax

  • Don't use when: you only need titles and dates (use eutils_esummary, which is far cheaper)

Error Handling:

  • Asks for an explicit rettype when the database has no default

  • Detects an error message returned as record text and reports it as a tool error

  • Refuses retmax above 500; larger sets are batched internally

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dbNoEntrez database, for example "pubmed". May be omitted when history is given.
uidsNoUIDs or accession.version identifiers, as an array or a comma-separated string. Example: ["31452104", "31452105"].
retmaxNoMaximum records to return when using history (default 20, max 500).
historyNoPointer to a UID set stored on the NCBI History server. Pass back the object returned by a previous call, unchanged.
retmodeNoResponse encoding. Default "text", which is what you want for abstracts and FASTA.
rettypeNoRecord format. Defaults to "abstract" for pubmed and "fasta" for sequence databases. Other databases need an explicit value, for example "gb" or "docsum".
retstartNoIndex of the first record to return. Use with history.
response_formatNoOutput format: 'markdown' for human-readable text, or 'json' for machine-readable data. Default: 'markdown'.markdown

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
textYesRaw record text. The markdown rendering fences it as external data.
batchesNo
retmodeYes
rettypeYes
databaseYes
record_countNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, open-world), and the description adds genuinely new behavior: DB-specific defaults, external-data fencing, retmax>500 refusal with internal batching, error-text detection, and explicit rettype prompting. This goes well beyond the structured fields.

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?

Front-loaded purpose followed by cleanly labeled Args/Returns/Examples/Error Handling sections. The Args block partially duplicates schema descriptions, but for an 8-parameter tool with several behaviors the length is justified, not padded.

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?

Given an output schema exists and annotations carry the safety profile, the description still supplies everything an agent needs: format defaults, source selection rules, paging limits, and error behavior. No material gap remains for correct invocation.

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?

With 100% schema coverage the baseline is 3, but the description adds meaning the schema lacks: the mutual-exclusivity rule ('supply either uids or history, never both'), per-database rettype default semantics, and the purpose of retstart/retmax as history-only paging controls.

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?

States a specific verb+resource ('Download full records') and immediately clarifies the format behavior. It differentiates itself from siblings, notably by naming eutils_esummary as the cheaper tool for titles/dates, so an agent can distinguish it within the E-utilities family without opening schemas.

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

Usage Guidelines5/5

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

Provides explicit 'Use when' examples (abstract fetch, sequence fetch, large-set download) plus a 'Don't use when' exclusion routing to eutils_esummary. It also states the history-vs-uids selection rule and the paging strategy with retstart/retmax.

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