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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds context about returned fields and the owner-reply status, which hints at the tool's relevance for response workflows. However, it doesn't disclose pagination behavior, rate limits, or whether 'recent' has a specific definition (e.g., last 30 days). With annotations covering safety, this is adequate but not rich.

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?

Two tightly written sentences that front-load the resource and fields, then the use case. No wasted words, though the field list could be slightly compressed.

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 read-only listing tool with annotations covering safety, the description is mostly complete: it states what's returned and a primary use case. However, it omits pagination behavior, what 'recent' means, and any output format details (though no output schema exists). Given the complexity of review data, this leaves the agent with gaps about scope and volume.

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 50%. The description doesn't explain the 'limit' parameter (default 25, max 50) or add meaning to 'gbp_location_id' beyond the schema's note 'From gbp_list_locations'. Since the schema documents both parameters (one with description), and the description doesn't compensate for the gap, baseline 3 is appropriate.

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 clearly states the resource (reviews for one Business Profile location) and the specific fields returned (rating, text, reviewer, owner reply status). It distinguishes itself from gbp_posts and gbp_reply_review by being a listing tool, though it could more explicitly differentiate from those siblings.

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 description gives a clear use case: 'Use it to find reviews waiting on a reply.' This implies the tool is for triage, naturally routing to gbp_reply_review for the actual reply action. However, it doesn't explicitly name alternatives or when not to use it (e.g., no guidance on pagination limits or date filtering).

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