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

Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds genuinely new behavior beyond that: the data source is the owner's own Search Console, the window is the prior week, missing searches mean no impressions yet, and it reports explicitly when Google is unconnected or the site unverified. Return format is undescribed, but no output schema exists to cover it either.

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?

Three sentences, front-loaded with the actual answer (where the site ranked last week) before the caveats. The 'change from the week before' phrase slightly duplicates 'last week,' and 'A search that is not listed has not shown the site yet' is wordier than needed, but nothing is padding.

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?

For a zero-parameter, read-only report with no output schema, the description covers source, time window, meaning of gaps, and failure states — enough to call it correctly. The one material omission is sibling disambiguation against check_google_positions, which is the most likely misselection risk here.

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 tool takes zero parameters and the schema is an empty closed object, so there is nothing for the description to disambiguate. The only plausible semantic question — what time range is covered — is answered as 'last week,' which is the right kind of addition for a no-argument tool.

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 names a concrete resource and scope: Google search positions for the website, for last week, sourced from the owner's Search Console, with each search's place and week-over-week change. That is far more specific than the title. However, it never distinguishes itself from the near-identically named sibling check_google_positions, so an agent still has to guess which one to call.

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 ('where the website showed on Google last week') but names no alternatives and gives no when-to-use versus when-not guidance. It does supply useful edge-case context — how to read an absent search and the not-connected/not-verified conditions — but routing between this and check_google_positions or find_searches is left to inference.

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