Skip to main content
Glama
logly

mureo

by logly
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

meta_ads_lead_forms_duplicate

Duplicate a Meta lead form on the same or another Page by copying its questions, privacy policy, follow-up URL, and settings, creating a new named form. Works around Meta's absent copy endpoint.

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

TableJSON 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.
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.

Schema Changelog

Changes observed during successful MCP inspections.

  1. 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"
+}
  2. Changed1 schema field changedv0.10.37
    • addedInput schema / additionalProperties
      Added value: +false
  3. Addedv0.9.17

TDQS

A4.5/5.0
Behavior5/5

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

With no annotations provided, the description carries the full burden and meets it thoroughly. It discloses mutation, reversibility, source form being untouched, the normalization caveat for context_card, the fail-fast ValueError condition, the lossy fields that are not copied, and the return value.

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

Conciseness5/5

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

The description is dense but every sentence earns its place: purpose, implementation approach, normalization caveat, failure behavior, return value, mutability, reversibility, and lossy fields. The most important information is front-loaded and the additional caveats are clearly flagged.

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 a mutating tool with no output schema, the description is unusually complete: it states what is copied, what is not copied, what happens on failure, how to reverse the operation, and what is returned. Combined with fully documented parameters, nothing critical is missing for an agent to use it correctly.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents all five parameters. The description adds some reinforcement around new_name and the copy source, but no significant per-parameter meaning beyond what the schema provides. Baseline 3 is appropriate.

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?

The description uses a specific verb ('Duplicates') and resource ('lead form'), and immediately clarifies the scope: same or another Page. It clearly differentiates this from create/update siblings by describing the copy mechanics and the 'no native copy endpoint' caveat.

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?

The use case is clear: duplicate an existing lead form, preserving specified fields and creating a new form. It does not explicitly name meta_ads_lead_forms_create as the alternative for creating a blank form from scratch, but it does mention reversibility via meta_ads_lead_forms_update, giving useful adjacent-tool context.

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