Send Conversion Event (CAPI)

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

Annotations already declare readOnlyHint=false, so the description correctly aligns with 'Sends' as a write operation — no contradiction. The description adds useful behavior beyond annotations: it discloses that test_event_code 'won't affect production data' and that event_id is 'for deduplication with browser pixel.' However, it omits other behavioral traits an agent might need, such as async processing, the returned event receipt ID, or required authentication. It adds some value but not rich coverage.

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?

The description is a clean one-line purpose statement followed by a compact bullet list of arguments, with required params naturally front-loaded before optional ones. It is appropriately sized (~150 words) for a 10-param tool. Minor waste: the action_source enum is duplicated verbatim from the schema, which adds length without new 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?

Complexity is high (10 params, nested objects, enums, no output schema), and the description documents all required params well. But it omits the response_format parameter entirely, leaves many optional subfields of custom_data and user_data undocumented, and — with no output schema present — never explains the return value. The schema covers gaps for field shapes, but the absence of any return-value note is a real deficiency for a sending tool.

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 100%, so the baseline is 3. The description adds marginal value: it explicitly states the 'at minimum one of' requirement for user_data identifiers, which the schema only loosely implies, and it documents action_source's enum. But it lists only a subset of user_data and custom_data fields (omitting ct, db, fn, ge, ln, st, zp, madid, country, status, contents, predicted_ltv, etc.), so it does not fully compensate or enrich beyond 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?

The first sentence states a specific verb and resource: 'Sends a server-side conversion event to Meta via the Conversions API.' The term 'server-side' and 'CAPI' in the title distinguish it from browser-pixel tracking and sibling tools like meta_send_offline_event (which sends to offline event sets) and meta_test_conversion_events (which tests events). The intent is unambiguous.

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?

No explicit when-to-use or when-not-to-use guidance exists. The description never names alternatives such as meta_test_conversion_events, meta_send_offline_event, or meta_create_event, nor states the conditions that would select one over the other. The 'server-side' phrasing only implies context; an agent has to infer that this is the intended path for CAPI sends rather than being told.

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