data_health_radar

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

Annotations already declare readOnlyHint=true. The description adds meaningful context: schema_stability is omitted when fewer than 2 history snapshots, and runtime_coverage is an optional 7th axis that appears when traces are ingested. This discloses conditional behavior beyond the read-only hint, though it doesn't delve into other edge cases.

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 purpose, axes, and output format. The closing clause 'Mirrors jcm's six-axis health radar' adds little value and is slightly extraneous, but the rest is efficient and well-structured.

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 no output schema, the description adequately specifies return values (scores, composite, grade) and conditional axes. It also explains the optional runtime axis and pairing with diff tool. The main missing piece is the dataset parameter semantics, but overall it is sufficient for a read-only health 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 covers two of three parameters (window_days, include_runtime) with descriptions, giving 67% coverage. The description itself does not elaborate on parameters. The required 'dataset' parameter lacks any description in both schema and tool description, leaving an important 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?

The description clearly specifies it is a 'six-axis health radar' for a dataset, names all six axes, and explicitly states the output format (0-100 scores per axis plus composite and A-F grade). It distinguishes from sibling diff_data_health_radar by noting the pairing, and from other health tools like get_dataset_health by its multi-axis scope.

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 mentions pairing with diff_data_health_radar for snapshot deltas, implying this tool is for current health snapshots. However, it does not explicitly state when not to use it or compare with alternative health tools like get_dataset_health, so it stops short of full when/when-not guidance.

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