Skip to main content
Glama
logly

mureo

by logly
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

meta_ads_campaigns_create

Creates a new Meta Ads campaign in the specified account and returns its ID, defaulting to PAUSED to prevent unapproved spend. Ad sets and ads are created separately.

Instructions

Creates a new campaign in the specified Meta Ads account. Returns the new campaign id. Mutating — not automatically reversible; record before-state with mureo_state_action_log_append if you may need to roll back. Default initial status is PAUSED — explicitly pass status='ACTIVE' only if the operator has confirmed immediate spend. A campaign acts as a container; ad sets (where budgets and targeting live) and ads must be created separately via meta_ads_ad_sets_create and meta_ads_ads_create.

Input Schema

NameRequiredDescriptionDefault
nameYesCampaign name. Visible in Ads Manager; Meta allows up to 400 characters.
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.
statusNoInitial status. Default PAUSED. Only set ACTIVE when the operator has signed off on spend.
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.
objectiveYesCampaign objective using Meta's ODAX taxonomy. Older names (CONVERSIONS, LINK_CLICKS) are rejected by current API versions — use the OUTCOME_* forms.
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.
bid_strategyNoBid strategy for automatic auction bidding. LOWEST_COST_WITHOUT_CAP is fully automatic (do NOT set bid_amount). LOWEST_COST_WITH_BID_CAP and COST_CAP both require a bid_amount on the ad set (the cap). LOWEST_COST_WITH_MIN_ROAS requires bid_constraints.roas_average_floor on the ad set. When set on the campaign, budgets typically live at the campaign (CBO) level; when set on the ad set, at the ad-set level.
daily_budgetNoDaily budget in account currency minor units (cents for USD, yen for JPY). Mutually exclusive with lifetime_budget. Budgets can live on the campaign (CBO) or the ad set — not both.
lifetime_budgetNoLifetime budget in account currency minor units. Requires a stop_time on at least one ad set. Mutually exclusive with daily_budget.
is_adset_budget_sharing_enabledNoRequired by Meta when creating a campaign WITHOUT campaign budget optimization (i.e. budgets live on the ad sets). Set false for per-ad-set budgets; set true to let ad sets share a campaign-level budget.

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. Changed3 schema fields changedv0.10.37
    • addedInput schema / additionalProperties
      Added value: +false
    • addedInput schema / properties / bid_strategy
      Added value: +{
+  "description": "Bid strategy for automatic auction bidding. LOWEST_COST_WITHOUT_CAP is fully automatic (do NOT set bid_amount). LOWEST_COST_WITH_BID_CAP and COST_CAP both require a bid_amount on the ad set (the cap). LOWEST_COST_WITH_MIN_ROAS requires bid_constraints.roas_average_floor on the ad set. When set on the campaign, budgets typically live at the campaign (CBO) level; when set on the ad set, at the ad-set level.",
+  "enum": [
+    "LOWEST_COST_WITHOUT_CAP",
+    "LOWEST_COST_WITH_BID_CAP",
+    "COST_CAP",
+    "LOWEST_COST_WITH_MIN_ROAS"
+  ],
+  "type": "string"
+}
    • addedInput schema / properties / is_adset_budget_sharing_enabled
      Added value: +{
+  "description": "Required by Meta when creating a campaign WITHOUT campaign budget optimization (i.e. budgets live on the ad sets). Set false for per-ad-set budgets; set true to let ad sets share a campaign-level budget.",
+  "type": "boolean"
+}
  6. Addedv0.9.12
  7. Removedv0.9.6
  8. Addedv0.9.2
  9. Removedv0.9.1
  10. Addedv1.0.5

TDQS

A4.5/5.0
Behavior4/5

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

With no annotations, the description carries the burden well: it declares the operation mutating, warns it is 'not automatically reversible', and prescribes capturing before-state for rollback. The PAUSED default is partly a restatement of the status parameter description, and it does not cover permission/auth or failure behavior, so it falls just short of exhaustive.

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?

Four front-loaded sentences: purpose and return value first, then reversibility risk, then the spend-safety default, then the compositional constraint. Every sentence maps to a decision the caller must make; nothing is decorative.

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 12-parameter, nested-object mutation tool with no output schema, the description supplies what structure cannot: the returned id, irreversibility, the safe status default, and the create-order dependency on ad sets and ads. The remaining fields (reason, approval, expected, decision_id) are fully specified in the schema.

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 nearly everything about name, account_id, objective, bid_strategy, budgets, and status is already documented in structured fields. The description only adds the campaign-level/container framing (that budgets and targeting live on ad sets), so it sits at the baseline for a fully documented 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 ('Creates a new campaign in the specified Meta Ads account') plus the return value ('Returns the new campaign id'). It also distinguishes the tool from meta_ads_ad_sets_create and meta_ads_ads_create by explaining that a campaign is only a container, and it is unambiguous against siblings like meta_ads_campaigns_update or the google_ads equivalents.

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

Usage Guidelines5/5

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

Gives explicit when/when-not guidance: default to PAUSED and only pass ACTIVE with operator sign-off on spend, plus a concrete prerequisite ('ad sets and ads must be created separately'). It also routes the agent to a sibling (mureo_state_action_log_append) when rollback may be needed, which is exactly the alternative-selection guidance this dimension rewards.

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