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

Annotations already mark it read-only, idempotent, and non-destructive, but the description adds important behavioral details: it resolves locus to UniProt, returns specific fields (plddt confidence, band ranges, model version, download URLs), and defines edge cases—found=false for valid proteins without a model (a normal outcome) and a typed NotFoundError for missing UniProt entries. This goes well beyond the annotations and gives an agent a clear picture of outcomes.

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

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

The description is dense but well-organized: it opens with the core purpose, enumerates the returned data, covers edge cases and errors, notes the sibling relationship, and closes with defaults. Every sentence contributes value; no filler. It front-loads the primary action and resource, making it easy to scan.

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

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

For a tool with two parameters, an output schema, and several nuanced behaviors (resolution, error types, default organism, links-to-fetch-only), the description covers all of them. It even mentions the full organism set (12 organisms, UniProt-keyed). Nothing an agent needs to invoke it correctly is missing.

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

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

Schema coverage is 100% and both parameters already have descriptive text (e.g., locus examples, organism acceptors). The description reinforces the default organism and explains the locus resolution, but it does not add significant meaning beyond the schema. Baseline 3 is appropriate given the schema's completeness.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a clear verb and resource: 'Fetch the AlphaFold DB predicted-structure summary for a locus', naming the external service and the input type. It also differentiates from the sibling resolve_locus_to_uniprot by explicitly stating this is the structure-level view, so an agent can immediately tell them apart.

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

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

It explicitly names the sibling tool and the distinction ('Complements resolve_locus_to_uniprot (sequence-level) with the structure-level view'). It also gives practical usage context: defaults to arabidopsis_thaliana, the need to pass organism for others, and that the returned URLs are for the client to fetch (not for the tool to download). These are direct when/how-to-use cues.

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

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.

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.

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.

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.

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.

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.

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

Annotations already establish read-only, idempotent, and non-destructive behavior, and the description adds valuable context beyond that: the service is free and requires no key, pagination has a true-count caveat ('variant_count is the true row total even when capped'), and unsupported organisms raise a specific error. This helps an agent reason about external-service behavior, truncation, and failure modes.

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

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

The description is three dense sentences with the core action front-loaded, followed by return content and critical caveats. Parentheticals add relevant detail without excessive padding. It could be slightly tighter, but every sentence carries useful information and the structure is logical.

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

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

The output schema covers return values, so the description correctly focuses on selection criteria, organism restriction, pagination semantics, and external-service access details. An agent has enough information to decide whether to call this tool and to set expectations about errors and result limits. Nothing essential for correct invocation is missing.

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

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 three parameters, including the AT1G01060 example, cursor usage, and organism default. The description repeats the default organism but does not add substantive parameter-level meaning beyond the schema. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb and resource: 'Fetch 1001 Genomes natural-variation SNP effects for an Arabidopsis locus.' It clearly defines the data scope (1135 resequenced accessions) and the tool's specialized output, setting it apart from generic locus or variant tools. It also states the return payload concretely, so an agent knows exactly what this tool produces.

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

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

The description provides strong usage context by naming the data source, explaining the organism restriction ('ARABIDOPSIS-ONLY'), and stating the default organism. It also warns that non-Arabidopsis organisms raise OrganismNotSupported. However, it does not explicitly compare this tool to sibling alternatives like locus_variants, so the when-to-use-vs-alternatives guidance is implied rather than explicit.

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

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

Annotations already cover the safety profile (readOnly/idempotent/destructive=false), and the description goes well beyond them: it discloses no-auth access, deterministic ordering (strongest first), page size and cap, cursor semantics, the guarantee that association_count is the true total even when page-capped, and the OrganismNotSupported failure mode. That is substantial operational context.

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

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

A single dense paragraph with the core action front-loaded and pagination/organism constraints at the end. Nearly every clause carries unique information, though it is long enough that mild trimming would improve scannability.

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

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

For a read-only, output-schema-backed tool, the description covers everything an agent needs: what is returned, ordering, pagination, the true-total caveat, authentication needs, and the error condition. Nothing essential is missing.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaning the schema lacks: the ordering guarantee behind limit (strongest first), the resume semantics of next_cursor (first row not returned), and the organism constraint ('Arabidopsis only'). This raises it above baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (fetch) and resource (AraGWAS GWAS association hits) scoped to an Arabidopsis locus, and enumerates the returned fields (score, MAF, predicted effect, phenotype/study, thresholds). This clearly distinguishes it from neighbors like arabidopsis_natural_variation and locus_variants without opening any schema.

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

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

The description implies its use case (pull GWAS hits for a locus) and notes it is free/no key, plus a hard constraint that non-Arabidopsis input raises OrganismNotSupported. However it never routes the agent among the many sibling locus tools (e.g., arabidopsis_natural_variation, locus_variants) or states when this source is preferable, leaving usage to inference.

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

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

Beyond the readOnly/idempotent annotations, it discloses concrete behavior: per-organism release resolution, explicit error behavior (OrganismNotSupported before any request, NotFoundError for missing loci), score_type semantics, and the organism allowlist. This is substantial context an agent would not get from the annotations or schema.

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

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

The description is front-loaded with purpose and output, followed by release, organism, and error details in a logical order. The final 'Pairs with string_interactions' sentence is ambiguous and slightly undercuts the otherwise tight structure.

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

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

Given the output schema and annotations already exist, the description is largely complete: it covers organisms, errors, scoring, and release handling. Minor unresolved details are the exact meaning of 'Pairs with string_interactions' and possible API limits, which are not critical for calling the tool.

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

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

Schema coverage is 67% and locus/organism already have decent descriptions. The description adds value by clarifying top_n as the number of returned neighbors, enumerating the organisms accepted by organism, and explaining release resolution. It does not merely repeat the schema text.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: 'Fetch co-expressed gene neighbors from ATTED-II.' It names API v5, the input (plant locus), the output shape (top_n neighbors with locus, Entrez ID, score), and the supported organisms, so an agent can distinguish it from sibling interaction tools like string_interactions.

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

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

The description states what it returns and lists supported organisms, but it never explicitly says when to choose this over coexpression or interaction alternatives, and it does not give exclusions. The final sentence about pairing with string_interactions is too vague to count as solid usage guidance.

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

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

