eutils-mcp-server

Overview Schema Source Related Servers Score Discussions Admin

Upload UIDs to Entrez History

eutils_epost

Read-only

Upload UIDs to NCBI's History server to get a reusable handle. Use the handle to combine sets or process IDs from outside ESearch.

Instructions

Upload a list of UIDs to the NCBI History server and get a reusable handle.

Use this when you already have UIDs from somewhere other than an ESearch, or when you want to combine several sets. Many thousands of UIDs fit in one call.

Args:

db (string): database the UIDs belong to, for example "gene".
uids (string[] | string): UIDs or accessions, as an array or comma-separated string.
response_format ('markdown' | 'json'): output format. Default 'markdown'.

Returns: { database, uploaded, history: { db, web_env, query_key } }

Examples:

Use when: "fetch these five gene IDs" -> db="gene", uids=["7173","22018","54314"]
Use when: combining UID lists from two sources before one download
Don't use when: you are about to search; ESearch with usehistory already posts its own results

Error Handling:

Rejects UIDs containing URL metacharacters
Reports an upstream error if NCBI returns no History handle

Input Schema

TableJSON Schema

Name	Required	Description	Default
`db`	Yes	Entrez database the UIDs belong to, for example "pubmed".
`uids`	Yes	UIDs or accessions to upload, as an array or a comma-separated string.
`response_format`	No	Output format: 'markdown' for human-readable text, or 'json' for machine-readable data. Default: 'markdown'.	markdown

Output Schema

TableJSON Schema

Name	Required	Description	Default
`history`	Yes
`database`	Yes
`uploaded`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Sep 11, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Beyond the annotations (readOnlyHint/destructiveHint/idempotentHint), it discloses capacity (many thousands of UIDs per call), the validation rule (UIDs with URL metacharacters are rejected), and failure mode (upstream error if NCBI returns no History handle). This explains why idempotentHint is false: each call yields a fresh handle.

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?

Well structured and front-loaded: purpose first, then Args/Returns/Examples/Error Handling. The Args section largely restates the schema descriptions, which is mild redundancy, but no sentence is wasted elsewhere.

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 a 3-parameter tool with an output schema and full annotation coverage, the description supplies everything an agent needs: purpose, routing advice, parameter shapes, return shape, and error behavior.

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, but the description adds worked examples with real values (db="gene", uids=["7173","22018","54314"]) and restates the array-or-comma-separated flexibility of uids, which helps an agent choose a form quickly.

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+outcome: upload UIDs to the NCBI History server and receive a reusable handle. It distinguishes itself from the search-oriented siblings by explaining that this is the entry point when UIDs come from somewhere other than ESearch.

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?

Explicitly names when to use it (UIDs from another source, combining sets), when not to use it (you are about to search; ESearch with usehistory already posts its own results), and gives concrete examples. The alternative is named and the selecting condition is stated.

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

Install Server