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

Annotations only declare destructiveHint=true and idempotentHint=false; the description adds substantial behavioral context beyond them: the confirm=false preview vs confirm=true live send, local SHA-256 hashing of email/phone so raw PII never leaves the server, and Meta-side de-duplication via a shared event_id. These are exactly the operational details an agent needs before firing a destructive, non-idempotent 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?

The definition is front-loaded (the core action in the first clause, then identifiers, dedup, action_source, test mode, and confirm), and each line carries a distinct piece of information. It is dense and slightly long, but no sentence is padding.

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-value explanation is correctly omitted, and the description covers the high-stakes behaviors (preview mode, PII handling, dedup, test routing). The remaining gap is the handful of undocumented parameters (account_id, value, currency, event_source_url) in a 15-parameter 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 description coverage is 0%, so the description must compensate, and it largely does: it documents pixel_id's source (list_meta_pixels), event_name values, the 'at least one identifier' rule across email/phone/external_id/fbc/fbp, event_id semantics, the action_source value set, test_event_code, and confirm. It omits account_id, value, currency, and event_source_url, which remain undocumented in both places.

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 description states a specific verb and resource (sends a server-side conversion event to Meta's Conversions API) and immediately frames the scope: off-website/offline sales that browser pixels miss. That is enough to distinguish it from siblings like send_tiktok_conversion_event, upload_offline_conversions, and the various meta_* management tools without opening a schema.

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?

It gives clear when-to-use context (iOS 14+/ad-blocker losses, CRM/phone/showroom/POS sales) and a conditional workflow ('verify first, then send for real' via test_event_code; confirm=false previews). It does not, however, name the sibling tools it should be preferred over (e.g. upload_offline_conversions or upload_meta_leads), leaving that boundary to inference.

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