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

The description adds genuinely useful behavior beyond the schema: customer records are never exposed to chat/tools, a human uploads and attests consent, and counts are not matched members. However, it does not reconcile its "read safe metadata" framing with annotations declaring readOnlyHint=false and destructiveHint=true — an agent sees a read-shaped tool flagged as able to destroy data and gets no explanation of what state is actually touched.

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?

Purpose and return fields are front-loaded, then privacy, consent, usage, and the counts caveat follow in a tight four-sentence block. Dense but every sentence carries information; only the approval sentence is slightly oblique about whose approval and where it happens.

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 shape need not be restated, and the privacy/consent/approval semantics are well covered. Still missing for a 6-parameter, nested-object tool: pagination behavior for `after`, what a valid batch reference looks like, and any reconciliation of the destructive/openWorld annotations with an operation described purely as a read.

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 50%, and the uncovered parameters are the substantive ones: work_id, request_key, and the nested arguments.account_id / arguments.after. The description mentions no parameter names, gives no hint that `after` is a pagination cursor, and does not explain how a batch reference maps to the required arguments object.

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?

The first sentence gives a specific verb (read) and resource (protected customer batch metadata) and enumerates exactly what is returned: selected audience, counts, consent expiry, revocation. It implicitly separates this from raw customer data, but it never names a sibling (e.g. genads_audience_review, genads_conversion_batches) as the alternative, so differentiation relies on the reader inferring it.

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?

"Use an available batch reference in an append_customers plan; the exact change still needs human approval" gives concrete situational context: this is a lookup feeding a downstream plan, and approval is not conveyed by the read. It stops short of explicit when-not conditions or named alternatives among the ~250 siblings.

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