Skip to main content
Glama
iwinoid

eutils-mcp-server

by iwinoid
OverviewSchemaSourceRelated ServersScoreDiscussionsAdmin
TypeScript
Remote

Link and Fetch Across Databases

eutils_link_then_fetch
Read-onlyIdempotent

Follow links across Entrez databases and download target records in one call, such as gene IDs to protein sequences or PMIDs to PMC full text.

Instructions

Follow links from one database to another and download the target records in one call.

Typical uses: gene IDs to protein sequences, PMIDs to PMC full text, nucleotide records to SNPs. Give it either a query or a UID list in the source database, and it returns records from the target database.

Args:

  • dbfrom (string): source database, for example "gene".

  • db (string): target database to download from, for example "protein".

  • term (string, optional): query in dbfrom. Pass exactly one of term or uids.

  • uids (string[] | string, optional): source UIDs in dbfrom.

  • linkname (string, optional): specific link to follow.

  • retmax (number, optional): target records to download. Default 20, max 500.

  • rettype (string, optional): record format for the target database.

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

Returns: { dbfrom, dbto, source_total, retrieved, rettype, source_history, history, text }

Examples:

  • Use when: "get the protein sequences for these gene IDs" -> dbfrom="gene", db="protein", uids=[...]

  • Use when: "find PMC full text for papers about X" -> dbfrom="pubmed", db="pmc", term="..."

  • Don't use when: you only need the linked UIDs (use eutils_elink, which is cheaper)

Error Handling:

  • Rejects passing both term and uids, or neither

  • Returns an empty result with a hint to list link names when no links exist

  • Refuses retmax above 500

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dbYesTarget database to download from, for example "protein".
termNoQuery in dbfrom. Use instead of uids to select the source records.
uidsNoSource UIDs in dbfrom. Use instead of term.
dbfromYesSource database, for example "gene".
retmaxNoRecords to download from the target database (default 20, max 500).
rettypeNoRecord format for the target database.
linknameNoSpecific link to follow. Use eutils_einfo to list valid names.
response_formatNoOutput format: 'markdown' for human-readable text, or 'json' for machine-readable data. Default: 'markdown'.markdown

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
dbtoYes
textYes
dbfromYes
historyNo
rettypeNo
retrievedNo
source_totalYes
source_historyNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered. The description adds real behavioral detail beyond that: mutual exclusivity of term/uids, retmax capped at 500 with default 20, and graceful empty-result hinting when no links exist. This is richer than typical but stops short of describing pagination or auth needs.

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?

It is well front-loaded (purpose, then uses, args, returns, examples, errors) and every section is scannable. The Args block largely restates the 100%-covered schema, which is mild redundancy, but the examples and error-handling sections earn their space.

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 an 8-parameter cross-database tool, the description covers selection of source/target, the term-vs-uids rule, format control, and failure modes, and an output schema exists so return values need not be re-explained. Nothing material is missing 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?

Schema coverage is 100%, so the baseline is 3. The description nevertheless adds meaning the schema does not encode, notably the 'Pass exactly one of term or uids' constraint and the retmax default/ceiling framing, which helps an agent construct a valid call rather than just read field docs.

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 names a specific compound action (follow links across databases and download target records in one call) and gives concrete examples (gene IDs to protein sequences, PMIDs to PMC full text). It is clearly distinguishable from eutils_elink and eutils_search_then_fetch because the 'link then fetch' scope is stated explicitly.

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?

It provides explicit 'Use when' examples and a 'Don't use when: you only need the linked UIDs (use eutils_elink, which is cheaper)' exclusion naming the alternative tool. The agent can route between this tool and eutils_elink without inference.

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

Install Server

Other Tools