Beyond the readOnlyHint and idempotentHint annotations, the description discloses substantive behavior: the response shape is discriminated by the `kind` field, the image URL is only a link and no tool on this server retrieves it, rice rejects RAP-DB Os*g* format upstream, and unsupported organisms raise OrganismNotSupported. This is rich, accurate behavioral context that goes well beyond 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.

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

The description is dense but every sentence earns its place. It front-loads the core purpose, then efficiently covers endpoint routing, response fields, organism-specific caveats, and failure behavior. There is no redundancy or filler.

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

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

Given this tool has an output schema and complete parameter schema coverage, the description adds the remaining context an agent needs: supported organisms, endpoint dispatch, response shape discrimination, the MSU locus requirement, and error behavior. Nothing critical is missing for correct invocation.

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

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

Although the schema already documents both parameters well (100% coverage), the description adds essential semantics beyond it: the exact locus formats expected for each organism, the rejection of RAP-DB identifiers for rice, and how the `kind` field in the response relates to the organism-specific behavior. These details materially help an agent select correct parameter values.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: 'Fetch BAR AIV (Arabidopsis Interactions Viewer) interactions for an Arabidopsis or rice locus.' It clearly defines the tool's scope, distinguishes it from generic interaction tools by naming AIV and the unique endpoints, and calls out the supported organisms. The purpose is unambiguous and not a tautology.

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

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

The description provides clear context on when to use the tool: for Arabidopsis or rice AIV interactions, and explicitly says other organisms raise OrganismNotSupported. It also gives decisive routing guidance (curated GRN papers for Arabidopsis, predicted PPI partners for rice) and locus-format requirements. However, it does not explicitly name alternative tools or state when a sibling should be preferred, so it falls just short of full usage guidance.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive. The description adds valuable behavioral details: the endpoint it wraps, the fields returned (per-replicate, control samples, lat/lng), the client-side computation of the mean, and the approximate ecotype count. It also notes keyless access and the resource's status. No contradictions; it complements the annotations well.

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

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

The description is moderately sized but packs essential information: main purpose, endpoint, output fields, ecotype count, keyless access, and resource status. The most critical information (what it fetches) is front-loaded, and every sentence adds value. It could be slightly tighter, but it avoids redundancy.

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

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

Given the presence of an output schema (not shown here but indicated), the description needn't detail the full return structure, but it does list the main fields. It covers constraints (Arabidopsis only, keyless), the nature of the data, and the source. For a simple one-parameter read-only tool, this is complete enough for an agent to invoke it correctly.

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

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

Schema description coverage is 100% for the single parameter (locus), with a clear AGI format example. The description adds minimal additional meaning beyond the schema—it reiterates the locus usage and Arabidopsis restriction but doesn't introduce new syntax or formatting guidance. Baseline 3 is appropriate because the schema already fully documents the parameter.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('Fetch'), a precise resource (BAR/eFP world-map natural-variation expression), and the object (Arabidopsis locus). It distinguishes itself from siblings by specifying 'world-map natural-variation expression' and the exact endpoint path, leaving no ambiguity about what it does.

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

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

It provides clear context: this is for Arabidopsis natural-variation expression across ecotypes, and notes 'Arabidopsis only' and 'BAR is keyless.' While it doesn't explicitly name alternative tools or when not to use it, the specificity of the domain (expression vs. summary, interactions, etc.) implicitly guides selection. A minor gap is the absence of explicit exclusions.

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

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

Beyond the annotations, the description adds valuable behavioral context: BAR is keyless, no subscription is needed, data comes from specific endpoints, and the underlying resource carries taxon 3702 plus yeast/human for ortholog cross-reference. This meaningfully supplements the readOnly/idempotent annotation hints.

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

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

The description is front-loaded with the core action and return contents, and is dense but not bloated. The phrase 'Global Core Biodata Resource (2023)' is a credibility credential rather than operationally necessary detail, and 'keyless' plus the endpoint breakdown are the most valuable extras.

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

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

For a one-parameter tool with an output schema, the description covers the input scope, data provenance, exact endpoints, returned fields, access model, and the intended replacement use case. Nothing essential is missing for an agent to call it correctly.

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

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

The lone parameter 'locus' is already fully documented in the schema with the same Arabidopsis AGI locus format and example (AT1G01010). The description does not add new precision about accepted formats or edge cases, so the schema carries the weight here.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb and resource: 'Fetch the BAR ... merged ThaleMine + GAIA-aliases summary for an Arabidopsis locus.' It enumerates the returned content (TAIR curator summary, Araport11 description, NCBI Gene ID, cross-DB aliases) and explicitly distinguishes itself from the older tair_locus_info stub, making its role clear.

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

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

The description gives clear use context: it is for Arabidopsis locus curator summaries, excludes non-Arabidopsis use, and explicitly positions itself as replacing the subscription-gated tair_locus_info stub. It does not, however, contrast itself against other sibling locus/xref tools such as get_gene_xrefs or ensembl_plants_lookup_locus.

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

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

Annotations already declare read-only, open-world, idempotent, and non-destructive behavior, so the bar is lower. The description adds concrete behavioral details: the 50-locus cap and early OrganismNotSupported error for unsupported organisms, which go beyond what annotations provide.

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

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

Three short sentences with no filler. Key constraints are front-loaded, and each sentence adds useful information: batch nature, capacity, supported organisms, and error behavior.

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

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

Given the output schema and simple wrapper semantics, the description covers batch capacity, supported organisms, and failure mode. It could more explicitly state when to choose this over the single atted_coexpression, but the batch naming and sibling context make that reasonably clear.

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

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

Schema description coverage is only 33%, so the description must compensate. It adds the supported organism list and the 50-locus cap, but the cap is already in schema maxItems and it says nothing about top_n, leaving a core parameter's meaning undocumented.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States it is the batch version of atted_coexpression, with a concrete batch limit of 50 loci and a list of supported organisms. This distinguishes it from the single-locus sibling, though it never explicitly states the action (e.g., 'retrieves coexpression data').

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

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

