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

Annotations only declare it as a safe idempotent read; the description goes well beyond that, disclosing that metrics have different units and must never be summed, that fetches require server reporting (fetches_unavailable -> 0), that robots.txt/llms.txt/sitemaps aren't fetches, that scanner probes for secrets are excluded, how unconfirmed fetchers behave, and how partial/today-inclusive ranges distort readings.

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?

Almost every clause carries real semantic content, but there is no front-loaded lead sentence and the whole thing is a semicolon-chained block of jargon ('unconfirmed', '*_change') that forces the reader to reverse-engineer the tool's purpose. Informationally dense but structurally poor.

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 takes on responsibility for explaining return fields and largely does so (answer_fetches, search_crawler_requests, visitors, unconfirmed, *_change with null comparability). What it never conveys is the result shape (per-assistant rows? totals?) or whether assistants with zero traffic appear, leaving a meaningful 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?

With 100% schema coverage the baseline is 3, and the description earns more by adding semantics the schema lacks: dates are the project's calendar days (timezone via get_project) while timestamps are UTC, omitting both yields the last 28 complete days, and a range including today reads as a drop. It does not add anything about the 'project' parameter beyond the schema.

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 never states a verb or framing sentence such as 'lists AI assistant traffic metrics per assistant'; the purpose must be inferred from the colon-led enumeration of answer_fetches/search_crawler_requests/visitors. It does partially differentiate from the sibling list_sources by saying visitors are 'list_sources rows in source_keys', which helps separate the two tools.

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?

There is no explicit guidance on when to call this versus alternatives like list_sources or get_overview, nor any when-not guidance. The only usage-ish instruction ('Omit from/to for the last 28 complete days') is about parameter defaults, not tool selection.

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