Skip to main content
Glama
logly

mureo

by logly
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

google_ads_campaigns_create

Creates a new Search or Display campaign in a specified Google Ads account, returning its resource name and ID. Requires a pre-existing budget ID.

Instructions

Creates a new Search or Display campaign in the specified Google Ads account. Returns the new campaign's resource_name and id. Mutating — counts against daily write quota. Not automatically reversible — record before-state with mureo_state_action_log_append if you may need to roll back. Requires a pre-existing budget_id; to create a budget first, call google_ads_budget_create. For later edits use google_ads_campaigns_update or google_ads_campaigns_update_status.

Input Schema

NameRequiredDescriptionDefault
nameYesCampaign name (max 255 chars). Must be unique within the account.
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.
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.
budget_idNoExisting campaign-budget ID to attach. Create one first with google_ads_budget_create if you do not have one.
customer_idNoGoogle Ads customer ID as a 10-digit string without dashes (e.g. '1234567890'). Optional — falls back to GOOGLE_ADS_CUSTOMER_ID / GOOGLE_ADS_LOGIN_CUSTOMER_ID from the configured credentials when omitted.
decision_idNoA proposed decision this change carries out.
channel_typeNoAdvertising channel. SEARCH (default) for text ads on Google Search; DISPLAY for image/banner ads on the GDN.
bidding_strategyNoGoogle Ads bidding strategy. Defaults to MAXIMIZE_CLICKS when omitted. TARGET_CPA / TARGET_ROAS require additional target fields that this tool does not expose — use the Google Ads UI or a follow-up campaigns.update for those.

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.10.11
  7. Removedv0.10.9
  8. Addedv0.9.12
  9. Removedv0.9.6
  10. Addedv0.9.2
  11. Removedv0.9.1
  12. Addedv1.0.5

TDQS

A4.7/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 load and does so: it discloses that the call is mutating, consumes daily write quota, is not automatically reversible, and recommends capturing before-state via mureo_state_action_log_append. It also surfaces a bidding-strategy limitation (TARGET_CPA/TARGET_ROAS unsupported) that would otherwise cause a failure.

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 tight sentences, each doing distinct work: purpose, return value, side effects/rollback, prerequisites and alternatives. Nothing repeated and the most decision-relevant facts come first.

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 9-parameter mutating tool with a nested approval object and no output schema, the description supplies the return shape, the quota and reversibility profile, the cross-tool prerequisite chain, and the follow-up path. An agent can call this correctly without opening anything else.

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 name, budget_id, customer_id, channel_type, bidding_strategy and the nested approval/expected shapes. The description adds only the budget_id prerequisite and default-behavior context already implied by the schema, so the baseline applies.

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 Search or Display campaign') plus the target account scope, and declares the return values (resource_name, id). It is clearly distinguishable from the update/update_status siblings, which it names.

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?

Explicitly states the prerequisite (a pre-existing budget_id) and routes to google_ads_budget_create when one is missing. It also names the correct alternatives for later changes (campaigns_update, campaigns_update_status) and calls out the state-logging step before a risky write.

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