Gives explicit batch capacity (up to 50 loci), enumerates supported organisms, and states that unsupported organisms raise OrganismNotSupported before any request. It implies use for batch queries but does not explicitly contrast with the single atted_coexpression tool or other batch siblings.

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

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

The description adds context beyond annotations: parallel execution, 50-locus limit, organism constraint per call, and the varying result payload per organism (papers vs partners). It does not contradict annotations.

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

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

Two sentences efficiently convey purpose, constraints, and result structure without redundancy. Every sentence adds value.

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

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

Given the batch complexity and existing output schema, the description covers parallelism, limit, organism sharing, and result structure. Minor gap: no explicit error handling beyond mentioning errors[locus], but overall sufficient.

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

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

Schema coverage is 100%, so baseline is 3. The description adds that loci are identifiers with success/failure mapping in results and errors, but does not significantly extend schema-provided parameter meanings.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it is a batch variant of bar_aiv_interactions, outlines the parallel fan-out for up to 50 loci, and specifies the result structure per locus. It distinguishes itself from the single-locus sibling by focusing on batch processing.

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

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

The description implies usage when querying multiple loci, noting the constraint that all loci share the same organism. It distinguishes from the single-locus variant but does not explicitly compare with other batch tools or state when not to use it.

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

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

Annotations already provide readOnlyHint, openWorldHint, idempotentHint, destructiveHint=false. Description adds behavioral context: fan-out in parallel, up to 50 loci, result structure, and organism restriction. 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.

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

Three sentences, front-loaded with purpose and constraints. No extraneous information. Every sentence adds value (batch variant, parallel fan-out, payload summary, organism restriction).

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

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

Given that an output schema exists (as per context), the description sufficiently explains return values without needing full schema details. Covers key payload fields and error handling, and includes scope (Arabidopsis) and limits (50 loci).

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

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

Schema coverage is 100% with a description for the loci parameter. Description adds meaning about array items and error handling ('Successes land in results[locus]; PlantGenomicsError failures in errors[locus]'), which goes beyond the schema-provided description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states it's a batch variant of bar_gene_summary, describes parallel fan-out over up to 50 loci, and specifies the output structure (curator summary, computational description, NCBI Gene ID, cross-DB aliases). Distinguishes from sibling bar_gene_summary by being batch and from other batch tools by specifying the exact per-locus payload.

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

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

Explicitly says 'Batch variant of bar_gene_summary' and 'Arabidopsis only', implying use for multiple loci. Does not explicitly state when not to use (e.g., for single locus), but the context is clear. Provides information about parallel execution and payload structure.

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

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

Discloses retry behavior (429/5xx via _http helper, Retry-After capped at 60s), explains error handling (misses in errors[] with prefix), and notes result shape matches single-locus tool. Adds value beyond annotations.

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

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

Two sentences, front-loaded with purpose, no redundancy. Every sentence adds value.

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

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

Given batch complexity, error handling, and cost benefit, the description is thorough. Output schema exists, annotations cover safety, so all behavioral aspects are addressed.

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

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

Schema coverage is 100%, so baseline 3. Description adds that loci max is 50 and clarifies error structure, providing context beyond schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states it's a batch variant of a single-locus tool, uses POST /lookup/id endpoint for up to 50 loci, and highlights cost efficiency. Distinguishes from sibling 'ensembl_plants_lookup_locus'.

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

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

Implicitly guides use for multiple loci via 'batch variant' and 'cheaper than N parallel GETs'. No explicit when-not or alternative mentions, but context is clear.

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

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

Annotations already indicate read-only, idempotent, open-world, non-destructive behavior. The description adds valuable context: parallel fan-out, 50-locus limit, and the output structure per locus. No contradictions 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.

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

The description is two sentences with no wasted words. It front-loads the core identity ('Batch variant of get_gene_xrefs') and then details behavior concisely.

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

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

Given the presence of full annotations and an output schema, the description is complete. It covers the batch nature, parallelism, limits, and output shape. No critical missing information for effective tool use.

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

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

Schema description coverage is 100%, so baseline is 3. The description does not add meaning beyond the schema; it mentions the loci parameter implicitly but does not elaborate on organism. The parameter semantics are adequately covered by the input schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies this as a batch variant of get_gene_xrefs, describes the parallel fan-out over Ensembl Plants with a max of 50 loci, and specifies the output shape per locus. It effectively distinguishes this tool from the single-locus version.

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

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

The description implicitly suggests use for multiple loci, but lacks explicit guidance on when to use this vs alternatives (e.g., the single-locus get_gene_xrefs or other batch tools). No when-not-to-use or alternative mentions are provided.

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

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

Annotations already cover read-only and idempotent safety. The description adds the 50-locus limit, the shared filter behavior, and the return envelope structure (count + results + errors), which are useful behavioral details beyond the schema and annotations.

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

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

Two sentences with zero waste. It front-loads the batch nature and key constraints (cap, filter sharing, return format) and avoids unnecessary elaboration.

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

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

Given the output schema and detailed parameter descriptions, the description covers the essential cap and filter behavior. It doesn't mention optional parameters like with_organism or target_organism, but those are fully described in the schema, so an agent has enough to call it correctly.

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

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

Schema description coverage is 75% (homology_type lacks a description). The description adds that homology_type is shared across all loci, giving meaning to that parameter. Other parameters are well-documented in the schema, so the description adds value where needed without redundancy.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it is a batch version of gramene_homologs, with a 50-locus cap and shared homology_type filter. This distinguishes it from the single-locus sibling and conveys the core function without ambiguity.

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

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

The 'Batch version' phrasing implies use for multiple loci, and the 50-locus cap hints at splitting larger requests. However, it doesn't explicitly name the single-locus alternative or state when not to use it, nor does it differentiate from other batch tools like batch_locus_call.

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

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

Annotations already indicate read-only, idempotent, and non-destructive behavior. The description adds valuable traits: the 50-loci cap and the pre-request validation that raises OrganismNotSupported for unsupported organisms. This goes beyond annotations without contradicting them.

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

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

Three concise sentences, each carrying essential information: batch nature, limit, supported organisms, and error behavior. The content is front-loaded and there is no redundancy or filler.

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

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

