BAR: eFP Expression

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.