Skip to main content
Glama

Jean — Molecular Biology & Genomics

compare_trees

Read-only

Compare trees over the same taxa: the Robinson-Foulds distance between two of them, and the consensus of any number.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "trees": "<trees>"
    },
    "name": "compare_trees"
  }
}

Input Schema

NameRequiredDescriptionDefault
modeNohow strict the consensus is: strict keeps only clades in EVERY tree; majority keeps those above the cutoff. Values: majority (Majority-rule), strict (Strict).majority
treesYestwo or more trees in Newick (NEXUS, PhyloXML and NeXML pastes are sniffed too) — wire `newick` outputs here.
_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.
cutoffNothe fraction of trees a clade must appear in for a majority consensus. Only applies when mode is majority.
_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.
sharedTaxaOnlyNoprune every tree to the taxa they ALL share before comparing, instead of refusing a mismatch. The numbers then describe the pruned trees, and pruning can only remove or merge splits, so the distance is a lower bound on the disagreement between the trees as given.

Output Schema

NameRequiredDescriptionDefault
rfYesRobinson-Foulds distance between the first two trees (absent for one tree)
consensusYesthe consensus tree, in Newick
distancesYesevery distance the comparison computes, not just RF
treeCountYeshow many trees went into the consensus
normalizedYesthe same distance as a fraction of its maximum, 0 = identical topology, 1 = share nothing
prunedTaxaYesunder `sharedTaxaOnly`: the labels dropped from each tree, so a comparison over a smaller set can never be read as one over the whole
comparedTaxaYeshow many taxa the distances were computed over — under `sharedTaxaOnly` this is the shared set, which is smaller than either tree

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.5/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds one behavioral fact beyond that — that trees must share taxa, which is why the pruning option exists — but says nothing about what happens on mismatch absent sharedTaxaOnly, or about pagination/size limits. Adequate but thin given annotations carry most of the load.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence with zero filler: the resource, the scope constraint and both outputs are packed into one clause. Nothing repeats the title or wastes words.

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 6 parameters (one nested), an output schema and annotations present, the hard structural facts are covered elsewhere. However, the description leaves ambiguous what is returned when three or more trees are supplied (pairwise distances? consensus only?) and does not mention the mismatch-refusal behavior that sharedTaxaOnly toggles.

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%, and the schema already explains mode, cutoff, trees and sharedTaxaOnly in detail (including the lower-bound caveat). The description adds no parameter-level detail beyond the implicit 'same taxa' constraint, so the schema baseline of 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?

States a specific verb and resource ("Compare trees over the same taxa") and names the two computations: Robinson-Foulds distance for a pair and consensus for any number. That distinguishes it from siblings like tree_statistics, draw_tree, build_tree and transform_tree. It stops short of saying how the tool behaves when given more than two trees for the distance case, so it is not 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?

Usage is only implied by the phrase "over the same taxa" — an agent can infer this is the tree-comparison tool, but no alternative is named and no condition selects it over tree_statistics or discover_tree_incongruence. There are no explicit when-not-to-use notes.

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