For a read-only batch tool with an output schema and safety annotations, the description covers the key operational details: batch limit, organism coverage, and error handling. It does not explain what the loci parameter should contain, but that may be inferred from the sibling kegg_pathways tool. Overall, the description is sufficient for an agent to call the tool correctly.

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

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

The schema covers the organism parameter with a description, but the loci parameter has no schema description, and the tool description does not clarify what loci should be (e.g., gene IDs, locus identifiers). The description does add the list of supported organisms and the error behavior, but it only partially compensates for the undocumented loci parameter.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description identifies the tool as the 'Batch version of kegg_pathways', which clearly indicates its purpose as a batched pathway lookup. It specifies the batch limit (50 loci) and enumerates supported organisms, differentiating it from the single-locus sibling and other batch tools. However, it never explicitly states that it returns KEGG pathways for the given loci, relying on the sibling's implied functionality.

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

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

It implies usage for multiple loci via the 'batch version' phrasing and sets clear limits. It also explicitly warns that unsupported organisms raise an error before any request, guiding the agent to validate organisms upfront. It does not name alternatives or explicitly state when not to use it, but the context is sufficient.

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

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

The description substantially enriches the annotations by disclosing that args are shared across loci and validated once against the target tool's schema, that the response is a standard batch envelope keyed by locus, that each result matches the single-tool output, and that per-locus errors are included. This is exactly the behavioral nuance an agent needs beyond readOnly/idempotent hints.

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

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

