clinical_trials_field_sizes

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 agent knows it's a safe, non-destructive operation. The description adds that it shows min/max/top sizes, but the return format is unspecified (no output schema, no mention of JSON structure), and the default behavior when 'fields' is omitted is only vaguely implied (probably returns stats for all fields). It doesn't disclose pagination, aggregation behavior, or potential performance implications (e.g., scanning large dataset). Since annotations already cover safety, a 2 acknowledges the description's added value but notes missing behavioral details.

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 and front-loads the core purpose ('Get statistics on list/array field sizes') before giving examples. It earns its place by clarifying what 'field sizes' means (min/max/top) and examples of array fields. It could be slightly more concise by trimming 'in the ClinicalTrials.gov database' since the tool name already implies that, but the redundancy is minor.

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 simple interface (one optional param, no output schema, annotations indicating read-only and idempotent), the description covers the core semantics: what the tool computes and that it is useful for data distribution. However, it lacks details about the returned structure (e.g., in what format are the stats returned?), defaults for omitted 'fields' beyond what schema says (e.g., does it return all fields? how many?), and interaction with the sibling clinical_trials_size_stats. Since output schema is absent, the description should have explained return values more clearly. This is a moderate gap.

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's 'fields' parameter already has a description: 'Pipe-separated field names: 'Phase|Condition|InterventionName'. Omit for all.' This covers semantics fully (schema_description_coverage=100%). The tool description gives examples of fields and reinforces the purpose, but doesn't add meaning beyond the schema. Per the rubric, with full schema coverage, a 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 clearly identifies a specific verb ('Get statistics'), a resource ('list/array field sizes in the ClinicalTrials.gov database'), and names example fields (Condition, Intervention, Phase). It distinguishes itself from siblings like clinical_trials_field_values (which likely returns field values rather than size statistics) and clinical_trials_size_stats (which may also be related, though ambiguous). Differentiation from clinical_trials_size_stats is weaker because that sibling name could be synonymous with field sizes, so it doesn't fully distinguish from all 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 implies usage for understanding data distribution, but does not explicitly state when to use this tool versus alternatives. It does not mention any exclusions or alternatives like clinical_trials_size_stats or clinical_trials_field_values. The openWorldHint and readOnlyHint annotations give some sense of safe usage, but no direct guidance on when to prefer this tool. A clear context is provided ('for understanding data distribution'), but no 'use X instead' condition.

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