Skip to main content
Glama
Google Ads MCP Server

Google Ads MCP Server

update_ad_group

Idempotent

Modify an existing Google Ads ad group by updating its name, status, CPC bid, or target CPA. Bid, enable, and remove changes return a preview first and require confirmation.

Instructions

Update an existing ad group.

Only provided fields will be updated.

Safety: bid changes, enabling and removing return a preview first; call
again with confirm=True. Renaming and pausing apply immediately. Refused if
cpc_bid is above GOOGLE_ADS_MAX_CPC_BID.

Args:
    customer_id: Google Ads customer ID.
    ad_group_id: Ad group ID to update.
    name: New ad group name.
    cpc_bid: New max CPC bid in currency.
    target_cpa: New target CPA in currency.
    status: New status -- 'ENABLED', 'PAUSED', or 'REMOVED'.
    confirm: Must be True to apply a gated change.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "customer_id": "<customer_id>",
      "ad_group_id": "<ad_group_id>"
    },
    "name": "update_ad_group"
  }
}

Input Schema

NameRequiredDescriptionDefault
nameNo
statusNo
confirmNo
cpc_bidNo
target_cpaNo
ad_group_idYes
customer_idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A4.2/5.0
Behavior5/5

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

Discloses behavior the annotations do not: which changes are gated behind a preview/confirm round-trip (bid changes, enabling, removing) versus which apply immediately (renaming, pausing). It also names a hard constraint ('Refused if cpc_bid is above GOOGLE_ADS_MAX_CPC_BID') that no structured field conveys.

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 partial-update semantics, then the safety model, then per-parameter notes — a sensible ordering for an agent deciding whether it needs a second call. The safety paragraph's line wrapping adds slight noise, but no sentence is redundant given the 0% schema coverage.

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 7-parameter mutation with no output schema, it covers what changes are applied, what is immediate, what is gated, and what is rejected. The remaining gap is that it does not say what the preview response contains before the agent decides to confirm, which matters for the two-step flow it mandates.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% and the schema has no enums, so the description carries the full burden. It documents every parameter's meaning, supplies units ('in currency'), and enumerates the allowed status values ('ENABLED', 'PAUSED', 'REMOVED') plus the gating semantics of confirm.

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?

States a specific verb and resource ('Update an existing ad group') and clarifies the partial-update semantics ('Only provided fields will be updated'). It does not address how it relates to the sibling set_ad_group_status, which overlaps on the status parameter, so sibling differentiation is incomplete.

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

Usage Guidelines3/5

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

Gives clear context for the two-step confirm flow and names the precondition for gated changes (call again with confirm=True), which is real usage guidance. However, it never says when to use this tool rather than set_ad_group_status or update_campaign, and it leaves the overlap between 'status: REMOVED' here and a dedicated status setter unresolved.

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