Skip to main content
Glama
logly

mureo

by logly
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

meta_ads_lead_forms_update

Change a lead form's lifecycle status to archive or reactivate it: set ARCHIVED to stop new submissions while keeping existing leads queryable, or ACTIVE to resume submissions.

Instructions

Changes a lead form's lifecycle status. This tool updates only the status field — other form fields (questions, privacy_policy_url, name, follow_up_action_url, locale, advanced layout) are intentionally out of scope; Meta's post-creation mutability has shifted between versions, so mureo stays conservative. Pass status=ARCHIVED to retire a form (existing leads stay queryable; the form stops accepting new submissions). Pass status=ACTIVE to undo an archive. Mutating, reversible (re-call with the opposite value).

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.
statusYesTarget status. ACTIVE accepts submissions; ARCHIVED stops them. Other values (DRAFT, DELETED, DELETION_PENDING) appear in read paths but cannot be set by an operator.
form_idYesLead form ID to update.
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.
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

A3.9/5.0
Behavior4/5

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

No annotations are present, so the description carries the full burden and largely does: it discloses this is a mutation, that it is reversible by re-calling with the opposite value, that existing leads stay queryable, and that the form stops accepting submissions. It does not mention required permissions/auth scopes or any rate limits, which is the remaining gap for a write tool with zero annotation coverage.

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 purpose, then scope boundaries, then per-value usage, so the agent can stop reading early. The aside about Meta's shifting post-creation mutability justifies the conservative design but is the one sentence that doesn't directly help invocation.

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

Completeness4/5

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

For a mutation tool with no annotations and no output schema, it covers the essentials: what changes, what doesn't, side effects on leads, and reversibility. Auth expectations and what the call returns are left unstated, though the rich 100%-covered schema carries the remaining parameters.

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 required form_id and the ACTIVE/ARCHIVED enum are already documented in the schema, including that DRAFT/DELETED/DELETION_PENDING are not settable. The description restates the ARCHIVED/ACTIVE intent, adding the operational consequence (leads queryable) rather than new parameter semantics; the four auxiliary parameters (reason, approval, expected, decision_id, account_id) are not touched at all.

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

Purpose4/5

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

"Changes a lead form's lifecycle status" gives a specific verb and resource, then immediately narrows scope: "updates only the status field" with the other form fields explicitly listed as out of scope. That effectively separates it from meta_ads_lead_forms_create/duplicate/list/get, though no sibling is named directly.

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?

Gives concrete conditional guidance: pass status=ARCHIVED to retire a form, status=ACTIVE to undo an archive, and states that question/privacy/name/URL/locale/layout edits are deliberately not supported so the agent knows to look elsewhere for those. Missing an explicit "use tool X instead" pointer, but the when-to-use conditions are 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