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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint, so the safety profile is fully covered. The description does add useful non-annotation context: the display-name pipe format and the account_id default behavior. It does not mention rate limits or result caps, so it is solid but not rich beyond annotations.

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 purpose and purpose-linkage, then a concrete example, then filters and defaults. Dense but every clause carries information; the trailing 'Read-only.' is redundant with readOnlyHint and slightly wasteful.

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?

An output schema exists, so return-shape explanation is optional, yet the description still gives the example result shape, covering the critical id extraction. The only real gap is the undocumented customer_id and limit parameters, which is minor for a lookup tool.

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 0%, so the description must carry parameter meaning, and it largely does: query semantics, the full location_type enum (Country|State|City|County|MetroArea|PostalCode), and account_id's empty-string fallback. customer_id and the limit default are never explained, leaving two of five parameters undocumented.

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 and resource ('Searches Microsoft/Bing Advertising GEOGRAPHIC LOCATIONS by name') and immediately gives the downstream purpose: returning LocationIds required by add_microsoft_location_target. This distinguishes it from geo_target_search (Google) and tiktok_region_search (TikTok) without opening any 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?

Explicitly ties the tool to its consumer ('required by add_microsoft_location_target') and explains the optional account_id fallback, which is real routing guidance. It stops short of stating when to prefer this over a sibling lookup, but the platform prefix makes the alternative unambiguous in practice.

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