Skip to main content
Glama

meta_ads_lead_forms_duplicate

Copy a Meta lead form's questions, privacy policy, thank-you page and settings into a new form on the same or another Page, then get the new form ID back.

Instructions

Duplicates a lead form under the same (or another) Page. Meta has no native copy endpoint, so this fetches the source form's questions, privacy_policy, follow_up_action_url, locale, context_card, thank_you_page, is_higher_intent and conditional_questions_choices, then creates a fresh form with the supplied new_name. The copied context_card is normalized (Meta reads the intro cover photo back as cover_photo.id but only accepts cover_photo_id on write). Fails fast with a ValueError when the source form has no follow_up_action_url or no privacy_policy.url — Meta requires both. Returns the new form's id. Source form is untouched. Mutating, reversible via meta_ads_lead_forms_update {status: ARCHIVED} on the new form's id. Lossy: legal_content_id, gdpr_required / custom_disclaimer and question_page_custom_headline are NOT copied; re-create them on the new form manually if needed.

Input Schema

NameRequiredDescriptionDefault
reasonNoWhy this change is being made: one or two sentences naming the evidence and the expected effect. Stored in the journal and on the action_log entry this call produces, for the operator and the next session.
form_idYesSource lead form ID to copy from.
page_idYesFacebook Page that will own the new form. Usually the same Page that owns the source form.
approvalNoExternal approval this change carries out (recorded and shown, never verified)
expectedNoExpected effects [{metric, direction, target?, horizon_days?, primary?}], exactly one primary:true when several; metric cpa/cpc/cpl/cpm/conversions/cvr/ctr/roas/cost/spend/clicks/impressions; direction up/down/hold.
new_nameYesName for the new form. Pick something distinct from the source.
account_idNoMeta Ads account ID in the format 'act_XXXXXXXXXX' (e.g. 'act_1234567890'). Optional — falls back to META_ADS_ACCOUNT_ID from the configured credentials. The leading 'act_' prefix is required.
decision_idNoA proposed decision this change carries out.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.33.0
    • changedInput schema / properties / expected / description
      Previous value: -"Expected effects [{metric, direction, target?, horizon_days?}]; metric cpa/cpc/cpl/cpm/conversions/cvr/ctr/roas/cost/spend/clicks/impressions; direction up/down/hold."New value: +"Expected effects [{metric, direction, target?, horizon_days?, primary?}], exactly one primary:true when several; metric cpa/cpc/cpl/cpm/conversions/cvr/ctr/roas/cost/spend/clicks/impressions; direction up/down/hold."
  2. Changed1 schema field changedv0.28.0
    • addedInput schema / properties / approval
      Added value: +{
      +  "additionalProperties": false,
      +  "description": "External approval this change carries out (recorded and shown, never verified)",
      +  "properties": {
      +    "approved_at": {
      +      "maxLength": 64,
      +      "type": "string"
      +    },
      +    "approved_by": {
      +      "maxLength": 80,
      +      "type": "string"
      +    },
      +    "reference": {
      +      "maxLength": 128,
      +      "type": "string"
      +    }
      +  },
      +  "required": [
      +    "reference",
      +    "approved_by",
      +    "approved_at"
      +  ],
      +  "type": "object"
      +}
  3. Changed2 schema fields changedv0.26.0
    • addedInput schema / properties / decision_id
      Added value: +{
      +  "description": "A proposed decision this change carries out.",
      +  "maxLength": 128,
      +  "minLength": 1,
      +  "type": "string"
      +}
    • addedInput schema / properties / expected
      Added value: +{
      +  "description": "Expected effects [{metric, direction, target?, horizon_days?}]; metric cpa/cpc/cpl/cpm/conversions/cvr/ctr/roas/cost/spend/clicks/impressions; direction up/down/hold.",
      +  "maxItems": 12,
      +  "type": "array"
      +}
  4. Changed1 schema field changedv0.20.0
    • addedInput schema / properties / reason
      Added value: +{
      +  "description": "Why this change is being made: one or two sentences naming the evidence and the expected effect. Stored in the journal and on the action_log entry this call produces, for the operator and the next session.",
      +  "maxLength": 500,
      +  "type": "string"
      +}
  5. Changed1 schema field changedv0.10.37
    • addedInput schema / additionalProperties
      Added value: +false
  6. Addedv0.9.17

TDQS

A4.6/5.0
Behavior5/5

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

No annotations exist, so the description carries the full burden and does so thoroughly: it discloses the read-then-write mechanism, the cover_photo id normalisation quirk, fail-fast ValueError conditions on missing follow_up_action_url/privacy_policy.url, that the source is untouched, that the operation is mutating and reversible, and explicitly flags the lossy fields. That is exactly the beyond-schema behavioral context an agent needs.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the core action and mechanism, then the failure modes, then the lossy warning in bold at the end. The enumerated field list is long but each item is load-bearing for understanding what is copied.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For an 8-parameter, nested-object, no-output-schema mutation tool, the description covers mechanism, failure conditions, side effects, reversibility and data loss — the only remaining unknown is the exact return shape, and it does state the new form's id is returned.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds real semantic value: it explains which source fields get read and re-created and that new_name is what names the copy. It does not explain the bookkeeping params (reason, approval, expected, decision_id), though those are self-documented in the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource (duplicate a lead form) and immediately explains the mechanism because Meta lacks a native copy endpoint. It also distinguishes itself from siblings by naming meta_ads_lead_forms_update as the reversal path and contrasting with meta_ads_lead_forms_create implicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explains when this is needed (no native copy endpoint) and how to reverse it (archive the new form via meta_ads_lead_forms_update). It does not explicitly say when to prefer building a form from scratch with meta_ads_lead_forms_create instead, but the context is otherwise clear.

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

Deploy Server

Other Tools