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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, open world). The description adds something the annotations cannot express: 'One lookup from the plan's allowance', which tells the agent this call consumes a metered quota — genuinely useful for cost-aware planning. It does not mention caching, rate limits or pagination behaviour, so not a 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?

Front-loaded with the core purpose, then output fields, then use cases, then the quota note — a sensible priority order with no filler sentences. Slightly dense in the middle run-on enumeration of returned metrics, but every clause earns its place.

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 compensates well by listing the returned metrics and their ranges (difficulty 0-100), so an agent knows what comes back. Parameters and safety are covered by schema and annotations, leaving little an agent needs that is missing.

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 75% and documents limit, language and location including defaults, so the schema carries most of the load. The description's only parameter-relevant detail is 'up to 100 suggestions', which merely echoes the schema's limit maximum, adding no new syntax or constraint information.

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 (keyword ideas around a seed keyword) and enumerates exactly what each result contains — volume, CPC, competition, difficulty 0-100, intent — plus the cap of 100 suggestions. The only gap is that it never distinguishes itself from close siblings like keyword_volume or domain_keywords, so an agent must infer the boundary.

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?

Gives three concrete use cases — building a content plan, finding what to target next to a page, and checking difficulty before writing — which is clear context for when to reach for it. It stops short of naming an alternative tool or an explicit when-not-to-use condition, so it sits below a 5.

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