The description is compact and front-loaded, with the core action, limit, examples, behavior, and relationship to dedicated batch tools all conveyed in three sentences. The only minor drag is the issue-number reference (#131), which is noise for an agent selecting the tool.

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

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

Given the output schema exists and the annotations already carry the safety profile, the description covers what an agent needs: eligibility, argument handling, limits, and the response envelope. It could be slightly more explicit about when the generic batch path should be chosen over dedicated batch tools, but nothing required for a correct call is missing.

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

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

Schema description coverage is 67%, so the description must compensate, and it does. It explains the meaning of 'tool' beyond the enum, defines 'args' as the target tool's non-locus arguments, and states that args are shared and schema-checked. It adds real semantic value over the bare schema, though the schema already covers the 'loci' array limit and basic args shape.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: 'Run one locus-keyed tool over up to 50 loci in one call'. It further clarifies the exact class of tools eligible ('any tool whose only required argument is "locus"') with concrete examples, making it easy to distinguish from the single-locus tools and the dedicated batch_* siblings.

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

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

The description states the eligibility condition for the 'tool' argument and notes that 'dedicated batch_* tools remain', but it does not explicitly say when to prefer this generic batch tool over a dedicated batch_* sibling. The use case is implied (batch many loci through one locus-keyed tool) rather than directly contrasted with alternatives.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds significant behavioral detail: the two-stage fanout, per-locus error handling (NotFoundError into errors[] with typed prefix), and the 50-locus cap. This goes well beyond 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.

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

The description is four sentences, each adding distinct information: purpose, process, error behavior, and cap. No unnecessary words; front-loaded with the most important information (batch variant).

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

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

Given the complexity of a batch tool with a two-stage process, the description covers the key aspects. It mentions error handling and the cap. However, it could benefit from a brief note on when to prefer this over other batch tools or the single-locus version, though the tool name and sibling set provide some context.

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

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

Schema coverage is 100%, and the description adds context about error handling for the 'loci' parameter (how errors are structured). It also clarifies the default for 'organism' and the range for 'limit'. This adds value beyond the schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states it is a batch variant of locus_go_annotations, specifies the two-stage fanout (locus to UniProt to QuickGO), and includes a cap of 50 loci. This distinguishes it from the single-locus sibling tool.

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

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

The description implies use for multiple loci by being a batch variant, and mentions the cap of 50 loci. However, it does not explicitly state when not to use it or compare with other batch tools (e.g., batch_locus_literature) to avoid confusion.

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

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

Annotations already provide readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds value by explaining parallel execution and error handling (successes in results, errors in errors), going beyond what annotations offer.

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

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

The description is two sentences with no wasted words. It front-loads the purpose ('Batch variant of locus_literature') and efficiently covers parallelism, limits, and result structure.

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

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

Given the tool's complexity (batch, parallel, error handling), the description covers all key aspects: it's a batch, fan-out, max 50 loci, per-locus response payload. Output schema exists, so return values are covered. No gaps.

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

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

Schema description coverage is 100%, and the description does not add significant meaning beyond what the schema already provides. It mentions 'up to 50 loci' which is already in schema maxItems. Baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it is a batch variant of locus_literature, specifies parallel per-locus searches for up to 50 loci, and describes the results structure. This distinguishes it effectively from the single-locus sibling.

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

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

The description implies usage when multiple loci are involved but does not explicitly state when to use this tool versus other batch tools like batch_locus_go_annotations or alternatives. No direct comparison or exclusion criteria are provided.

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

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive. The description adds that it fans out in parallel with a 50-locus limit and specifies error handling (errors[locus]), providing useful context beyond annotations.

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

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

Two concise sentences: first sets context (batch, parallel, limit), second describes output structure. Every sentence earns its place with no superfluous information.

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

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

Given the output schema exists, the description adequately covers batch behavior, limits, and error handling. However, comparing to siblings, it could better highlight when to prefer this batch tool over others.

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

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

Schema coverage is 100%, but the description adds value by explaining loci limits and stating that organism accepts slugs, scientific/common names, or NCBI taxids, aiding correct parameter usage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states this is a batch variant that fans out per-locus BioMart queries in parallel, and specifies the max loci and output structure, distinguishing it from the single-locus sibling.

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

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

It identifies as a batch version but does not provide explicit guidance on when to use it versus other batch tools or the single-locus version, missing opportunities to guide selection among numerous siblings.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds valuable behavioral context: parallel fan-out, batch size limit of 50, and error handling per locus. This goes beyond annotations.

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

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

Two sentences succinctly convey the tool's batch nature, parallelism, limits, and output structure. Every sentence is informative and well-placed.

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

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

Given the presence of an output schema and detailed annotations, the description fully covers the tool's purpose, behavior, limits, and result format. No critical gaps remain.

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

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

Schema coverage is 100% and each parameter has a schema description. The tool description adds no additional semantic information about parameters beyond what the schema already provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it is a batch variant of resolve_locus_to_uniprot, performing parallel searches for up to 50 loci. It explicitly distinguishes from the single-locus sibling by specifying batch behavior and result structure.

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

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

The description indicates it is a batch variant, implying use for multiple loci, but does not explicitly state when not to use or list alternatives among sibling batch tools. However, the context is clear given the sibling list.

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

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 the batch limit and a deprecation note about the parameter name change, which are useful. However, it does not disclose how partial failures are handled, rate limits, or other batch-specific behaviors, leaving some gaps beyond 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.

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

The description is two sentences with no wasted words. It front-loads the key batch limit and then adds the deprecation note. It is efficient and easy to parse, though it could have included a bit more context without becoming verbose.

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

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

For a batch tool with three parameters and an output schema present, the description is minimal. It doesn't explain batch semantics (e.g., whether a single failed locus invalidates the whole call), pagination, or how the limit interacts with the batch. The deprecation note is helpful but not sufficient for a tool that likely has complex edge cases. The output schema mitigates some return-format ambiguity, but operational details are missing.

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

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

Schema coverage is only 33% (only organism has a description). The description adds semantic info for the loci parameter by noting its deprecated name (loci_or_accessions), which helps. But it provides no explanation for the limit parameter or how batching interacts with it, and the organism parameter's flexible types are not elaborated. Given the low schema coverage, more parameter guidance is needed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states this is the batch version of string_interactions, which distinguishes it from the single-input sibling. It also specifies the batch limit (up to 50 inputs), making the tool's scope explicit. However, it doesn't restate what string_interactions does, relying on the sibling name for context.

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

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

The description implies usage for multiple loci ('up to 50 inputs') but does not explicitly state when to choose this over the single version or how to decide between other batch tools. The deprecation note provides some usage guidance about accepted parameter names, but no exclusions or alternatives are mentioned.

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

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.

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.

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.

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.

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.

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.

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

Annotations give only the safety profile (readOnly, openWorld, non-destructive). The description adds substantial behavioral detail beyond them: async Put/Get polling, the NCBI per-RID 60s floor, progress notifications per poll, the >10 min failure mode raising UpstreamUnavailableError with the RID preserved for re-polling, and the required NCBI etiquette env var. This is exactly the operational context an agent needs and justifies a top score.

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

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

The description is dense but front-loaded, opening with the core operation before moving to async mechanics, program/database defaults, and error behavior. Every sentence carries information, though the async/error/env-var block is a touch long. Efficient overall.

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

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

With an output schema present it need not describe return values, and it doesn't over-explain them. For a long-running, polling-based external call it covers the full behavioral surface: submission, polling cadence, progress events, timeout/failure semantics with RID preservation, and NCBI identification. Nothing an agent needs to invoke it correctly is missing.

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

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 8 parameters including the database default mapping and the poll floor. The description largely restates the program list and database defaults already present in the schema, adding little semantic value beyond it. Baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb+resource: 'Run a BLAST sequence-similarity search against NCBI BLAST URLAPI.' It even enumerates supported programs, so the agent knows exactly what operation is performed. It stops short of differentiating itself from homology-oriented siblings (find_homologs_synth, consensus_homologs), which is the only thing keeping it from a 5.

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

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

Usage is implied rather than stated: the agent can infer this is the tool for raw/fasta sequence input as opposed to a locus identifier. There is no explicit 'use this when you have a sequence, use X when you have a locus' routing, and no stated exclusions. Adequate but leaves selection vs siblings to inference.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered by structured data. The description adds genuinely useful behavioral context beyond that: the parallel execution model, deduplication by 'normalized locus token', and the exact scoring formula including the identity=1.0 default for Gramene and pident/100 for BLAST. No contradiction 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.

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

Roughly 40 words, densely packed, with the purpose front-loaded in the first phrase ('cross-source homology consensus'). Every sentence earns its place: pipeline order, parallel sources, dedup rule, and scoring formula. There is zero fluff or repetition of schema/annotation content.

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

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

For a moderately complex multi-step pipeline, the description covers the essential mechanics: resolution step, parallel homology calls, dedup, and scoring. The output schema exists, so return-value documentation is not the description's job, and annotations cover the safety/read-only profile. Remaining gaps are the when-to-use routing (vs. find_homologs_synth) and parameter detail for locus/top_n, which were already penalized in other dimensions.

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

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

Schema coverage is only 33% — only 'organism' has a schema description. The tool description partially compensates by explaining that the locus is 'resolved to UniProt + FASTA sequence' and that hits are scored, which implies what locus and top_n do. However, it never specifies the expected locus format (e.g., AGI ID vs symbol) or clarifies that top_n caps the returned hit list. The compensation is partial, not complete.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses specific verbs and resources: it 'resolves UniProt + FASTA sequence', 'runs Gramene homology calls and NCBI BLAST in parallel', 'dedupes hits', and 'scores by n_sources * mean_identity'. The opening phrase 'cross-source homology consensus' immediately distinguishes it from single-source siblings like gramene_homologs and blast_sequence, so an agent can tell this is the synthesis tool without opening the schema.

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

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

The description implies usage context — choose this when you want a consensus across multiple homology sources rather than any single one — but it never explicitly states when to use this tool versus alternatives like gramene_homologs, blast_sequence, or the similarly-named find_homologs_synth. No 'when not to use' or alternative-routing guidance is given.

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

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

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, but the description goes well beyond them. It discloses ordering (karyotype first, then scaffolds/contigs longest first), naming conventions (Ensembl names like CM001064.4 vs '1'), the in_karyotype flag vs coord_system for identifying chromosomes, and the total-before-limit counting with truncated=true. These are rich behavioral traits that materially affect how an agent interprets results.

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

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

The description is four sentences long but each sentence carries distinct weight: API/endpoint overview, integration with ensembl_region_query, ordering/naming rules, and limit/truncation behavior. It is front-loaded with the primary purpose and then layered with specifics. While not minimal, there is no filler and every clause earns its place, so a 4 fits.

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

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

Given the tool is a read-only metadata endpoint with a simple 2-parameter schema and an output schema, the description covers every critical nuance an agent needs: the exact data returned, ordering rules, naming pitfalls, the distinction between coord_system and in_karyotype, and limit/truncation semantics. It even cites concrete examples (tomato, soybean) to make the behavior tangible. Nothing essential is missing.

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

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

The schema describes the organism parameter completely (slug, name, taxid) but leaves limit only with constraints. The description compensates by explaining limit's effect: 'total counts every region before limit; truncated=true when limit cut some off', and ties region lengths to downstream region_query validation. This adds practical meaning beyond the raw schema, so it earns a 4.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: 'Describe an organism's Ensembl assembly' and enumerates the exact output fields (assembly name, GCA accession, date, karyotype, seq-regions with lengths). It also distinguishes the tool from its sibling ensembl_region_query by explaining how the names it returns are used there, which clearly positions this tool as the assembly metadata provider.

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

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

The description does not explicitly name alternatives or draw exclusions, but it gives a concrete usage scenario: 'a region walk can be planned before the first call' with ensembl_region_query. It implies this tool is the prerequisite for region queries and notes it is 'free, no key', which conveys straightforward access. However, it stops short of saying 'use this when X, not when Y', so it stays at 4.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the default organism and identifier format, which is useful context but not a behavioral trait beyond what annotations provide. It does not describe error behavior or edge cases, but that is not required given 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.

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

Three concise sentences that front-load the core purpose, then add the default and identifier format. There is no redundancy or filler, and every sentence contributes to correct usage.

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

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 covers the primary usage (fetch metadata), the default organism, and the identifier format. It doesn't mention potential limitations (e.g., which species are supported beyond the examples), but the examples and default give enough guidance for a typical call. The lack of sibling differentiation is a minor gap given the tool's simple purpose.

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

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

Schema coverage is 100% for both parameters, so the baseline is 3. The description adds value by explaining the TAIR-style identifier with a concrete example (AT1G01010) and clarifying that organism defaults to arabidopsis_thaliana. This enriches the schema descriptions with practical usage context.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a clear verb ('Fetch metadata') and a specific resource ('plant locus identifier from Ensembl Plants'). It also provides an example identifier and distinguishes the data source from similar tools like TAIR or Phytozome, making its purpose unambiguous.

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

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

The description explains the default organism and how to change it, but it never states when to prefer this tool over the many sibling tools (e.g., tair_locus_info, phytozome_lookup_locus). There is no explicit when-to-use or when-not-to-use guidance, so an agent must infer the appropriate context from the data source alone.

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

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

Beyond the annotations (readOnly, idempotent, openWorld), the description explains output row fields (locus, type, taxonomy_level, perc_id/perc_pos, protein_id), the differences between within_species_paralog and other_paralog, and the pagination behavior (total and counts_by_type before limit, truncated=true). It also warns that a paralogue list is not a family list, which is a subtle non-obvious behavior. This adds substantial context without contradicting 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.

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

The description is long but each sentence serves a purpose: explaining output fields, contrasting with gramene_homologs, clarifying edge cases, and describing pagination. The core purpose is front-loaded in the first sentence, and the detailed examples (AT2G23390, FLS2) justify the length. It could be slightly tighter, but the density is appropriate given the tool's complexity.

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

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

The description covers all non-obvious aspects of the tool: paralogue types, the distinction between empty list and found=false, unknown ID errors, and limit truncation. With an output schema present for return structure, the agent has everything needed to call and interpret the tool. No critical gaps remain for a wrapper around an external API.

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

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

Schema description coverage is 67%, so locus and organism are already documented in the schema. The description does not add any semantic detail about these parameters, and only indirectly hints at the limit parameter through 'truncated=true when limit cut some off.' This is minimal added value; it could have explicitly described the limit's purpose and the organism's accepted formats.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a clear verb and resource: 'List the paralogues Ensembl Compara (plants) records for a plant locus.' It also specifies the underlying API endpoint (rest.ensembl.org /homology, type=paralogues), which unambiguously identifies the tool's function. It further differentiates from sibling gramene_homologs by noting the difference in paralogue types.

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

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

The description contrasts this tool with gramene_homologs, noting that a gene can have paralogues here but none there, and advises using interpro_domains to test family membership. It also clarifies critical semantics: an empty list means Compara records no paralogue, found=false means no homology record, and a not-found error for unknown IDs. This gives an agent clear guidance on when to use this tool versus alternatives.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context beyond annotations: coordinate convention, Ensembl span caps causing errors, dependency on assembly region names, and default organism behavior.

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

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

The description is dense and well-structured, front-loading the core operation, then coordinates, feature choices, use case, error behavior, and default organism in logical order. Every sentence contributes meaningful information without redundancy.

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

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

Despite being a moderately complex tool, the description covers the critical context: coordinate system, feature enum, default organism, error boundaries, and relationship to the assembly tool. The presence of an output schema removes the need to describe return values, so nothing essential is missing.

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

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

Schema description coverage is 100%, so the schema fully documents each parameter. The description largely restates the schema's parameter meanings with examples ('1' or 'Chr1') and the feature default, but adds little semantic detail beyond what the schema already provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Starts with a specific verb and resource ('List features overlapping a genomic interval via Ensembl Plants /overlap/region'), clearly stating the operation and scope. The phrase 'without a per-locus lookup' distinguishes it from sibling lookup tools, and the title reinforces the region-to-features purpose.

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

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

Explicitly describes the use case: answering 'what genes are in this QTL interval / assembly window'. It also names ensembl_plants_assembly as the way to discover valid region names and lengths, and notes error conditions that help an agent decide when this tool is appropriate.

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

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

Even though annotations already mark the tool as read-only, open-world, and idempotent, the description adds substantial behavioral context: it reveals the underlying UniProt query, that it is free and keyless, what each member contains, the meaning of null locus, and the total/truncated/cursor pagination contract. This goes well beyond the annotation signals.

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

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

The description is long but every sentence carries useful information, and the core purpose is front-loaded before the edge-case details. It reads as a compact reference that avoids filler while covering the important quirks.

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

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

Given the tool's complexity, the description is complete: it explains the direction, required input, data source, output fields, null behavior, pagination, reviewed_only caveats, and default organism. With an output schema also present, nothing essential is missing for an agent to select and invoke the tool correctly.

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

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

The schema already covers 80% of parameter meaning, and the description adds extra value by explaining reviewed_only's organism-dependent behavior and how cursor interacts with the truncated field. The description also clarifies entry types through the entry format, building on the schema examples.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific action and resource: list every protein in an organism carrying an InterPro, Pfam, or PANTHER entry along with its gene locus. It also explicitly distinguishes itself from interpro_domains and panther_family by describing it as the reverse direction (entry -> genes).

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

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

The description clearly positions the tool against sibling tools by naming interpro_domains and panther_family and explaining the reverse relationship. It also gives concrete guidance on when to adjust reviewed_only, such as passing false for most crops because reviewed-only results are empty there.

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

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

Annotations already indicate readOnly, openWorld, idempotent, and non-destructive behavior. The description adds substantial behavioral context: one row per evidence record is aggregated to one row per partner, partners are ordered by evidence_count, found=false semantics, NotFoundError for unknown loci, and OrganismNotSupported for non-Arabidopsis organisms. No contradiction with annotations exists.

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

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

Although long, the description is dense and each sentence earns its place: source, data provenance, sibling distinctions, aggregation behavior, ordering, found=false semantics, error behavior, and organism restriction. It is front-loaded with the core purpose and then adds necessary caveats in a logical order.

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

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

Given the tool's moderate complexity and the existing annotations/output schema, the description covers all necessary operational context: data sources, result granularity, support signal, ordering, normal vs error outcomes, and organism limitations. An agent has enough information to call it correctly and interpret its results.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds value beyond the schema by giving an example locus (AT5G11260), clarifying that organism accepts slug/name/taxid but ThaleMine only supports Arabidopsis, and explaining how the locus parameter maps to the returned evidence. This goes beyond the structured schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Fetch') with a precise resource: curated experimental protein/genetic interaction partners for an Arabidopsis locus. It explicitly differentiates itself from string_interactions (predicted/text-mined) and bar_aiv_interactions (GRN paper references), so an agent can distinguish it without inspecting the schema.

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

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

