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

Annotations already declare read-only, idempotent and non-destructive behavior, so the safety profile is covered. The description goes well beyond them by defining settled vs confirmed, the denominator rule, the three-install reporting threshold, the dating of scoped totals, and the [?] convention for unknown values. What it does not disclose is anything about result volume or how large a response can be for all-zones queries.

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 purpose is front-loaded, but the middle section is dense with compressed jargon ('settled over expected, with confirmed over expected beside it', 'come separately dated and measured') that takes effort to parse. Several clauses about output formatting could be tightened for a tool with only two optional parameters.

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 no output schema, the description carries the burden of explaining return semantics, and it does so for the metric definitions, unknown handling, and data dating. It is still unclear what the overall response shape looks like (whether zone/type breakdowns are nested or flat), which leaves a gap for a reporting 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 100%: both parameters carry descriptions and the type enum is fully enumerated, so the schema already does the explanatory work. The description adds no syntax or semantics beyond the schema for 'zone' or 'type' (the 'per field' dimension has no corresponding parameter). Baseline 3 applies when the schema carries the load.

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 ('Counts how much of WoW: Forever's database is settled or confirmed') plus the exact dimensions of aggregation (per zone, per type, per field). It also explicitly separates itself from the entity/page tools at the end, so an agent can tell it is a metrics tool rather than a fact lookup.

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?

'Use it for how complete the database is for a zone or type; use the page tools for the facts themselves' gives a clear when-to-use and a contrasting alternative. The alternative is named as a category ('page tools') rather than a specific sibling, so routing is slightly less precise than it could be.

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