Skip to main content
Glama

jean — Molecular Biology & Genomics

by io.github.genmnz
OverviewDiscussionsAdmin

build_ena_submission

Read-only

Turn a record into what ENA's Webin-CLI takes for an annotated sequence (-context sequence): an ENA flat file (.embl) and its manifest. Features are checked against the tables ENA's own validator reads, so what Webin-CLI would refuse (an unknown key, a missing mandatory qualifier, a double quote in a value, a duplicate feature) is refused or rewritten here, by name. A description under 10 characters, an entry under 100 bp and a missing study are reported first. It WRITES FILES and sends nothing.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
studyNothe Webin Portal study accession (PRJEB… or ERP…). Webin-CLI refuses a set without one; left empty, the files are written and the reason reported.
_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, topology and DEFINITION are read from 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_typeNothe source feature's mandatory /mol_type. `other DNA` is the INSDC value for a synthetic construct.other DNA
organismNothe scientific name of the source organism; ENA checks it against its taxonomy. `synthetic construct` is a real answer for a built vector.synthetic construct
topologyNocircular for a plasmid (the ID line; only then may a feature cross the origin). Left empty, the record's own topology is used. Values: (From the record), circular (Circular), linear (Linear). Advanced.
descriptionNothe DE line, what the sequence is. Left empty, each record's own DEFINITION is used; ENA refuses one shorter than 10 characters.
geo_loc_nameNowhere the sample came from, from the INSDC vocabulary, or a missing-value term.missing: lab stock
collection_dateNowhen the sample was collected, on the source feature. Optional, but must be INSDC-legal; a construct takes a missing-value term such as `missing: lab stock`.missing: lab stock

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
filesYesthe flat file and its manifest, each with its `name` and `text`. Gzip the flat file before running Webin-CLI; the manifest already names the `.gz`
changesYesevery feature the writer refused, rewrote or left a qualifier off, each with ENA's reason
commandYesthe exact gzip and webin-cli invocation, with -validate
readingYeswhat the set is, generated from what was written
writtenYesfeatures written, source excluded
flatFileYesthe `.embl` alone, for reading or diffing
problemsYeswhy Webin-CLI will refuse the set as it stands: a short description, a short entry, no study, or a malformed date or locality. Empty means none of those, never that the validator will be silent

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.5/5.0
Behavior1/5

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

Annotations declare `readOnlyHint=true` and `destructiveHint=false`, but the description explicitly says 'It WRITES FILES,' which is a filesystem write and contradicts the read-only claim. This is an annotation contradiction; despite otherwise useful validation detail, the contradiction forces a 1.

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 front-loaded with the core transformation and then details validation checks; every sentence contributes useful information. It is dense but not bloated for a 10-parameter, nested-object tool.

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?

With an output schema present, the description needn't explain return values. It covers purpose, validation, side effects, and error reporting, though the annotation contradiction creates a misleading signal about the write side effect.

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 the baseline is 3. The description adds cross-parameter validation notes (unknown keys, missing mandatory qualifiers, double quotes, duplicate features, entry under 100 bp) that go beyond individual schema fields, but it largely repeats schema-provided meanings for study, description, mol_type, and organism.

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: turning a record into an ENA flat file (`.embl`) and manifest for Webin-CLI, with validation against ENA's own feature tables. It distinguishes itself from other build_* siblings by naming ENA, Webin-CLI, and the file types produced.

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?

Gives clear context: this is for building an ENA Webin-CLI annotated-sequence submission, it writes files, and it sends nothing. It does not explicitly name an alternative sibling to use instead, but the ENA/Webin-CLI framing is sufficient to route correctly among the build_* tools.

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

All jean — Molecular Biology & Genomics toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources