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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds meaningful behavior beyond them: drafts are never posted, reviews with existing owner replies are skipped, and fabrication is explicitly forbidden. It does not mention auth requirements, rate limits, or what the returned drafts look like.

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?

Five short sentences, each carrying a distinct constraint, with purpose and the never-posted guarantee front-loaded. Nothing is repeated from the schema or the annotations.

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 no-required-param, no-output-schema tool the critical behavior (drafts not posted, no fabrication, skip already-replied) is covered. The remaining gap is which location identifier to supply when reviews come from Google, which neither the description nor the schema resolves.

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 clarifies the dual source of the reviews parameter (user-pasted vs Google-returned), matching that param's schema text, but says nothing about the undocumented placeId, googleMapsUrl, or restaurantName fields, leaving the agent guessing how to target a restaurant.

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 (draft) and resource (owner replies to reviews), plus the two input sources: reviews the user pasted or that Google returned. No sibling tool touches reviews, so the agent can identify this tool immediately without conflict.

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?

Gives explicit exclusions — skip reviews that already have an owner reply and do not invent reviews — which tell the agent when not to act on a given review. It stops short of naming an alternative tool or stating the top-level triggering condition a user must satisfy.

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