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

Annotations already cover safety (readOnly, idempotent, non-destructive), and the description adds real context: the per-area ok/warning/critical rating scheme, the top-actions output, and the fixed lookback windows (30/28 days). 'Reads only' largely repeats readOnlyHint, but the output-shape disclosure is genuinely additive since no output schema exists.

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?

Front-loaded with the deliverable and organized as a readable inventory of checks grouped by platform, so each clause carries information. It is long, but the density is justified by the four-source scope rather than padding.

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?

With no output schema, the description usefully documents the returned scorecard structure and rating vocabulary, and the single input is fully covered by the schema. Minor remaining gap is the unspecified client identifier format, but otherwise complete for a read-only aggregate tool.

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?

One parameter at 100% schema description coverage, where the schema already specifies 'Client name from list_clients'. The description only implies a single client ('one client') and adds no naming, format, or sourcing detail beyond the schema, so baseline 3 applies.

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 ('Audit one client and return a scorecard') and enumerates exactly what is checked across four data sources with their date windows. An agent can distinguish this from the granular ads_*/ga4_*/gsc_* siblings immediately.

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?

Explicit when-to-use: 'Use for a new client, or when asked what to fix first.' It also implies the handoff to apply_audit_fixes via 'the tool that makes each fix', though it does not name that sibling directly, so the routing is clear but not fully explicit.

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