Skip to main content
Glama
Sign In

Jean — Molecular Biology & Genomics

by io.github.genmnz
OverviewDiscussionsAdmin

codon_table_fetch

Read-only

Fetch a real codon-usage table for an organism and save it into this project, so later steps can score against it by name.

Input Schema

NameRequiredDescriptionDefault
modeNowhich CDS set to count. `heg` uses the highly-expressed-gene set, which is what CAI and Fop reference tables are conventionally built from; `genome` counts every annotated CDS, which describes the organism's average gene rather than its best-expressed one. Values: heg (Highly-expressed genes — the CAI/Fop convention), genome (Whole genome — every annotated CDS). Only applies when source is ncbi.heg
_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.
sourceNowhich register to build the table from. `ncbi` counts the CDS of a RefSeq assembly and covers any organism with one; `kazusa` serves a published table and covers only the organisms its mirror bundles. Values: ncbi (NCBI RefSeq — counted from annotated CDS, any organism), kazusa (Kazusa/CUTG mirror — published table, bundled organisms only).ncbi
save_asNothe name to save the table under, as `table` on the other codon tools will spell it. Defaults to the resolved organism plus the basis, which is what the panel names 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.
coverageNohow much of a multi-replicon assembly to download. `complete` takes every replicon; `budgeted` takes the largest ones that fit a memory budget and SAYS which it used. The panel defaults to complete and falls back when the browser cannot hold the whole thing. Values: complete (Complete assembly), budgeted (Budgeted — largest replicons that fit). Only applies when source is ncbi.complete
organismYesthe organism: a scientific name ("Saccharomyces cerevisiae") or an NCBI taxonomy id ("4932"). Resolved live against NCBI — no allow-list (§1 r4) — and the assembly it picks comes back in `report.builtFrom`.

Output Schema

NameRequiredDescriptionDefault
cdsYeshow many CDS the table was counted from — the reference-set size, and the number a thin table is thin by. Absent on a register that publishes no counts
gc3YesGC at the third codon position (%), the usage fingerprint. NCBI only; absent elsewhere
tableYesthe saved name — wire this straight into `table` on codon_usage_analysis or codon_optimality
codonsYestotal codons counted, the weight behind every frequency. ABSENT when the register publishes frequencies rather than counts (the Kazusa mirror does) — never 0, which would be a number you could quote
reportYesthe full provenance: register, resolved organism, the identifier the table was built from, and any coverage fallback
organismYesthe organism as the register resolved it, which may be more specific than asked

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedOutput schema / properties / gc3 / x-unit
      Added value: +"%"
  2. First observed

TDQS

B3/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 states the tool 'save[s] it into this project' and the save_as parameter ('the name to save the table under') confirms a persistent artifact is written into project state. That is a state mutation, directly at odds with the read-only annotation, so the description and structured metadata disagree about the tool's side effects.

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 that states the action, the target, and the payoff, with no filler. It is efficient, though for a seven-parameter tool with two nested object types it is arguably too compact.

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?

An output schema exists and parameter documentation is complete, so the description need not explain return values. However, for a tool that persists an artifact into the project, the description never says what document gets created, how it appears in the project/library, or how name collisions with an existing saved table are handled.

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 mode, source, coverage, save_as, organism and the nested _subject/_files shapes are already documented in the schema, including enum value explanations and defaults. The description only echoes 'organism' and the naming-for-later-use idea; it adds no syntax or resolution detail (e.g., taxonomy-id vs scientific name, which live in the schema).

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 verb and resource ('Fetch a real codon-usage table for an organism') plus the effect ('save it into this project, so later steps can score against it by name'), which distinguishes it from scoring tools like codon_usage_analysis or codon_optimality. It stops short of naming a sibling explicitly, so the boundary is inferred rather than stated.

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?

Usage is implied rather than prescribed: it is a preparatory step whose output is consumed 'by name' in later scoring steps. There is no explicit when-to-use/when-not, no mention of what to do if a table for that organism already exists, and no named downstream tool that consumes the saved table.

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