Skip to main content
Glama

Jean — Molecular Biology & Genomics

codon_usage_distance

Read-only

How this region's codon usage compares with the record's OTHER genes (CUFS, Diament, Pinter & Tuller 2014).

Input 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.
featureNoscore this annotated CDS or gene by NAME instead of the selection (the panel's "A CDS / feature…" mode). Its own strand is used unless `reverse` says otherwise.
reverseNoread the region as the reverse complement. Leave unset to take the strand from the annotation when the selection is exactly an annotated CDS or gene, which is what the panel does.
_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.
synonymousNonormalise each amino acid's codons to sum to 1 (synCUFS), so what remains is the synonymous choice alone. Off compares all 64 codon frequencies, which also reflects amino-acid composition.

Output Schema

NameRequiredDescriptionDefault
regionYeswhat was actually scored, naming the STRAND and where it came from — a reverse-strand gene read forwards is a wrong answer, not a missing one
ceilingYesthe largest distance this run could have produced, for the mode it ran in — read a distance against THIS, never against a constant
nearestYesthe feature whose codon usage is closest to the scored region
skippedYesfeatures that were NOT compared and why — a feature too short for the statistic is reported, never dropped
comparedYeshow many features were compared
furthestYesthe feature whose codon usage is least like the scored region — the odd one out
neighboursYesevery other coding feature with its CUFS distance, nearest first — name, span, codons compared and distance
synonymousYeswhether amino-acid composition was normalised away — the same column of figures means a different thing under each
strandSourceYes`explicit` (you passed `reverse`), `feature` (taken from the annotation the selection matches) or `default` (forwards, nothing said otherwise)
nearestDistanceYesits distance. 0 would mean an identical codon distribution; the maximum depends on the mode and is reported as `ceiling` beside it — sqrt(2 ln 2) = 1.177 for the plain form, sqrt(2 ln 2 F) = 5.396 for the synonymous one, which normalises each amino acid separately

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

B3.2/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds the useful baseline fact that the comparison is against other genes in the same record and cites the CUFS method, but says nothing about preconditions (minimum number of genes) or about the effect of the synonymous toggle, which is the main analytical subtlety.

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?

A single front-loaded sentence with no filler; the citation earns its place by anchoring the metric. It is arguably too terse rather than bloated, which is not a conciseness fault.

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

Completeness3/5

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

With an output schema and full annotation coverage, the description only needs to fix the comparison semantics, and it partly does. However, for a 5-parameter tool with a nested record object, it omits what happens when the record has few or no other genes and how the chosen region is delimited relative to the feature/_subject parameters.

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% and the schema's own prose already explains feature, reverse, _subject and the synonymous normalisation in detail. The description adds only the comparison baseline ('the record's OTHER genes'), not parameter-level meaning, so baseline 3 applies.

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 gives a specific comparison: this region's codon usage versus the record's other genes, named as CUFS with a literature citation. It is far clearer than a bare 'codon usage' sibling, though it never says what form the result takes (a single distance value?) and does not name nearby tools like codon_usage_analysis or discover_codon_outliers.

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

Usage Guidelines2/5

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

There is no when-to-use guidance at all – nothing about when a comparative distance beats plain codon_usage_analysis, or when discover_codon_outliers is the better call. Only the implicit hint 'OTHER genes' suggests it needs a multi-gene record.

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