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

Annotations already declare readOnly/idempotent/non-destructive/closed-world, so the bar is lower, yet the description adds substantial behavioral context: the caveat/rule mechanism that governs the figures, a hard cap of 5 findings per kind with the remainder counted, the distinction between 'checked' (nothing found) and 'skipped' (could not be evaluated), and the new_means lookback definition. It does not explain pagination or how to interpret an empty finding set beyond 'checked', so it falls short of 5.

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?

Word count is low for the amount of content, but it is delivered as one dense, telegraphic block ('at most 5 a kind, unlisted counting the rest', 'checked lists the kinds looked for that found nothing'). Operationally critical facts, such as the default range of 7 whole days to yesterday, are buried mid-paragraph rather than front-loaded, which hurts scanability.

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 return-value burden and largely does: it describes the shape of a finding (its kind, what it says, its figures, the filter/dashboard link) plus the checked/skipped lists and the rule/caveat envelope. For a fairly complex, rule-driven tool that is close to complete, though it leaves the failure/empty-result case only partly specified.

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 description coverage is 100%, so the baseline is 3. The description adds a little: it points the agent to get_site_summary for range semantics and explicitly states the tool 'takes no filters', which usefully rules out filter parameters. The date/range parameters themselves gain no syntax or behavior detail beyond what the schema already documents.

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 opening sentence names a specific verb and resource: what changed on a site, computed against the preceding period, ranked by urgency, and it enumerates the concrete finding types (server errors, goals no longer reached, slow pages, new sources). This is far more than a restatement of the name. It stops short of naming a sibling (e.g. explain_change or get_overview) to distinguish itself from, so it lands at 4 rather than 5.

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 what is new, what is wrong or what to look at' implies the investigative/anomaly use case but never states when NOT to use it or which sibling (explain_change, get_overview, get_site_summary) answers a different question. Usage is inferable but not explicit, and no alternatives are offered.

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