jean — Molecular Biology & Genomics

trim_trace

Read-only

Trim a Sanger read's low-quality ends, by either of the two methods that answer different questions: the instrument's own Mott record as written into the file, or a sliding mean-Phred window computed here. Returns the kept interval as 1-based inclusive bounds, and the mean quality of what it KEPT beside the mean of what it DISCARDED — the pair that says whether the trim was worth making, because a trim whose discarded ends score no worse than the bases it left has shortened the read for nothing.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`min_q`	No	the mean Phred the window has to hold for a bound to stop walking inward.
`_files`	No	The 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.
`method`	No	auto = the file's own Mott record when it has one and the sliding window when it does not; mott = the instrument's record, which SCF and ZTR never carry; window = always compute it here.	auto
`_subject`	No	The 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.
`document`	No	which trace file to read: its name (`read_F.ab1`) or its project file id. A file id is project-specific, so a template ships this unset.
`win_size`	No	bases in the sliding window, when the window method runs.

Output Schema

TableJSON Schema

Name	Required	Description
`reading`	Yes	the same sentence the editor shows for this run, generated from it
`sequence`	Yes	the trimmed read, ready to align or verify
`keptBases`	Yes	how many bases survived. Wire it into a gate: a read trimmed to nothing is not a read
`methodUsed`	Yes	which one actually ran. `auto` and `mott` both answer `window` when the file carries no Mott record, and a pipeline that assumed otherwise trimmed on a threshold nobody chose
`lastBaseKept`	Yes	1-based inclusive
`firstBaseKept`	Yes	1-based inclusive, matching every trim readout in the editor
`meanQualityKept`	Yes	mean Phred over the kept interval
`meanQualityDiscarded`	Yes	mean Phred over what was cut. Read it AGAINST the kept figure: if it is not lower, the trim removed nothing bad

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 20, 2026

TDQS

A3.7/5.0

Behavior4/5

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

The annotations already establish that this is a non-destructive read-only operation. The description adds behavioral context beyond the annotations by explaining what the returned kept-interval and quality means imply, and why comparing discarded versus kept quality matters. It does not discuss auth, rate limits, or side effects, but none appear relevant.

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 action and is generally efficient. The second sentence is dense but earns its space by explaining how to interpret the returned quality pair; it avoids boilerplate repetition.

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?

For a six-parameter tool with full schema coverage and an output schema, the description is largely complete: it explains the operation, the two methods, and the meaning of the result. The main remaining gap is decision guidance relative to sibling read-trimming tools.

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 schema already carries the detailed meaning of min_q, method, win_size, document, _subject, and _files. The description restates the conceptual distinction between the mott and window methods but adds little parameter-specific detail beyond what the enum descriptions already provide.

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?

States a specific verb and resource: trimming a Sanger read's low-quality ends. It also explains the two available methods, which is more than a tautology. It does not explicitly differentiate itself from the nearby sibling trim_reads, so it falls just short of a 5.

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 the tool's use case — cleaning Sanger traces — and notes the two methods answer different questions, but it does not state when to choose this tool over trim_reads or other trace-consuming siblings, nor when to prefer mott versus window at a decision level.

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 tools Inspect

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

Need Help?