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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered. The description adds meaningful context beyond that: counts are scoped to the given countries/language or worldwide by default, results are returned as structured content, and calls consume no Adrails credits — useful for an agent deciding whether to spend a call. It omits result-size limits and pagination behavior.

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?

The core is front-loaded and mode-driven in two dense clauses with no wasted phrasing. The trailing MCP boilerplate and the 'Free: ... no Adrails credits' line are somewhat mechanical, but the latter carries real decision value, so the text remains efficient overall.

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 must convey what comes back, and it does: for each mode it states the returned figures and ordering ('most searched first'). Combined with the declared scoping defaults and the read-only guarantee, an agent has enough to call this correctly.

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% and the description still adds real meaning: 'mode' semantics are explained per value, 'url' is tied to the ideas mode as an https page of the site, and countries/language are described as falling back to 'everywhere' when omitted — a default the schema doesn't state. It doesn't cover the keyword array limits (200 items, 80 chars), but those are documented in the schema itself.

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 verb and resource ('Reads Google's Keyword Planner for a Google Ads account') and then defines both operating modes with what each returns: monthly search volume plus top-of-page bid range for 'volumes', and keyword suggestions from seed words or a page URL for 'ideas'. This is far more specific than any sibling ('google_ads_library', 'targeting_options') and lets an agent know exactly which tool produces real search-volume data.

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?

It gives a clear use case ('choose a search campaign's keywords on real searches rather than guesses') and implicitly tells the agent which mode to pick based on whether it has seed keywords or a URL. It stops short of naming an alternative sibling tool or stating when not to use it, so it falls just below the explicit when/when-not/alternative bar.

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