plant-genomics-mcp

Overview Schema Source Related Servers Discussions Admin

Synthesis: Homolog Search

find_homologs_synth

Read-onlyIdempotent

Runs BLAST to find homologous sequences, resolves matched UniProt accessions, and returns ranked hits with their UniProt annotations.

Instructions

Synthesis: one-call equivalent of the find_homologs prompt. Runs BLAST then resolves UniProt-shaped subject accessions via the batch UniProt helper. Returns ranked hits each annotated with their UniProt record (or null if subject_id is not a UniProt accession).

Input Schema

TableJSON Schema

Name	Required	Description	Default
`top_n`	No
`program`	No		blastp
`sequence`	Yes	Query sequence (protein or nucleotide)

Output Schema

TableJSON Schema

Name	Required	Description
`tool`	Yes	Synthesis tool name, e.g. analyze_locus_synth
`input`	Yes	Echoed input arguments
`steps`	Yes	Per-backend execution rows
`result`	No	Composed cross-source result; None if root step failed
`elapsed_s`	Yes	Total orchestrator wall time
`started_at`	Yes	ISO 8601 UTC timestamp

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv1.22.0Sep 24, 2026

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."

First observedv1.8.0May 30, 2026

TDQS

A3.6/5.0

Behavior4/5

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

Annotations already cover read-only, idempotent, and non-destructive behavior. The description adds meaningful behavioral detail beyond that: it runs BLAST first, then resolves subject accessions via a batch helper, and explicitly documents the null-result case for non-UniProt accessions. This is useful and consistent with the annotations.

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?

Three tightly scoped sentences with no filler. The synthesis label and core pipeline are front-loaded, and the result semantics are stated in the final sentence, making the description easy to parse quickly.

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?

Given the rich annotations and existing output schema, the description covers the essential pipeline, return format, and edge case (null UniProt record). It lacks explicit guidance on choosing program or interpreting top_n, but for a synthesis wrapper with this structured metadata, it is largely complete.

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

Parameters2/5

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

Schema description coverage is low (33%), and the description does not compensate: it never explains top_n or program beyond what the schema's defaults and enum provide. The mention of 'subject_id' refers to an output concept rather than any input parameter, adding no parameter-level guidance.

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?

The description states a specific pipeline: BLAST plus UniProt resolution, returning ranked hits with UniProt annotations. It distinguishes itself as a one-call synthesis of the find_homologs prompt and its return semantics separate it from a plain BLAST tool, though sibling differentiation is implicit rather than explicit.

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 phrase 'one-call equivalent of the find_homologs prompt' implies when to use it, and the pipeline description implies it replaces a multi-step workflow. However, it does not explicitly state when to prefer this over siblings like blast_sequence or batch_gramene_homologs, nor does it mention any exclusions.

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

Deploy Server