Skip to main content
Glama

ncbi_esearch

Search NCBI databases (Gene, PubMed, ClinVar, etc.) via E-utilities esearch API. Improve result completeness by using mandatory field tags in queries.

Instructions

Search NCBI databases using E-utilities esearch API.

⚠️ CRITICAL FOR COMPREHENSIVE RESULTS ⚠️ ALWAYS use NCBI field tags for Gene, ClinVar, and similar databases! Without field tags, you may miss 70-80% of relevant results.

MANDATORY FIELD TAGS FOR GENE DATABASE: • [Organism] - Taxonomic filtering (e.g., "Homo sapiens[Organism]", "Archaea[Organism]") • [Gene Name] - Gene symbols (e.g., "TP53[Gene Name]", "nifH[Gene Name]") • [All Fields] - Broad keyword search (e.g., "nitrogenase[All Fields]")

IMPACT OF FIELD TAGS (Gene Database): • Without field tags: ~300 results (20-30% recall) ❌ • With field tags: ~1,300 results (100% recall) ✅ • Performance loss: Missing field tags = 70-80% data loss!

Args: database: NCBI database name (alias: db). Supported values: - "gene" or "ncbigene": NCBI Gene database ⚠️ FIELD TAGS CRITICAL - "taxonomy": NCBI Taxonomy (organism information) - "clinvar": ClinVar (genetic variants) ⚠️ FIELD TAGS CRITICAL - "medgen": MedGen (medical genetics concepts) - "mesh": MeSH (Medical Subject Headings) - "pubmed": PubMed (biomedical literature) - "pccompound": PubChem Compound - "pcsubstance": PubChem Substance - "pcassay": PubChem BioAssay query: Search query with NCBI field tags and boolean operators (alias: term) max_results: Maximum number of results to return (default: 20) start_index: Starting index for pagination (default: 0) sort_by: Optional sort order (e.g., "relevance", "pub_date" for PubMed) search_field: Optional specific field to search in db: Alias for database. term: Alias for query.

Returns: Formatted search results with database-specific IDs

Examples - GENE DATABASE (CRITICAL): ✅ CORRECT (finds ~1,300 archaeal nifH genes, 100% recall): database="gene" query="Archaea[Organism] AND (nifH[Gene Name] OR nitrogenase[All Fields])"

❌ WRONG (finds only ~300 genes, 23% recall):
   database="gene"
   query="archaea AND nifH"
   Problem: Missing [Organism] and [Gene Name] field tags!

✅ CORRECT (human genes):
   database="gene"
   query="Homo sapiens[Organism] AND TP53[Gene Name]"

❌ WRONG (incomplete results):
   query="human AND TP53"

Examples - OTHER DATABASES: MeSH: database="mesh", query="asthma[MeSH Terms]" PubMed: database="pubmed", query="CRISPR[Title/Abstract] AND gene editing" Taxonomy: database="taxonomy", query="Escherichia coli[Scientific Name]" ClinVar: database="clinvar", query="BRCA1[Gene Name] AND pathogenic[Clinical Significance]" PubChem: database="pccompound", query="aspirin[All Fields]"

Learn more: https://www.ncbi.nlm.nih.gov/books/NBK3837/

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
databaseNo
queryNo
max_resultsNo
start_indexNo
sort_byNo
search_fieldNo
dbNo
termNo
Behavior5/5

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

With no annotations, the description fully bears the burden of behavioral disclosure. It thoroughly explains the API behavior, query construction requirements, database-specific nuances, and performance implications. It also notes that field tags can dramatically affect recall, providing transparency about the tool's limitations and best practices.

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?

The description is well-structured with clear sections (warnings, args, returns, examples) and front-loaded critical information. However, it is quite verbose; some repetition (e.g., multiple examples for the same concept) could be trimmed. Still, every sentence serves a purpose, so it's more comprehensive than bloated.

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 the tool's complexity (8 parameters, no output schema, no annotations), the description is remarkably complete. It covers all parameters, provides extensive examples, warns about common pitfalls, and includes a link to official documentation. The only minor gap is lack of explicit pagination details, but start_index is mentioned and examples cover many scenarios.

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

Parameters5/5

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

Despite 0% schema description coverage, the description compensates excellently. It defines each parameter in the 'Args:' section, including database options with critical field tag warnings, query format, aliases (db, term), and optional parameters. Examples further illustrate parameter usage, adding significant meaning beyond the bare 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?

The description clearly states the tool's purpose: 'Search NCBI databases using E-utilities esearch API.' It specifies the verb (search), resource (NCBI databases), and method (E-utilities). The detailed list of supported databases and examples effectively distinguishes this tool from siblings like ncbi_efetch or ncbi_esummary.

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?

The description provides explicit, critical usage guidelines, particularly regarding field tags for Gene and ClinVar databases. It includes mandatory field tags, impact analysis (70-80% data loss without tags), and numerous correct vs. incorrect examples. This gives clear when-to-use and when-not-to-use guidance, with actionable alternatives.

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

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/dbcls/togomcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server