The description explicitly names alternatives and states when they are not appropriate, contrasting with string_interactions and bar_aiv_interactions. It also gives clear selection constraints: Arabidopsis only, other organisms raise OrganismNotSupported, and found=false is a normal outcome rather than an error.

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

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

Annotations already cover readOnly/openWorld/idempotent/non-destructive hints, and the description adds substantial behavioral detail: locus-to-UniProt resolution, best_structures ranking and fields, found=false as a non-error, a typed NotFoundError, and the fact that structure_count is the true total even when the list is capped. This gives an agent accurate expectations for edge cases and error semantics well beyond the annotation hints.

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

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

The description is dense but well-structured: it front-loads the core purpose, then progressively covers result contents, edge cases, the relationship to alphafold_structure, organism scope, and defaults. Every clause carries useful information with no filler, though the length is at the upper edge of what is ideal for a single tool description.

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

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

With an output schema in place, return-value details are covered elsewhere, and the description fills the remaining gaps: supported organisms, the no-structure normal case, the no-UniProt error case, the capped-list behavior, and the relationship to a sibling tool. For a two-parameter, read-only fetch with rich annotations and a full output schema, nothing critical is missing.

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

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

Schema coverage is 100% with descriptions for both parameters, so the baseline is 3. The description adds meaning by explaining that results are UniProt-keyed and that locus resolution precedes the PDBe query, which clarifies how organism interacts with the lookup. It also reinforces the default organism and that organism= can be passed for other species, going slightly beyond the schema's default declaration.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb ('Fetch') and a clear resource ('experimentally-solved protein structures for a locus from PDBe'), enumerating the experimental methods (X-ray / cryo-EM / NMR). It explicitly distinguishes itself from alphafold_structure by labeling that tool as the predicted view, so there is no ambiguity about what this tool retrieves.

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

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

