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

Annotations already declare readOnlyHint/openWorldHint/idempotentHint, so the safety profile is covered. The description adds real value beyond them: 'live' signals a remote call to Google rather than cached data, and the explicit scoring rule (no service areas, or an area >80 straight-line miles, caps the score) is behavioral context an agent cannot get from structured fields.

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?

Three sentences, front-loaded with the action, then the return contents, then the scoring caveat. No filler, though the long enumerated section list is dense and could be tightened.

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 audit with no output schema, the description adequately previews the return payload (overall score, grade, section scores, recommendations). Minor gap: all three parameters are optional, so it never clarifies how the tool resolves the target location when e.g. only workspace_id is supplied.

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 67% and the description mentions no parameters at all — it does not reinforce the important account_id-vs-location_id guidance (including the warning against the ChIJ Place ID) that the schema text carries. With the schema doing the heavy lifting, baseline 3 applies, but the description contributes nothing here.

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 — 'run a live local-profile audit' for a 'connected Google Business Profile location' — and enumerates the exact outputs (0-100 score, letter grade, per-section scores, recommendations). This clearly separates it from the sibling list_/manage_google_business_* tools, which read or mutate resources rather than compute a scored audit.

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 phrase 'for a connected Google Business Profile location' implies the prerequisite (an already-connected account) but never states when to pick this over list_google_business_locations or manage_google_business_location, nor when not to run it. Usage must be inferred rather than read.

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