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

Annotations already declare it as a non-read-only, non-idempotent, open-world write, so the description isn't carrying the safety burden alone. It adds genuinely useful behavior beyond that: 'confirm=false = preview' discloses a dry-run mode, and it explains that a destination URL is mandatory in sales/leads campaigns. It does not mention the PAUSED default state or permission/auth requirements.

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 core identity is front-loaded in the first clause, followed by the object_story_id mechanics and then the link/cta behavior. It is dense but each paragraph earns its place; the Ads Manager analogy is slightly verbose but aids interpretation rather than 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 values need no explanation here. For an 8-parameter write tool with zero schema descriptions, the description covers the identity, the prerequisite lookup, the object_story_id construction, the link/cta interaction, and the preview switch — everything an agent needs to invoke it correctly.

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 does well for the hardest parameters: object_story_id format ('{page_id}_{post_id}'), the link + cta_type pairing with an example enum value, and confirm. But account_id, adset_id, name, and status (default PAUSED) are never addressed, leaving roughly half the parameters undocumented anywhere.

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 names a specific verb and resource ('Turns an existing Facebook/Instagram Page post into an ad (boosts an organic post)'), which immediately distinguishes it from siblings like create_meta_link_ad, create_meta_carousel_ad, and create_meta_dynamic_ad that build ads from scratch. It also clarifies the organic-post origin, which is the key differentiator among the many create_meta_* tools.

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 supplies a concrete prerequisite path ('found via list_meta_page_posts') and explains the condition under which link/cta_type matter versus leaving them empty. What is missing is explicit guidance on when to pick this tool over create_meta_instagram_post_ad or create_meta_link_ad, so it stops short of a full 5.

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