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

Adds substantial context beyond annotations: staging/activation/budget require 'the exact current human approval'; pause, performance reports and measurement checks require 'their own account grants'; conversions requires a protected human-uploaded batch with batchId/approvalId/fingerprint from a native review. The retry rule ('Reuse request.operationId after uncertainty; never create another staging request to retry a lost response') and the billing note ('spends no generation credits; live advertising is billed by the ad account') are exactly the kind of behavioral detail annotations do not convey. Consistent with destructiveHint=true and idempotentHint=true.

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?

Sentences are individually informative with little filler, and the approval/retry rules are front-loaded. However it is an undifferentiated wall of equal-weight sentences mixing safety rules, per-action routing, and billing notes, with no structure for a 15-variant dispatcher, and the first sentence largely restates the title.

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?

An output schema exists, so return values need not be described, and the safety/permission/retry posture is covered well. But for a tool whose complexity is the breadth of the action enum, the description documents only a subset of variants and omits the lead, catalog, and audience action families entirely, which is a material gap for correct selection.

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% over a large nested discriminated union, so description must compensate and it only partly does. It explains operationId's retry semantics, destinationId's optionality, and the provenance of batchId/approvalId/fingerprint, but says nothing about work_id, accountId, request_key, or how required fields differ across the 15 action variants — leaving most variant-specific parameter meaning to the schema.

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 concrete resource (advertiser actions) and enumerates several of the dispatched actions (staging/activation/budget, pause, report, measurement, studies, conversions, conversion_destinations), which goes beyond the title. However the opening verb 'Accept' is imprecise for a gateway that executes actions, and roughly a third of the schema's action variants (lead_collect, lead_forms, lead_form_change, engagement_sources, catalogs, audiences, audience_change) are never named, so an agent cannot fully map purpose to the full action space.

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?

Gives real routing guidance for a few actions: 'Use action measurement to refresh this advertiser's pixels', 'Use action studies for bounded Meta platform-study reads', 'Use conversion_destinations to refresh a pixel list'. It also states negative scope for studies ('does not create a study or change allocation') and conversions ('never accepts raw event data'). But there is no guidance for when to use this tool versus the obvious siblings native.genads_ad_operation, native.genads_read_measurement, native.genads_read_studies, or native.genads_conversion_destinations, and no when-not-to-use conditions beyond the two negatives.

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