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

Goes well beyond the annotations (readOnlyHint=false, destructiveHint=false, idempotentHint=false) by disclosing the side effect: a block, billing failure, 90% spend-cap crossing, recovery or payment-method change on a known cabinet raises an alert to the profile owner. It also pins down unit semantics ('money in the cabinet's currency, whole units') and partial-update behaviour ('cabinets missing from the payload are left untouched'). These are exactly the operational traits an agent cannot infer from the 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?

Front-loads purpose and scope in the first clause, then layers effect and unit semantics. It is dense rather than padded, though the single long paragraph mixes field enumeration, alerting rules and unit conventions, which makes it slightly harder to scan than a short structured form would be.

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 nested, mutation-with-side-effects tool with no output schema, it covers scope, trigger, persistence target, alert conditions and unit conventions — most of what an agent needs. The notable gap is that no return value or acknowledgement shape is described, which matters given there is no output schema to fall back on.

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 only 33%, and the description compensates partially by listing the ad-account fields it consumes (status, disable reason, spend cap, amount spent, billing threshold, balance, daily limit, prepay, country, currency, timezone, payment method, BM) and clarifying that money is whole units in cabinet currency. However, the top-level fb_user and profile parameters — including the per-user vs per-cabinet distinction for restriction — get no treatment in the description, leaving meaningful gaps at this coverage level.

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?

Names a specific verb and resource ('Report the health of every Facebook ad account') and bounds the scope sharply with 'a logged-in FB user can see WITHOUT a Graph token', which separates it from token-based siblings like report_meta_access and report_meta_stats. It also enumerates the exact data points captured, so an agent knows precisely what payload it produces.

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?

States the real-world trigger — 'what the Torvex browser extension sends on its health timer' — and ties it to register_meta_cabinet by noting it lands in the same tokenless profile, which implies sequencing. It does not explicitly say when NOT to call it or name a competing alternative for the same data, so it stops short of full routing guidance.

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