It names alphafold_structure as the predicted counterpart, implying the experimental-versus-predicted decision an agent needs to make. It also explains the expected found=false outcome for most plant proteins and calls out the NotFoundError case, which prevents an agent from misclassifying normal results as failures. The guidance is strong but the 'when-not-to-use' instruction is more implied than explicitly stated.

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

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.

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.

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.

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.

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.

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.

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

Beyond the (safety-only) annotations, the description discloses the output shape (result.markdown headline plus result.sections mirror, steps[] carrying only status/timing), the intentional omissions (abstracts_included: false, with_from_included: false), gene_names labeling, and graceful degradation where a single backend failure becomes an 'Unavailable' note without breaking the rest. That is exactly the behavioral context annotations cannot convey.

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

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

It is dense but front-loaded, leading with the one-line purpose before the fan-out and output details. Each sentence carries information, though the section/steps and omissions details are packed tightly enough that a little trimming would sharpen it.

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

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

For a complex multi-backend synthesis tool with an output schema, the description covers the resolution pipeline, the callable surfaces, degraded-failure behavior, and the deliberate section differences versus sibling tools. An agent has everything needed to invoke it correctly.

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

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

Schema coverage is 100%, so the schema already documents locus, top_n (with its 1-50 cap and per-section capping semantics), and organism. The description adds no syntax or meaning beyond what the schema provides, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource (one-shot 'tell me about this gene' dossier) and enumerates the backend fan-out (Ensembl Plants, UniProt, KEGG, STRING, Europe PMC, QuickGO), so an agent can distinguish it from the many single-source siblings like locus_literature and locus_go_annotations without opening a schema.

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

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

It implicitly routes the agent: it notes that locus_literature and locus_go_annotations return the abstracts and withFrom that this report omits, giving a clear condition for choosing those siblings. It lacks an explicit 'use this instead of the individual tools when…' statement or exclusions, so it falls short of a 5.

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

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

Beyond the readOnly/openWorld/idempotent annotations, the description reveals significant runtime behavior: 'free, no key', total counts members before limit, truncated=true when limit cuts results, canonical slug or null for species outside the server's 12, and 'An unknown tree id is a not-found error.' This is rich, honest behavioral disclosure.

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

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

