Skip to main content
Glama

Create campaign

create_campaign

Create a new campaign. It runs only on the platforms named in body._platformBudgets, which is required. budget is daily, in the platform account's currency (list_connections); some platforms set a per-currency daily minimum, which validate_export names. Platform-only settings go in body._native, keyed by platform id — the NativeExtensions schema in the OpenAPI spec lists each platform's keys: for example a lifetime budget (budgetKind LIFETIME, which can never become daily once pushed and needs a fixed bid: biddingStrategy MANUAL_CPC with biddingStrategy.cpcBid, or a cpcBid on each ad group), the bidding type, or the delivery surfaces. A campaign created as DRAFT is held back until confirm_campaign. Returns the full updated/created object. Scoped to the active Space — see set_active_space to switch, or pass space_id to override for this one call.

Input Schema

NameRequiredDescriptionDefault
bodyYesRequest body matching the CampaignCreate schema. Fields below; see the OpenAPI spec for nested object shapes.
space_idNoOverride the active Space for this one call. Defaults to the active Space set via set_active_space (or GROWOMAT_SPACE_ID on the server). Pass to read/write a different Space without changing the session binding.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • addedInput schema / properties / body / properties / _native
      Added value: +{
      +  "additionalProperties": true,
      +  "description": "Platform-only settings, keyed by platform id (for example {\"openai-ads\": {\"budgetKind\": \"LIFETIME\"}}). Each value is stored and returned as sent. The NativeExtensions schema in the OpenAPI spec lists every key each platform reads and where (campaign, ad group or ad) — a lifetime budget, a bidding type, delivery surfaces, the words and image on a card. On update, send the whole object for a platform: it replaces that platform's settings.",
      +  "type": "object"
      +}
    • addedInput schema / properties / body / properties / adScheduleUseSearcherTimeZone
      Added value: +{
      +  "description": "Interpret the ad schedule in the searcher's local time zone instead of the account time zone, on platforms that support it (Microsoft Advertising). Ignored elsewhere.",
      +  "type": "boolean"
      +}
    • changedInput schema / properties / body / properties / biddingStrategy / description
      Previous value: -"Nested BiddingStrategy; see the OpenAPI spec for the field list."New value: +"How the platforms bid. MANUAL_CPC bids biddingStrategy.cpcBid per click (an ad group's own cpcBid wins); the target strategies read their target from the matching field."
    • addedInput schema / properties / body / properties / biddingStrategy / properties
      Added value: +{
      +  "cpcBid": {
      +    "description": "The click bid for MANUAL_CPC, in the account currency. Every ad group without its own cpcBid bids this.",
      +    "type": "number"
      +  },
      +  "maxCpcBidCeiling": {
      +    "description": "Never bid more than this per click.",
      +    "type": "number"
      +  },
      +  "targetCpa": {
      +    "description": "Target cost per acquisition, for TARGET_CPA.",
      +    "type": "number"
      +  },
      +  "targetImpressionShare": {
      +    "description": "Target impression share in percent, for TARGET_IMPRESSION_SHARE.",
      +    "type": "number"
      +  },
      +  "targetRoas": {
      +    "description": "Target return on ad spend as a ratio (2.5 means 250%), for TARGET_ROAS.",
      +    "type": "number"
      +  },
      +  "type": {
      +    "enum": [
      +      "MANUAL_CPC",
      +      "ENHANCED_CPC",
      +      "MAXIMIZE_CLICKS",
      +      "MAXIMIZE_CONVERSIONS",
      +      "MAXIMIZE_CONVERSION_VALUE",
      +      "TARGET_CPA",
      +      "TARGET_ROAS",
      +      "TARGET_IMPRESSION_SHARE"
      +    ],
      +    "type": "string"
      +  }
      +}
  2. Changed2 schema fields changed
    • addedInput schema / properties / body / properties / _platformBudgets
      Added value: +{
      +  "additionalProperties": {
      +    "properties": {
      +      "amount": {
      +        "minimum": 0,
      +        "type": "number"
      +      },
      +      "enabled": {
      +        "type": "boolean"
      +      }
      +    },
      +    "type": "object"
      +  },
      +  "description": "Where the campaign runs, keyed by platform id (google-ads, microsoft-ads, reddit-ads, meta-ads, openai-ads, linkedin-ads), each { amount?: number, enabled?: boolean }. Only listed, switched-on platforms run; being connected never adds one. { \"reddit-ads\": {} } puts the whole budget on Reddit Ads; an entry without amount gets an even share of what the listed amounts leave. If the user has not said where the campaign should run, ask them before calling this tool, offering their connected platforms by name.",
      +  "type": "object"
      +}
    • changedInput schema / properties / body / required
      Previous value: -[
      -  "name",
      -  "budget"
      -]New value: +[
      +  "name",
      +  "budget",
      +  "_platformBudgets"
      +]
  3. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations only declare it is not read-only and not destructive. The description goes far beyond: pushes are irreversible in one direction (a LIFETIME budget can never become daily), DRAFT campaigns are held until confirm_campaign, and the call is scoped to the active Space. It also states it returns the full created/updated object.

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 what it does and which field is required, then layers constraints. It is a single dense paragraph with heavy nested parentheticals (lifetime budget example, space scoping) that slow parsing, but no sentence is truly expendable.

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 complex create with nested objects and no output schema, it covers the required fields, currency semantics, platform-specific extension handling, draft lifecycle, and Space scoping, while deferring shape details to the OpenAPI spec. Nothing an agent needs to invoke it correctly is missing.

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 meaning: _platformBudgets is required and only listed, switched-on platforms run; budget is a daily figure in the platform account's currency; _native is keyed by platform id and carries platform-only keys. The lifetime-budget example (budgetKind LIFETIME requiring MANUAL_CPC plus cpcBid) is genuinely non-obvious guidance.

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 (create a new campaign) plus its defining constraint: it only runs on platforms listed in body._platformBudgets. It implicitly distinguishes itself from update_campaign, preview_campaign and confirm_campaign by describing the DRAFT-until-confirmed lifecycle, so an agent can pick it without opening a schema.

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?

Routes the agent to concrete siblings for supporting facts: list_connections for currency, validate_export for per-currency minimums, set_active_space for scope, confirm_campaign for draft release, and set_ad_schedule/set_geo_targeting as preferred helpers. It gives clear context but stops short of saying when NOT to create directly (e.g. preview first).

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources