Skip to main content
Glama

jean — Molecular Biology & Genomics

select_substitution_model

Read-only

Choose the substitution model for a maximum-likelihood phylogeny by fitting every candidate — model x rate-heterogeneity x invariant-sites — on ONE shared topology and ranking them by AIC, AICc or BIC with Akaike weights. Fitting on a shared topology is the point: a model test that also searched topologies would vary two things at once, and a log-likelihood measured on a different tree answers a different question. Wire the winning model into build_tree's ml_model.

Input Schema

TableJSON 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.
modelsNocandidate substitution models. Every one is fitted; the sweep costs one ML optimisation per candidate.
_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.
criterionNowhich information criterion ranks the table. Changing it re-ranks candidates that are already fitted — it does not re-fit them.AIC
sequencesYesaligned sequences — wire align_sequences' rows here, or name library documents.
include_subjectNoalso include the node's subject.
gamma_categoriesNodiscrete-Γ category counts to try. `[1]` is no rate heterogeneity; `[1, 4]` is the usual sweep and is the panel's default.
include_invariantNoalso try each model with a proportion of invariant sites (+I), doubling the candidate count.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
bestYesthe winning model in the conventional shorthand (e.g. `GTR+G4+I`)
fitsYesevery candidate with its log-likelihood, free parameters, AIC/AICc/BIC and Akaike weight
weightYesthe winner's Akaike weight — the share of the evidence it carries. A low weight means the data do not choose between the top models, which is a finding and not a failure
candidatesYeshow many candidates were fitted
startingTreeYesthe ONE topology every candidate was fitted on, in Newick — reported because it is a shared assumption of the whole table

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=false), so the burden is lighter. The description adds genuine behavioral context absent from annotations: the fitting is done on a shared topology, and it explains why that constraint exists (varying two things at once would answer a different question). It does not, however, quantify compute cost or sweep size in the description itself.

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?

Front-loaded with the action, then a short methodological justification, then the concrete handoff to build_tree. Every sentence contributes, though the middle rationale sentence is slightly discursive for an agent deciding whether to call the 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, return values need no explanation, and annotations carry the safety profile. The description still adds the key operational fact (the result feeds build_tree's ml_model) and the shared-topology invariant, leaving little an agent needs beyond what structured fields supply.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3 and the schema already documents every parameter. The description adds the conceptual decomposition that the candidate space is 'model x rate-heterogeneity x invariant-sites', which clarifies the interaction of models, gamma_categories, and include_invariant beyond their individual schema entries.

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 ('Choose the substitution model for a maximum-likelihood phylogeny') and precisely defines the mechanism (fit every model x rate-heterogeneity x invariant-sites candidate on one shared topology, rank by AIC/AICc/BIC). It ends by naming the sibling build_tree and the exact parameter (ml_model) the result feeds, so it is unmistakable against neighbors.

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

Usage Guidelines5/5

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

Explicitly positions the tool as a precursor step whose output is wired into build_tree's `ml_model`, giving a concrete workflow context rather than an implied one. The shared-topology rationale also clarifies the condition under which this test is the right choice (you must not vary topology and model simultaneously).

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