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

Annotations only say this is a non-readonly, non-destructive, non-idempotent write; the description goes far beyond by disclosing the 100-item cap, the transaction_id idempotency model per click + type, the three duplicate policies, the reclassified_from upsell behavior, and the full per-item result vocabulary (created/updated/duplicate/blocked/not_found/error). This is exactly the context an agent needs before making an irreversible booking call.

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 operation and scale, then zooming into idempotency, then results — a sensible order with no filler sentences. The duplicate-policy sentence is a dense stack of parentheses and internal references (Tracker → Conversion types) that costs a re-read, but every clause carries information.

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 batch mutation with no output schema, the description supplies the return contract via the per-item status list, which is the main thing an agent would otherwise be blind to. Combined with the idempotency and duplicate handling, that covers what is needed to call this correctly; missing auth/permission notes are the only remaining gap.

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 67%, and the description adds real meaning on top of it: transaction_id is framed as the idempotency key whose presence bypasses one-per-click dedupe, and the duplicate-policy branch explains what happens when it is omitted. It does not add anything for fire_pixels / fire_postbacks beyond the schema, and only alludes to event validity rather than covering payout, currency or created_at.

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?

"Import up to 100 conversions by click_id, exactly as if the affiliate network had postbacked them" gives a specific verb, resource, batch bound and key field, so the operation is unmistakable. It does not name the sibling it competes with (reconcile_conversions, or the separate import_google_costs / import_meta_costs flows), so routing between them is left to inference.

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?

The description implies the right context by explaining repeat semantics and the duplicate policy, which effectively tells the agent how to control re-booking behavior. It never states when to use this tool rather than reconcile_conversions or a postback path, and gives no prerequisites (click must exist, click must be within backdate window) as explicit usage conditions.

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