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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so safety is covered. The description usefully adds that results come from Google's location catalog and include IDs and types, which matters since there is no output schema. It does not disclose matching behavior (partial vs exact name), result limits, or how the language/country_code parameters affect returned names.

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 front-loaded sentence with no filler: the resource, the searchable entity types, and the return shape are all packed into it. Nothing could be removed without losing information.

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 five-parameter read-only lookup that returns only IDs and types, the description covers the core purpose but omits what the agent needs to interpret results — whether matches are exact, whether results are capped, and how folder vs account scoping changes the catalog searched. Since no output schema exists, the brief return note is helpful but thin.

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 80%, so the baseline is 3 and the schema already documents folder, account, language and country_code. The description only strengthens the meaning of 'query' by clarifying it is a name-based lookup across multiple geographic entity types; it adds nothing about how query, country_code and language interact or whether matching is fuzzy.

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 uses a specific verb ('Search') with a specific resource ('Google's location targets') and enumerates the granularity levels covered (countries, regions, cities, districts, postal codes), plus what is returned (IDs and types). That distinguishes it in substance from siblings like google_ads_find_audiences or google_ads_find_topics, though it never names those siblings explicitly.

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 use case is only implied: an agent can infer this is the lookup step before geo-targeting or radius work, but the description never states when to call it, when not to, or which sibling to use instead (e.g., find_topics for interest targeting). No prerequisites or sequencing are given.

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