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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the description's job is lighter. It adds useful context beyond the annotations: the data is GEO-deposited, represents treatment-vs-control experiments, and serves as evidence for downstream predictions. No behavioral contradiction is present.

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. The core verb, resource, and scope are front-loaded, and the second sentence efficiently lists the available filters. Every clause 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?

For a read-only list tool with annotations covering safety and schema covering pagination defaults, the description is nearly complete: it states what is listed, the experimental design, data source, and connection to herb_experiment_detail. The main gap is the platform/experiment_type naming mismatch, which slightly undermines an otherwise sufficient 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 only 40%, so the description should compensate for the three undocumented filter parameters. It does mention drug_type and species accurately, but it calls experiment_type 'platform' — a term that does not match the actual schema property and could cause an agent to pass a nonexistent parameter. It also adds no meaning to the enum values, making the compensation incomplete and partly misleading.

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 uses a specific verb ('List') and a precise resource ('HERB's transcriptomic experiments'), then clarifies the experimental design ('herb/ingredient treatment vs. control, GEO-deposited'). It also differentiates itself from the sibling herb_experiment_detail by positioning itself as the raw-evidence layer behind differential-expression predictions.

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 context for when this tool is relevant: it lists raw evidence behind predictions that appear in herb_experiment_detail. It stops short of explicitly naming alternatives or saying when not to use it, but the relationship to the detail tool is strong enough to guide selection.

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