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

Annotations already cover the safety profile (readOnlyHint, idempotentHint, openWorldHint, non-destructive), so the bar is lower. The description still contributes the important operational facts: results are normalized 0-100, an average per keyword is returned, and the call is billed when data is returned — a cost signal agents need before invoking. It stops short of noting rate limits or how sparse/short time ranges behave.

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?

A single sentence packs scope, scale, dimensions and the billing caveat with no filler. The primary capability (interest over time) is front-loaded before search-surface and output details.

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 carries the return shape (0-100 series plus per-keyword averages), which is exactly what is needed. Defaults for country, time_range and search_type live in the schema, so omitting them here is acceptable. Minor gap: no mention of how the series is sampled or truncated for short time ranges.

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 coverage is 75%, so most parameters are already documented. The description adds meaning the schema does not: the 0-100 normalization, the effect of comparing several keywords on a shared scale, and the average-per-keyword output. Keywords' max of 5 is restated from the schema, and time_range granularity is left entirely to 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 names a specific resource (Google Trends interest-over-time series, 0-100 scale) and its scope (up to 5 keywords, country or worldwide, five search surfaces, plus per-keyword averages). The verb is implicit ('interest over time') but the resource is unmistakable and distinct from siblings like keyword_metrics or google_serp. It does not call out those alternatives by name, keeping it 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?

Usage is implied: comparing relative search interest across up to 5 terms in a market. The description gives no explicit when-to-use versus keyword_metrics (absolute volume) or google_serp, and no prerequisites or exclusions. Adequate for an agent that can infer relative-interest comparisons, but routing between this and keyword_metrics is left to guesswork.

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