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

Annotations already cover read-only, idempotent, open-world and non-destructive behavior, so the bar is lower. The description still adds real context: it pages through all reviews rather than the first 50, returns full untruncated text plus dates and per-location totals, and flags the Place ID as output-only. It stops short of describing permission requirements or rate limits.

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 dense sentences, front-loaded with the resource and the default view, then the alternate view and its output-only caveat. Every clause carries information an agent needs, with no filler.

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?

Given eight parameters, two views, no output schema and read-only annotations, the description covers the return contents, paging strategy, filtering, the review_name handoff and the Place ID trap. An agent has what it needs to call this correctly without guessing.

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?

With 88% schema coverage the schema already documents most parameters, but the description adds useful semantics: rating and unanswered are filters on the reviews view, limit/offset page through large result sets, and review_name is the handle for the reply/delete tool. That goes beyond restating 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 Business Profile reviews) and clearly splits it into two behaviors, view=reviews and view=review_link, so an agent can tell them apart immediately. It also names the sibling manage_google_business_review as the mutation path.

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 explicit routing rules: default view=reviews for listing with filtering and paging, view=review_link when an account_id or location_id is supplied to get the public review link and Place ID. It also states the exclusion that the ChIJ Place ID must NOT be fed back as location_id, and points reply/delete to manage_google_business_review.

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