Skip to main content
Glama

jean — Molecular Biology & Genomics

search_records

Read-only

Search the sequence archives by free text (a gene name, a protein, an organism, a phrase) across NCBI Nucleotide and Protein, ENA (plain records, WGS and TSA/TLS assembly sets, and annotated coding/non-coding features), UniProtKB and the iGEM Registry at once, and hand back the matching accessions. This is the half of Fetch from database that answers "which record do I want?"; fetch_record answers "give me that one". A source that is down does not fail the search: its error comes back beside the hits the others returned.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNohow many hits to ask each source for. The panel pages at this size, and every source is asked for the same number.
queryYesthe words to search for. Archive query syntax is accepted where the archive accepts it, but plain words are the normal case: "beta-lactamase Escherichia coli", "GFP", "pUC19".
_filesNoThe project: record references shaped like _subject. Their records become library documents a tool names in sequences/parts/document; a trace or alignment is found by file name.
sourcesNowhich archives to ask. Each is searched independently and the hits are interleaved, so asking more costs time rather than accuracy. Defaults to the nucleotide pair the panel opens on.
_subjectNoThe record to act on: exactly one of sequence, accession (+source), sample (an id from list_samples) or file ({name, text} or {name, base64}); record_index picks one record of several.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
hitsYesthe full result rows: accession, title, source, organism, length, molecule kind and the archive’s own reported fields
sourceYeswhich archive the top hit came from, ready for the same node's $source where the two vocabularies agree
hitCountYeshow many records came back across every source asked
accessionYesthe top hit's accession, ready for a fetch_record node's $accession. This is the seam between searching and fetching
accessionsYesevery hit’s accession, newline-separated, in the order they are ranked
unavailableYesthe sources that could not answer, each with the reason: empty when every source answered. A search is not a failure because one archive is down, and hiding that would make a short list read as a small literature

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, openWorldHint and destructiveHint, lowering the bar. The description still adds real behavioral context beyond them: results are accessions, sources are searched independently, and a downed source returns its error alongside the other hits rather than failing the whole search.

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 with the verb and scope, then the sibling contrast, then the failure semantics. Three sentences that each carry weight, though the long parenthetical enumerating ENA sub-sources is heavier than an agent strictly needs.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return shape need not be explained, and the description covers routing, source set and partial-failure behavior. Given nested _subject/_files params, it could say more about how a search result connects to fetch_record inputs, but the essentials are present.

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 coverage is 100%, so the schema already documents query, limit, sources, _files and _subject. The description reinforces query examples and the source set but adds no syntax or semantics beyond what the schema provides, so the baseline 3 applies.

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 (search) and resource (sequence archives), enumerates the exact sources searched (NCBI Nucleotide/Protein, ENA variants, UniProtKB, iGEM), and names the sibling it is not: 'fetch_record answers give me that one'. An agent can distinguish the two 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?

Explicitly frames the decision: this tool answers 'which record do I want?' while fetch_record answers 'give me that one'. That is a direct when/when-not routing rule, not an implied one.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources