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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the description's "no writes" is largely redundant. It does add genuine behavior beyond the annotations — pagination, inclusion of campaigns with no findings, retention of intentional traffic and intermediate goals, and a hard cap of three priorities — but the dense constraint list is about output policy rather than what the agent will actually receive.

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?

Purpose and the responseMode distinction are front-loaded, but the middle is a single overstuffed run-on listing provider issues, policy differences, hypotheses, unknowns, CPA, pause durations and QA purposes. Every clause is a real constraint, yet the wall-of-text delivery makes it hard for an agent to prioritize which rules 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 complex, no-output-schema advisory tool this covers scope, inclusion rules, prioritization cap, pagination and the two response modes. The remaining gap is the mismatch between the documented parameters and those actually declared in the schema, which the description never reconciles.

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 75%, so the baseline is 3. The description reinforces responseMode semantics with concrete deliverable examples (creative brief, executable plan) and mentions pagination, but says nothing about limit, offset, language, or the oddly documented top-level accountIds/userStatement/idempotencyKey fields.

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?

The description opens with a specific verb-plus-scope: advises across selected accounts and campaigns after an audit, drawing on campaign objectives, ad set events, budget ownership and evaluated rules, and synthesizing at most three priorities. That is far more specific than the title, though it never names a sibling (performance_diagnose, business_review, findings_review) to distinguish itself from.

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 sets a clear precondition ("after an audit") and gives explicit routing on responseMode: answer for a report, evidence only for an explicitly requested additional deliverable. The schema's own responseMode description also does load-bearing work here; the description lacks any stated when-not-to-use relative to sibling diagnosis or review tools.

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