The description is dense but every sentence earns its place: purpose, output contents, filtering, pagination semantics, and error behavior. It front-loads the core action and naturally orders supporting details, with no filler.

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

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

For a tool with an output schema and strong annotations, the description covers everything an agent needs to call it correctly: required input provenance, optional filtering, pagination/count behavior, server scope, and failure mode. Nothing essential is missing.

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

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

Schema coverage is 67%, and the description compensates meaningfully. It explains where gene_tree_id comes from, how target_organism can be a slug/name/taxid and that omitting it returns all species, and how limit interacts with total and truncated. All three parameters gain real semantic value beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: 'List the member genes of an Ensembl Compara (plants) gene tree.' It clearly identifies the input (gene_tree_id from gramene_homologs) and the value of each member (locus, protein_id, species, taxid, organism), which distinguishes it from sibling tools like gramene_homologs.

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

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

It gives clear context: this consumes the gene_tree_id that gramene_homologs returns on every homolog and produces locus ids accepted by locus-keyed tools. It does not explicitly name alternatives or state when not to use the tool, so it falls just short of a 5.

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

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

Annotations (readOnlyHint, openWorldHint, idempotentHint) already present. Description adds return structure (count, raw xref list, by_db rollup) and dbname key explanation, going beyond annotations.

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

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

Two sentences, front-loaded with action, no wasted words. Every sentence adds value.

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

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

Given output schema exists, description covers inputs, defaults, and output structure sufficiently. No gaps.

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

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

Schema covers both parameters fully. Description adds examples (locus), explains organism accepts various forms (slug, name, taxid), enriching schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Clear verb 'Fetch' with specific resource 'cross-database references for a plant locus from Ensembl Plants'. Distinct from sibling tools like batch_get_gene_xrefs and resolve_locus_to_uniprot.

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

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

Provides default organism and how to use for other species. Lacks explicit when-not-to-use or alternatives, but context is clear.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false. The description adds valuable behavioral context: default parameters, seq_type enum options (including that 'protein' is the canonical-transcript product), and organism flexibility. No contradictions.

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

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

The description is extremely concise (two sentences of functional content plus one sentence of usage guidance) and front-loaded. Every sentence adds essential information without redundancy.

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

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

Given the low parameter count, high schema coverage, and presence of output schema, the description is complete. It covers purpose, parameters with defaults, usage scenario, and chaining to sibling tools. No gaps remain for the agent to guess.

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

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

Schema description coverage is 100%, but the description adds meaning beyond the schema by clarifying the default values for organism and seq_type, and explaining the seq_type mapping to BLAST types (protein for blastp, cds/cdna for blastn). This provides practical usage context not present in the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool fetches a locus's sequence from Ensembl Plants, specifying verb 'Fetch' and resource 'sequence'. It distinguishes from siblings by focusing on sequence retrieval, which is unique among the listed tools.

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

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

The description provides explicit guidance on chaining the output to blast_sequence for different seq_types, and mentions defaults for organism. It doesn't explicitly exclude alternative uses but gives strong contextual cues for when to use this tool.

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

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

Beyond annotations (readOnlyHint, idempotentHint, etc.), the description adds significant behavioral context: it names the upstream service (g:Profiler), notes it's free and requires no API key, explains the return of unmapped loci for detecting namespace mismatches, and describes the significance correction (g:SCS). No contradictions 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.

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

The description is a single paragraph with each sentence contributing essential information. It starts with the core purpose, then immediately differentiates from sibling, explains key parameters, and notes return values. No filler; every sentence earns its place.

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

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

Given the tool's complexity (6 parameters, 1 required, output schema present, extensive annotations), the description covers all essential aspects: purpose, usage context, parameter behavior, service details, return format, and organism defaults. It is fully sufficient for an AI agent to select and invoke the tool correctly.

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

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

Schema coverage is 100% with descriptions per parameter. The description adds value by explaining the role of 'loci' with examples, summarizing default behavior for sources and thresholds, and clarifying the purpose of optional parameters like background. This goes beyond the schema's structural descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it performs GO/KEGG over-representation analysis for a gene list, and explicitly contrasts with the sibling tool 'locus_go_annotations' which handles single loci. The verb 'answers what is my gene SET enriched for?' is specific and distinguishes the tool's purpose.

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

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

The description provides clear guidance by contrasting with locus_go_annotations and contextualizing the tool for differential-expression or co-expression cluster analysis. It could be improved with explicit when-not-to-use scenarios, but the sibling differentiation is effective.

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

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

The annotations already declare readOnly, openWorld, idempotent, and non-destructive hints; the description adds substantial behavior beyond that: homoeologs only under 'all', excluded_categories counts omitted categories, rows carry no taxon unless with_organism/target_organism is set, target_organism filters before the cap, and paralogs are within_species_paralog only. 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.

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

The description is dense but every sentence earns its place: purpose, default behavior, edge cases, output shape, taxon behavior, tool differentiation, and integration. It is front-loaded with the core purpose and does not waffle or restate schema fields.

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

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

Given the tool's complexity, the description is complete: it names the source version, output fields (target_locus + type + gene_tree_id), filter semantics, organism handling, cap ordering, and the key sibling alternative. The presence of an output schema reduces the need to document return details, but the description still gives a clear mental model.

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

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

Schema coverage is 100%, so the baseline is 3, but the description goes well beyond the schema by explaining non-obvious semantics: the default ortholog meaning, homoeolog behavior under 'all', target_organism's pre-cap filtering and organism-adding effect, and with_organism's per-row behavior. This materially improves parameter understanding.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Opens with 'Fetch orthologs and paralogs for a plant locus from Gramene compara (data.gramene.org v69)', which names a specific verb, resource, and data source. The scope is further distinguished from sibling ensembl_plants_paralogs by stating that paralogs here are within_species_paralog only.

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

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

Specifies the default homology_type='ortholog' and exactly when to pass 'paralog' or 'all'. It also names the alternative tool for the excluded case ('ensembl_plants_paralogs lists both') and recommends pairing with resolve_locus_to_uniprot and blast_sequence.

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