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

Annotations already declare readOnlyHint/idempotent/destructive=false, so the "nothing is ever changed in Meta" sentence is reinforcement rather than new information. The genuinely additive disclosures are the ordering guarantee ("most urgent first") and the unit conventions (amounts in hundredths of the ad account currency, rates as fractions), which the annotations cannot convey.

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?

One front-loaded sentence establishes the question being answered, then the issue list, then the unit and safety notes. The long enumeration is dense but every clause names a distinct detectable issue, so it earns its length; the unit/read-only tail could have been 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?

With no output schema, the description carries the burden of describing returns and does so by enumerating issue categories plus amount/rate encoding, which is what an agent needs to interpret results. It stops short of describing result shape or volume (per-ad rows? grouped?), a minor residual gap for a 4-parameter diagnostic 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?

Schema description coverage is 100% – app, range, source, and environment are all documented in the schema, including the range enum semantics and the default Meta ad account. The description adds nothing parameter-specific (e.g., how range interacts with issue detection), 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?

Opens with a specific framing ("What needs attention in a Meta ad account") and enumerates the exact issue classes it surfaces: rejected/limited ads, stuck review, learning-limited ad sets, excluded placements spending, spend without clicks, fatigue, under-delivery, pixel signal, bot-like visits. This clearly separates it from metric-oriented siblings like get_meta_ads_overview, get_meta_ads_breakdowns, and list_meta_ads without needing to name them.

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 use case (account health triage, ordered by urgency) is strongly implied by the content, but the description never states when to pick this over get_meta_ads_overview or list_meta_ads, and gives no exclusions or prerequisites. An agent can infer the intent but must reason about alternatives itself.

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