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

Annotations already cover readOnly/idempotent/openWorld, yet the description still adds real behavior: findings are ordered failures-first by severity rather than impact, some findings carry a fixing call, and page-speed analysis only runs with consent against the busiest landing pages in the Chrome UX Report. It also flags the get_org_context prerequisite, which is genuinely useful routing context.

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?

It is short, but the telegraphic fragments ("quick scores three, month-to-date", "Failures first, by severity, not impact") read as compressed notes and require re-parsing. The trailing "Tools revision: d80f65c0" is noise that earns no place in a tool description.

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 seven-parameter read-only audit with an output schema, the description covers the essentials: mode semantics, check targeting, result ordering, consent-gated page-speed behavior, and the account-context prerequisite. The remaining gap is the undocumented max_findings/render/days controls, which leaves result-sizing behavior to guesswork.

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 description coverage is 0%, so the description must carry the load, and it only partially does: depth, detail, and sections are given real meaning (including the non-obvious rule that named checks require detail=full). days, max_findings, and render are never explained, and "month-to-date" is ambiguous against the days parameter whose default is 30.

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?

Opens with a specific verb+resource ("Account audit") and enumerates the two modes with concrete scope (deep = 75 checks, quick = 3 checks month-to-date), so an agent knows exactly what it gets. It never names the nearest siblings (account_health_score, bidding_audit, conversion_setup_audit), so the boundary between a full audit and those focused audits must be inferred.

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 does explain mode selection (deep is the default, quick is a shallow three-check pass) and a targeting pattern for named checks ("one call with their sections, detail full"). But there is no when-not-to-use guidance and no pointer to the narrower audit siblings an agent should prefer when only bidding or conversion setup is in question.

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