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

Goes well beyond the annotations: it discloses server-side normalization and SHA-256 hashing (no plaintext leaves), silent dropping of non-E.164 phone numbers when another identifier is present, asynchronous processing where success only means 'accepted', and batch splitting above 2000 events with submitted_events on partial failure. The annotation set (readOnly=false, destructive=false, openWorld=true) is consistent with a non-destructive write via an external API.

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 usage are front-loaded, then a clearly delimited parameter block, then return/batching semantics. The event-field enumeration is long, but it is dense with required information that the schema lacks, so the length is largely earned rather than bloat.

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?

Despite an output schema existing, the description adds the crucial operational context an agent needs: that a successful response is only an asynchronous acknowledgement, how batching and partial failures behave, and how to verify actual booking. Nothing needed to call this mutation correctly is missing.

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 0%, and the description fully compensates: it documents every event key (click IDs, email/phone with the E.164 rule, address with all four fields required, value+currency, RFC 3339 event_time defaulting to now, event_source values, transaction_id dedup, consent flags for EEA/UK) plus conversion_action, validate_only and workspace. This is more information than the flat schema conveys on its own.

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 and resource ('Lädt Offline-/Enhanced-Conversions an Google Ads via Data Manager API hoch'), and the second sentence scopes it to conversions originating off-site or to enrichment of existing ones. It is clearly distinguishable from reporting siblings like ads_conversion_performance and from ads_list_conversion_actions, which it explicitly names as the ID source.

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?

Explicit when-to-use (CRM closes, phone leads, enhanced conversions with hashed customer data), explicit prerequisite (workspace Google connection with Data-Manager scope), and explicit verification path ('Verbuchung mit ads_conversion_performance prüfen'). It also names a dry-run alternative (validate_only) and the correct retry behavior after partial failure.

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