Skip to main content
Glama

Jean — Molecular Biology & Genomics

design_gene_fragment_order

Read-only

Write the sheet IDT's gene-fragment PLATE upload takes for one or more designed fragments: one worksheet per 96-well plate, wells in the template's own order, and the template's four columns (well, name, sequence, 5' phosphorylation).

Input Schema

NameRequiredDescriptionDefault
namesNoa name per fragment, in the same order. Required with `sequences`: a well is ordered by name, so an unnamed fragment is refused rather than numbered.
_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.
featureNoorder a named feature of the open record instead of the whole record: the insert rather than the vector it sits in. Advanced.
productNowhich IDT fragment product to order the fragments as. It sets the length range a fragment must fall in, and eBlocks take a per-plate minimum. Values: idt-gblocks (gBlocks Gene Fragments (125–3,000 bp)), idt-eblocks (eBlocks Gene Fragments (300–1,500 bp)).idt-gblocks
_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.
sequencesNothe fragments to order, 5'→3'. Leave unset to order the open record, or the current selection or named `feature` of it, under the record's name.
plate_nameNothe plate's name, which becomes the worksheet's name. Several plates get ' (2)', ' (3)' appended.Plate 1
phosphorylateNoask for 5' phosphorylation on every fragment. IDT offers it for blunt cloning only.

Output Schema

NameRequiredDescriptionDefault
rowsYesevery plate as header-first rows in the template's column shape, keyed by worksheet name: what the .xlsx holds
sheetsYesone entry per PLATE: its worksheet name and every laid-out well, each with the published limits it sits outside
columnsYesthe template's header row
profileYesthe vendor profile the length range came from, with its page and retrieval date
readingYeswhat the order is, generated from the laid-out plates
refusedYesevery fragment left OUT, with the reason
plateCountYeshow many plates the fragments needed
plateMinimumYesset when the product takes a minimum per plate and a plate falls under it; empty otherwise

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already declare read-only, non-destructive, non-open-world behavior, so the description need not restate safety. It adds useful output behavior: one worksheet per 96-well plate, wells in template order, and the exact four columns produced.

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?

It is a single front-loaded sentence with no obvious filler, and the colon list efficiently packs the output shape. The phrasing is dense but still readable and purpose-first.

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?

Given the output schema and detailed parameter descriptions, the description is largely complete for understanding what is generated. It omits deeper operational details such as validation rules or plate minimums, but those are handled by structured fields.

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 parameter meaning is already well supplied by the schema. The description reinforces the output columns and ordering but adds little parameter-specific detail beyond what the schema already documents.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific action and artifact: writing the IDT gene-fragment PLATE upload sheet for designed fragments. It identifies the output structure clearly enough to separate it from generic primer or oligo ordering, though it does not explicitly name the closest sibling tools.

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

Usage Guidelines3/5

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

The description implies when the tool is useful by saying it is for one or more designed fragments and formats an IDT plate upload. It does not state when to use this instead of sibling ordering tools or mention exclusions, so the guidance is only implied.

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