Google Ads MCP Server

update_campaign

Idempotent

Modify an existing Google Ads campaign's name, status, bidding targets, or dates. Gated changes return a preview and require confirmation before applying.

Instructions

Update an existing campaign's properties.

Only provided fields will be updated.

Safety: enabling or removing the campaign, or changing bidding targets or
dates, returns a preview first; call again with confirm=True to apply.
Renaming and pausing are applied immediately.

Args:
    customer_id: Google Ads customer ID.
    campaign_id: Campaign ID to update.
    name: New campaign name.
    status: New status -- 'ENABLED', 'PAUSED'.
    target_cpa: New target CPA (for maximize_conversions with target).
    target_roas: New target ROAS (for maximize_conversion_value with target).
    start_date: New start date (YYYY-MM-DD).
    end_date: New end date (YYYY-MM-DD).
    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>",
      "campaign_id": "<campaign_id>"
    },
    "name": "update_campaign"
  }
}

Input Schema

Name	Required	Description	Default
`name`	No
`status`	No
`confirm`	No
`end_date`	No
`start_date`	No
`target_cpa`	No
`campaign_id`	Yes
`customer_id`	Yes
`target_roas`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.0Nov 11, 2026

TDQS

A3.6/5.0

Behavior3/5

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

Strong value beyond the annotations: it discloses the two-phase preview/confirm gate, names exactly which mutations are gated versus immediate, and confirms non-destructive partial-update behavior. However, it does not describe what the preview returns, whether a pending preview must be re-issued if fields change, or any permission requirements — details an agent needs to drive the confirm loop reliably.

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 the safety model before the argument list, which is the right ordering for a mutation tool, and the Args block earns its space given zero schema descriptions. Minor waste and ambiguity in the phrase 'enabling or removing the campaign', since removal is not an available parameter here.

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 9-parameter mutation with no output schema and no annotation-encoded confirmation semantics, the definition covers purpose, gating behavior, and every parameter. The remaining gap is the return side — an agent is told a preview exists but not what it contains or how to read it before confirming.

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?

With 0% schema coverage this description carries the full burden, and it does define all nine parameters including formats (YYYY-MM-DD), allowed status values, and when target_cpa versus target_roas applies. Still thin for the tuning fields (no units or constraints stated, and micros conversion is a separate sibling tool) and confirm is described only as 'Must be True to apply a gated change' without saying what happens if omitted.

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 campaign's properties') and adds the partial-update semantics ('Only provided fields will be updated'), which tells an agent this is a patch, not a replace. It does not differentiate from overlapping siblings such as set_campaign_status (also a status writer) or remove_campaign, so the agent must infer the boundary.

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?

Gives clear operational guidance for the confirm flow: which changes return a preview and require confirm=True, and which ('Renaming and pausing') apply immediately. What is missing is routing guidance for sibling tools — nothing says when to prefer set_campaign_status or remove_campaign over this tool, and 'removing the campaign' is referenced even though no remove parameter exists in the schema.

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

Deploy Server