Skip to main content
Glama

Global Entrez Query

eutils_egquery
Read-onlyIdempotent

Find which Entrez database holds records for a topic by querying all databases at once and returning match counts. Use it before running a targeted search.

Instructions

Search every Entrez database at once and report how many records each one matches.

Use this to find which database holds data for a topic before committing to a search. It returns counts only, never records.

Args:

  • term (string): Entrez text query, for example "CRISPR base editing".

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

Returns: { term, databases_searched, databases_with_hits, hits: [{ db, menu, count, status }] (sorted by count, descending), empty_databases: string[] }

Examples:

  • Use when: "which database has information about BRCA1 variants?" -> term="BRCA1 variants"

  • Don't use when: you already know the database (use eutils_esearch instead)

Error Handling:

  • Returns "The search term was empty" when term is blank

  • NCBI EGQuery redirects to an internal host that is not published in public DNS, for every client including ones with a valid API key. When the real EGQuery is unreachable this tool falls back to per-database ESearch counts over 12 commonly used databases, and says so in a "degraded" field. Counts are then a subset, not all 38.

  • The fallback triggers only on a network failure, never on a validation error.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
termYesEntrez text query to run against every database at once.
response_formatNoOutput format: 'markdown' for human-readable text, or 'json' for machine-readable data. Default: 'markdown'.markdown

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
hitsYes
termYes
degradedNoTrue when the fallback produced this result.
degraded_reasonNo
empty_databasesYes
databases_searchedYes
databases_with_hitsYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already establish read-only, idempotent, open-world safety, and the description adds materially more: counts-only output, a degraded-mode fallback limited to 12 of 38 databases, the DNS/redirect cause, the exact fallback trigger condition (network failure, never validation error), and the blank-term error string. This is unusually rich disclosure for a read tool with full annotation coverage.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the one-line purpose, then cleanly sectioned into Args, Returns, Examples, and Error Handling. Despite its length, every section carries non-redundant operational information, particularly the degraded-mode caveat.

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?

Even though an output schema exists, the description spells out the full return shape including the degraded field, sorting order, and empty_databases, plus failure modes. Nothing an agent needs to interpret a result or handle a fallback is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so both parameters are already documented, and the description largely restates them. The example query 'CRISPR base editing' adds a small amount of concreteness about term format, but no syntax, limits, or field-qualifier guidance beyond the schema.

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 and resource ('Search every Entrez database at once') plus the exact output contract ('report how many records each one matches'). The 'Don't use when' line explicitly separates it from eutils_esearch, so an agent can route without opening either schema.

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 both a positive trigger ('find which database holds data for a topic before committing to a search') and an explicit exclusion with the named alternative ('you already know the database (use eutils_esearch instead)'). The worked example ('which database has information about BRCA1 variants?') makes the intent unambiguous.

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