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

Goes well beyond the annotations by disclosing write semantics ('A (ad, day) is set to the latest report'), the destination table (ad_daily_stats), currency of the spend value, and the downstream consumers (Creatives library stats, burnout check using reach-derived frequency). The upsert-on-key behavior sits in mild tension with idempotentHint=false but does not contradict it. Return shape and error handling are not described.

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-loaded with the core purpose, then mechanism, then side effects — a sensible order, and three sentences for a fairly complex tool is efficient. Some clauses are dense with internal vocabulary ('Torvex browser extension', 'Meta → Ads burnout check', 'cabinet') that an outside agent may not parse, but there is no filler.

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 write tool with no output schema, the definition covers what an agent needs: what data to supply, the keying rule on write, currency interpretation, and downstream impact. Missing batch-limit and error details are minor given the schema's maxItems and the fact that this is normally invoked programmatically.

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?

With only 33% schema description coverage, the description carries real weight: it enumerates the row fields, establishes the (ad, day) composite key, and supplies the missing semantics for 'spend' (cabinet currency) and 'reach' (source of derived frequency) that the schema leaves bare. It says nothing about fb_user beyond the schema and does not mention the 5,000-row cap.

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?

Specific verb and resource: report a single ad account's AD-level daily delivery (impressions, link clicks, spend, reach per ad and day) without a Graph token. The 'WITHOUT a Graph token' and 'read by the browser extension' framing makes the mechanism clear. It never names report_meta_ads or report_meta_stats, so an agent must infer how this differs from those closely named siblings.

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?

Usage is implied rather than stated: it is the ingestion path used when no Graph token exists, filling the same ad_daily_stats store as the Graph cost sync. There is no explicit 'use this when…, use import_meta_costs instead when you have a token' routing, and no prerequisites or exclusions, leaving the agent to infer the branch.

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