Skip to main content
Glama
musharna

plant-genomics-mcp

by musharna

Synthesis: Biological Context

biological_context_synth
Read-onlyIdempotent

Resolve a plant gene locus and retrieve its biological context in one call. Fetches homologs, pathways, protein interactions, and co-expression data in parallel, then ranks consensus partners by merged interaction and co-expression scores.

Instructions

Synthesis: one-call equivalent of the biological_context prompt. Resolves UniProt accession, then fans out to Gramene homologs, KEGG pathways, STRING-DB partners, and ATTED-II coexpression in parallel. Adds a consensus_partners ranking that merges STRING + ATTED scores.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
locusYes
top_nNo
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

A4.2/5.0
Behavior4/5

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

Annotations already declare read-only, idempotent, open-world, and non-destructive. The description adds valuable process context beyond annotations: the resolution step, parallel fan-out, and the consensus_partners ranking merging STRING + ATTED scores. It stops short of detailing failure modes or behavior when resolution fails, but the added pipeline detail is substantial.

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?

Two sentences with zero filler. The core purpose and pipeline steps are front-loaded, and every clause adds distinguishing information.

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, the description need not explain return values. It clearly defines the scope of the synthesis and its unique consensus ranking. The only notable omission is differentiation from analyze_locus_synth, another synthesis sibling whose scope could overlap; specifying the boundary would fully close the context.

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 only 33% (organism only). The description compensates for locus by explaining it must be resolvable to a UniProt accession, and for top_n only indirectly via the consensus ranking. However, top_n semantics are still left to inference from its schema metadata (default 10, max 50), so the description does not fully bridge the coverage gap.

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 ('Synthesis') and a precise resource ('biological_context'), then enumerates the exact pipeline: resolves UniProt accession, fans out to Gramene, KEGG, STRING-DB, and ATTED-II, and adds a consensus_partners ranking. This clearly distinguishes it from the individual source tools among its siblings.

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

Usage Guidelines4/5

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

Calling it a 'one-call equivalent of the biological_context prompt' and listing the four source databases implies when to use it: when a consolidated biological context is needed rather than separate calls. However, it does not explicitly state when not to use it or how it compares to sibling synthesis tools like analyze_locus_synth.

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