Skip to main content
Glama
musharna

plant-genomics-mcp

by musharna

Synthesis: Locus Overview

analyze_locus_synth
Read-onlyIdempotent

Resolve a plant locus via Ensembl Plants and cross-reference xrefs, UniProt, literature, and Gene Ontology in parallel. Return reconciled summary flagging name and accession conflicts across sources.

Instructions

Synthesis: one-call equivalent of the analyze_locus prompt. Resolves a locus through Ensembl Plants, then fans out to xrefs, UniProt, Europe PMC, and QuickGO in parallel. Returns a SynthesisEnvelope with per-step status and a reconciled summary flagging cross-source name/accession disagreements.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
locusYesLocus name, e.g. AT1G01010
organismNoPlant organism — accepts canonical slug (arabidopsis_thaliana), scientific or common name, or NCBI taxidarabidopsis_thaliana

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
toolYesSynthesis tool name, e.g. analyze_locus_synth
inputYesEchoed input arguments
stepsYesPer-backend execution rows
resultNoComposed cross-source result; None if root step failed
elapsed_sYesTotal orchestrator wall time
started_atYesISO 8601 UTC timestamp

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.22.0
    • changedOutput schema / $defs / StepRow / description
      Previous value: -"One backend call inside a synthesis envelope.\n\n``status=\"ok\"`` populates ``result``; ``status=\"error\"`` populates ``error``\nwith the existing ``[ExceptionClass] message`` wire format from\n``errors.PlantGenomicsError.__str__``. ``status=\"skipped\"`` populates\n``error`` with a human-readable skip reason (e.g. phase 1 failed)."New value: +"One backend call inside a synthesis envelope.\n\n``status=\"ok\"`` populates ``result`` — unless the orchestrator carries the\npayload elsewhere in the envelope (``gene_report`` keeps it once, under\n``result.sections``), in which case the row is the audit trail alone and\n``result`` is None. ``status=\"error\"`` populates ``error`` with the\nexisting ``[ExceptionClass] message`` wire format from\n``errors.PlantGenomicsError.__str__``. ``status=\"skipped\"`` populates\n``error`` with a human-readable skip reason (e.g. phase 1 failed)."
    • changedOutput schema / $defs / StepRow / properties / elapsed_s / description
      Previous value: -"Per-step wall time when separately measurable, else None. Phase-2 gather rows and phase-0 pre-call validation failures return None because their wall time can't be honestly attributed per-step; SynthesisEnvelope.elapsed_s carries the authoritative total."New value: +"Per-step wall time: every awaited backend call is timed on its own, including inside a phase-2 gather. None only for rows that never ran (skipped, or a phase-0 pre-call validation failure); SynthesisEnvelope.elapsed_s carries the orchestrator total."
  2. First observedv1.8.0

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the safety bar is met. The description adds genuinely useful behavior beyond annotations: parallel fan-out, per-step status reporting, and the reconciled summary that flags cross-source name/accession disagreements. No contradiction with annotations.

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?

Two sentences with no filler, front-loaded with the synthesis purpose and immediately followed by scope and return details. The phrase 'one-call equivalent of the analyze_locus prompt' is slightly redundant with the synthesis framing but still earns its place as context.

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?

An output schema exists, so return values need not be re-explained, yet the description still names the SynthesisEnvelope and its contents. Given the orchestration complexity, the description covers what it does, which sources it touches, and what it returns; the missing piece is explicit routing guidance versus the individual sibling tools, but annotations and schema cover the rest.

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% with full descriptions for both locus and organism parameters, so the baseline is 3. The description mentions resolving 'a locus' but adds no parameter-specific syntax, format, or behavior details beyond what the schema already documents.

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 (resolves) and resource (locus via Ensembl Plants), then names the exact fan-out targets (xrefs, UniProt, Europe PMC, QuickGO). The 'Synthesis: one-call equivalent' framing clearly differentiates it from the many individual sibling tools like get_gene_xrefs or resolve_locus_to_uniprot, telling the agent this is the aggregated variant.

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?

'One-call equivalent of the analyze_locus prompt' implies it is the all-in-one alternative to calling individual sibling tools separately, but the description never explicitly says when to prefer it versus calling get_gene_xrefs or resolve_locus_to_uniprot alone, nor states exclusions. Usage is implied rather than stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.