Skip to main content
Glama

jean — Molecular Biology & Genomics

build_genbank_submission

Read-only

Turn a record into the SUBMISSION SET NCBI's table2asn consumes: a .fsa whose defline carries the source modifiers, and a 5-column feature table (.tbl) beside it. This is not a GenBank export — GenBank's submission pipeline takes neither a .gb nor a plain fasta. Its real work is REFUSING and MIGRATING what GenBank will not accept: twelve feature keys were retired in 2014 in favour of regulatory (promoter, terminator and RBS among them, so every plasmid map is affected), a qualifier not on a key's approved list is dropped by name, and an unapproved key is kept as a misc_feature carrying its original name. Since December 2024 GenBank has required collection_date and geo_loc_name on every submission, and both are validated here against the INSDC vocabularies BEFORE a file is written. It WRITES FILES and sends nothing: no account, no key, no upload — table2asn stays yours to run, and the submission template it also wants is yours to make.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
_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.
genbankYesthe record to submit, as GenBank text. Its features and topology are read from it — wire it from an export, or paste it.
_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.
mol_typeNoone of INSDC's two MANDATORY qualifiers on the source key. Omitting it lets table2asn choose, which is a scientific fact picked by a tool.genomic DNA
organismNothe scientific name of the source organism. `synthetic construct` is a real answer for a built vector, not an absence.synthetic construct
topologyNocircular for a plasmid. With this omitted table2asn writes `linear` into the LOCUS line, so a plasmid is deposited as a linear molecule with no error anywhere. Left empty, the record's own topology is used. Values: (From the record), circular (Circular), linear (Linear). Advanced.
geo_loc_nameNowhere the sample came from: a country, ocean or sea from the INSDC vocabulary, optionally `:region` and `, locality`. MANDATORY since December 2024, and it takes the same missing-value terms.missing: lab stock
collection_dateNowhen the sample was collected. MANDATORY on every GenBank submission since December 2024. `DD-Mmm-YYYY`, `Mmm-YYYY`, `YYYY`, an ISO form, or two of them separated by `/` for a range. A construct that was never collected anywhere takes an INSDC missing-value term such as `missing: lab stock`.missing: lab stock

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
filesYesthe submission set: one entry per file, each with its `name` and `text`. The two names share a basename, which is how table2asn pairs them
changesYesevery feature the writer migrated, relabelled, refused or stripped a qualifier from, each with the authority's reason. Never empty-because-nothing-was-checked
commandYesthe exact table2asn invocation for the set, naming the submission template the user must make first
readingYeswhat the set is, generated from the record that was written rather than from the request
writtenYesfeatures written into the table. Branch on this rather than counting `changes`
problemsYeswhy the set cannot be submitted as it stands — an illegal collection date or a locality outside the vocabulary. Empty means the two mandatory modifiers are good, never that NCBI will be silent
featureTableYesthe `.tbl` alone, for pasting or diffing

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.3/5.0
Behavior5/5

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

Annotations only cover safety/openness; the description adds a great deal of behavior the agent could not otherwise know: retired feature keys are migrated to `regulatory`, unapproved qualifiers are dropped by name, unknown keys survive as `misc_feature` with the original name, and collection_date/geo_loc_name are validated against INSDC vocabularies before any file is written. It also discloses that files are written locally with no account, key, or upload, which is consistent with openWorldHint=false and destructiveHint=false.

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

Conciseness3/5

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

The deliverable and the 'not a GenBank export' caveat are correctly front-loaded, but the middle stretch (the 2014 feature-key retirement, the plasmid-map aside, the refusal/migration narrative) is dense flavor that does not directly help an agent select or invoke the tool. It is information-rich rather than wasteful, yet it is longer than the invocation decision requires.

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?

An output schema exists, so return values need not be explained, and the annotations cover safety. What remains — required inputs, the mandatory date/location validation, the fact that nothing is uploaded and the template is the caller's responsibility — is all stated, leaving no material gap for a correct call.

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% and the schema already documents mol_type, geo_loc_name, collection_date, topology and the `_subject` record selector in detail, so the baseline is 3. The description reinforces a few of these (mandatory-by-Date facts, source modifiers on the defline) but adds little syntax or format detail beyond what the schema states.

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 first sentence states a precise verb+resource+artifact: turn a record into the submission set `table2asn` consumes, specifically a `.fsa` with source modifiers plus a 5-column `.tbl`. It also explicitly rules out adjacent interpretations ('This is not a GenBank export'), so an agent can separate it from exporters and from the ENA/addgene deposit siblings without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives clear when-not guidance ('GenBank's submission pipeline takes neither a .gb nor a plain fasta') and defines the boundary of responsibility ('table2asn` stays yours to run'). It does not, however, name an alternative sibling such as build_ena_submission or build_addgene_deposit, so routing between deposit builders is left to inference.

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