Skip to main content
Glama

Brapi Germplasm Performance

brapi_germplasm_performance
Read-only

Aggregate a single germplasm's observations across every study it appears in, returning per-variable summary statistics (n, mean, median, sd, min, max), the contributing studies, and seasons. Study-anchored: discovers the germplasm's studies first (with a dialect-honor cross-check, capped at 200 studies), then pulls observations per study — avoids the unanchored germplasm-only pull that stalls on SGN/Breedbase. Pass an explicit studyDbIds set to skip discovery and its 200-study cap — e.g. process a chunk of the full study list retrieved via brapi_find_studies with extraFilters.germplasmDbIds. For the underlying observation matrix, use brapi_build_phenotype_matrix.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
aliasNoConnection alias registered via brapi_connect. Omit to read the connection registered under alias `default` — i.e. a prior brapi_connect call that did not specify an alias. Calls that used a non-default alias must pass that same alias here.
variablesNoOptional subset of observationVariableDbIds to aggregate. Omit to include every variable observed for the germplasm.
studyDbIdsNoOptional explicit set of studyDbIds to aggregate over. When supplied, skips automatic study discovery and its 200-study cap entirely — use it to process a specific slice of studies, e.g. the full germplasm-scoped study set retrieved via brapi_find_studies with extraFilters.germplasmDbIds. Omit to let the tool discover the germplasm’s studies automatically.
germplasmDbIdYesThe germplasmDbId to summarize performance for.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
aliasNoAlias of the registered BrAPI connection used.
errorNoPresent when the call failed. Absent on success.
warningsNoAdvisory messages (study-discovery limits, dropped filters, fallback paths, per-study failures).
studyCountNoNumber of distinct studies that contributed any observation.
studyDbIdsNoDistinct studyDbIds that contributed observations.
perVariableNoPer-variable aggregates, sorted by observationVariableDbId.
germplasmDbIdNoThe germplasm that was analyzed.
germplasmNameNoDisplay name of the germplasm, when the server provides one.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Beyond the readOnlyHint/openWorldHint annotations, the description discloses the study-anchored execution order, the 200-study cap, the dialect-honor cross-check, and the performance rationale. No statement contradicts 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?

Four sentences with no filler: result, execution mechanism, optimization path, and sibling alternative each get exactly one sentence. The main outcome is front-loaded before implementation details.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given a rich schema, an output schema, and read-only/open-world annotations, the description covers the core aggregation behavior, the study-discovery cap, the explicit-study shortcut, and how to get the raw matrix. An agent has everything needed to select and invoke it.

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%, so the schema already documents all four parameters thoroughly. The description's studyDbIds guidance largely duplicates the schema's own description, so it adds little per-parameter meaning beyond the baseline.

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?

The description opens with a precise contract: 'Aggregate a single germplasm's observations across every study it appears in' and itemizes the output (n, mean, median, sd, min, max, studies, seasons). It also distinguishes the tool from the sibling raw-matrix tool by deferring to brapi_build_phenotype_matrix.

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?

It gives an explicit alternative ('For the underlying observation matrix, use brapi_build_phenotype_matrix') and a concrete decision rule for studyDbIds: omit for automatic discovery, or pass an explicit set to skip discovery and the 200-study cap. It also advises against the unanchored germplasm-only pull that stalls on SGN/Breedbase.

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.