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

Beyond the readOnly/idempotent annotations, the description discloses the cost model ('billed per started block of 10 keywords that have data') and the partial-failure contract (no-data keywords are returned in noData and not charged). These are operational facts an agent cannot infer from structured fields and directly affect batching decisions.

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 packed sentences with no filler, front-loaded with the returned metrics, then constraints, then billing/exclusions. Every clause carries information an agent would otherwise have to guess.

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?

There is no output schema, and the description compensates by enumerating the returned metric fields. It never states whether results are keyed per keyword or the shape of the noData list, a minor residual gap for a tool with no output schema.

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 country, language and keyword formats are already documented in the schema with defaults and the 1-100 bound. The description restates the 100-keyword/one-country constraint but adds no syntax or format detail beyond it, making the schema baseline of 3 appropriate.

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+resource: returns Google search volume, CPC, competition, keyword difficulty (with its 0-100 scale), search intent and 12 months of volume. That is far more specific than siblings such as domain_overview or ranked_keywords, so an agent can tell which tool produces keyword-level metrics without opening the schema.

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 gives usable context: up to 100 keywords, one country per call, and what happens to keywords lacking data. It does not name an alternative tool or state when a sibling should be preferred, so it stops short of explicit routing guidance.

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