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

Adds real behavior beyond the annotations: tokenless ingestion from a logged-in Ads Manager session, overwrite rule for a (campaign, day) pair, and that spend is informational only. The overwrite semantics sit in mild tension with idempotentHint=false, though 'set to the latest report' could still mean a new row each call, so this reads as ambiguity rather than contradiction. It does not say what the call returns or how partial/invalid rows behave.

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?

Core purpose is front-loaded, but the description is a dense two-sentence run-on with heavy noun stacking ('the campaign list's network cells ... read them for tracker campaigns linked to those FB campaigns'), which costs parseability. Every clause carries some information, but the delivery could be split into clearer statements.

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 writing tool with a nested 5000-row array, no output schema, and only 50% schema coverage, the description covers data source and downstream consumers well but omits return shape, batching expectations, and what happens for unknown campaign ids or malformed rows. Adequate, with clear gaps for an agent invoking it the first time.

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 50%; the description enumerates the metric fields carried in rows and clarifies that actions is the raw Graph list and spend is not used for click costs. It adds no guidance on fb_user as profile key, currency handling, or the 5000-row / 60-action batch limits, so it only partially compensates for the coverage gap.

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 with explicit scope: reports one FB ad account's campaign-level daily metrics (impressions, reach, clicks, link clicks, spend, raw actions) per campaign and day. The 'campaign-level' and 'per FB campaign and day' qualifiers distinguish it from the ad-level and adset-level siblings (report_meta_ad_stats, report_meta_adsets) without needing to open a schema.

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?

Explains the operational context (what the Torvex browser extension reads on every cost sync, where the data lands) and routes the agent away from it for cost purposes: 'spend here is informational — click costs come from import_meta_costs.' That is a genuine alternative-selection signal. What's missing is an explicit prerequisite ordering vs. register_meta_cabinet (it only says the data lands under the same profile).

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