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

Goes well beyond the annotations: it discloses that a run consumes ad-hoc run credits (plus grid credits for Local Search Grid), that runs stop after a trial ends, that precondition failures are refused with a reason, and that the run is asynchronous, taking minutes. It does not address the non-idempotent/repeat-call consequence (each call spending another credit) or what the destructiveHint means for existing report data.

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?

The prerequisite and cost information is front-loaded and dense, but the opening two sentences are near-duplicates ('Run... now, as the Re-run button does' vs 'Starts a manual run... as the Re-run button does'), so the lead wastes space on restatement before getting to the constraints that actually matter.

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 non-idempotent, credit-consuming trigger with no output schema, the description covers cost, gating conditions, failure mode, and latency, and tells the agent to fetch the report separately afterwards. The remaining gap is what the call itself returns (e.g., a run identifier or confirmation) so the agent knows what to do between triggering and reading.

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 100% and both parameters are documented in-schema, so the baseline is 3. The description adds some meaning by tying specific report_type values to prerequisites, but adds nothing about location_id or the remaining enum values beyond what the schema already conveys.

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?

Specific verb plus resource: 'Run one of a location's reports now' / 'Starts a manual run of the location's report of that type.' It distinguishes itself from the get_*_report siblings by making clear this triggers a new run rather than fetching results, though the 'as the Re-run button does' clause is stated twice without adding information.

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 concrete preconditions per report type (local_search_grid and gbp_audit need a Google Business Profile, reputation_manager needs the Grow plan) and notes the call is refused with a reason otherwise. It also implies the follow-up path with 'read the report afterwards,' but never names the get_*_report sibling that should be used to retrieve results.

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