Skip to main content
Glama

google_ads_budget_create

Create a new Google Ads campaign budget with a daily or custom-period amount, and get the budget ID to assign to one or more campaigns. For existing budgets, use update instead.

Instructions

Creates a new campaign budget that can be attached to one or more campaigns. Returns the new budget's id and resource_name. Mutating — not automatically reversible; record before-state with mureo_state_action_log_append if you may need to roll back. Typical flow: budget.create → campaigns.create with the returned budget_id. To edit an existing budget's amount use google_ads_budget_update instead of creating a second budget. Budget type is fixed at creation: the period (DAILY / CUSTOM_PERIOD) is immutable in the Google Ads API. For a campaign-lifetime total budget pass period='CUSTOM_PERIOD' with total_amount or total_amount_micros; otherwise supply the daily amount.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYesBudget name (max 255 chars). Must be unique within the account.
amountNoDaily budget in the account's currency (JPY / USD / etc.). Not micros — e.g. pass 5000 for ¥5,000 / day.
periodNoBudget period. Default DAILY. CUSTOM_PERIOD makes this a campaign-lifetime total budget (requires total_amount or total_amount_micros, and the attached campaign must have start/end dates). Immutable after creation.
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.
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.
total_amountNoTotal (lifetime) amount in the account's currency. Only valid with period='CUSTOM_PERIOD'. Mutually exclusive with total_amount_micros.
total_amount_microsNoTotal (lifetime) amount in micros. Only valid with period='CUSTOM_PERIOD'. Mutually exclusive with total_amount.

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. Changed5 schema fields changedv0.10.19
    • addedInput schema / anyOf
      Added value: +[
      +  {
      +    "required": [
      +      "amount"
      +    ]
      +  },
      +  {
      +    "required": [
      +      "total_amount"
      +    ]
      +  },
      +  {
      +    "required": [
      +      "total_amount_micros"
      +    ]
      +  }
      +]
    • addedInput schema / properties / period
      Added value: +{
      +  "description": "Budget period. Default DAILY. CUSTOM_PERIOD makes this a campaign-lifetime total budget (requires total_amount or total_amount_micros, and the attached campaign must have start/end dates). Immutable after creation.",
      +  "enum": [
      +    "DAILY",
      +    "CUSTOM_PERIOD"
      +  ],
      +  "type": "string"
      +}
    • addedInput schema / properties / total_amount
      Added value: +{
      +  "description": "Total (lifetime) amount in the account's currency. Only valid with period='CUSTOM_PERIOD'. Mutually exclusive with total_amount_micros.",
      +  "minimum": 1,
      +  "type": "number"
      +}
    • addedInput schema / properties / total_amount_micros
      Added value: +{
      +  "description": "Total (lifetime) amount in micros. Only valid with period='CUSTOM_PERIOD'. Mutually exclusive with total_amount.",
      +  "minimum": 1,
      +  "type": "integer"
      +}
    • changedInput schema / required
      Previous value: -[
      -  "name",
      -  "amount"
      -]New value: +[
      +  "name"
      +]
  4. Addedv0.10.11
  5. Removedv0.10.9
  6. Addedv0.9.12
  7. Removedv0.9.6
  8. Addedv0.9.2
  9. Removedv0.9.1
  10. Addedv1.0.5

TDQS

A4.8/5.0
Behavior5/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure, and it delivers: states this is mutating ('Mutating — not automatically reversible'), tells the agent to record before-state with mureo_state_action_log_append for rollback, discloses the period immutability constraint, and specifies the return value (id and resource_name). This is exemplary disclosure for a mutation 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?

Six sentences, each earning its place: purpose, return value, mutability warning, flow, alternative tool, and period semantics. Slightly dense but not padded; purpose is front-loaded and the critical immutability/rollback caveats are near the top. A minor trim would be possible but nothing is wasted.

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 7-parameter tool with an anyOf constraint and one enum, the combination of a 100%-coverage rich schema and a description that covers workflow, immutability, rollback, and daily-vs-total semantics leaves nothing an agent needs to call it correctly. No output schema exists but the description states the return value (id and resource_name). Complete.

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. The description adds value beyond the schema by explaining the daily-vs-total budget decision ('For a campaign-lifetime total budget pass period='CUSTOM_PERIOD' with total_amount or total_amount_micros; otherwise supply the daily amount') and reinforcing the immutability of period. This disambiguation is genuinely helpful for the anyOf-constrained parameters.

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?

Description states a specific verb and resource ('Creates a new campaign budget') plus a precise scope ('can be attached to one or more campaigns'). It explicitly names the sibling it is not (google_ads_budget_update) so an agent can distinguish create from edit without opening either schema. The purpose is unambiguous and differentiated.

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-to-use guidance: 'To edit an existing budget's amount use google_ads_budget_update instead of creating a second budget' names the alternative and the exact condition selecting it. Also provides a typical flow (budget.create → campaigns.create with the returned budget_id), which tells the agent the intended sequencing.

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