Google Ads MCP Server

create_campaign

Creates a new Google Ads campaign and its daily budget atomically, defaulting to paused with a preview before confirmation.

Instructions

Create a new campaign with a budget.

Creates both the campaign budget and campaign in a single atomic operation.
Campaign is created as PAUSED by default for safety.

Safety: returns a preview first; call again with confirm=True to create it.
Refused if budget_amount is above GOOGLE_ADS_MAX_DAILY_BUDGET.

Args:
    customer_id: Google Ads customer ID.
    name: Campaign name.
    budget_amount: Daily budget in currency (e.g., 50.00 for $50/day).
    channel_type: Campaign type -- 'SEARCH', 'DISPLAY', 'VIDEO', 'DEMAND_GEN', 'SHOPPING'.
    bidding_strategy: Bidding strategy -- 'MAXIMIZE_CONVERSIONS', 'MAXIMIZE_CONVERSION_VALUE',
        'MAXIMIZE_CLICKS', 'TARGET_SPEND', 'MANUAL_CPC', 'TARGET_CPA', 'TARGET_ROAS'.
    target_cpa: Target CPA in currency (required if bidding_strategy is TARGET_CPA).
    target_roas: Target ROAS as a decimal (e.g., 3.0 for 300% ROAS).
    network_settings: Optional dict with keys: target_google_search, target_search_network,
        target_content_network (all bool).
    start_date: Campaign start date (YYYY-MM-DD). Defaults to today.
    end_date: Optional campaign end date (YYYY-MM-DD).
    status: Initial status -- 'PAUSED' (default, recommended) or 'ENABLED'.
    confirm: Must be True to actually create the campaign (after reviewing the preview).

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>",
      "name": "<name>",
      "budget_amount": "<budget_amount>"
    },
    "name": "create_campaign"
  }
}

Input Schema

Name	Required	Default
`name`	Yes
`status`	No	PAUSED
`confirm`	No
`end_date`	No
`start_date`	No
`target_cpa`	No
`customer_id`	Yes
`target_roas`	No
`channel_type`	No	SEARCH
`budget_amount`	Yes
`bidding_strategy`	No	MAXIMIZE_CONVERSIONS
`network_settings`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.0Nov 11, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Goes well beyond the annotations by disclosing the two-phase preview/confirm flow, atomic budget+campaign creation, the safety default of PAUSED status, and the budget ceiling that triggers a refusal. These are non-obvious behavioral constraints (write requires confirmation, hard cap on input) that an agent would otherwise have to discover by trial.

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-loaded with the safety and preview/confirm behavior, then a clean Args block. The opening line is mildly redundant with the following sentence, and status is described twice (default PAUSED in both prose and Args), but there is no filler.

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?

Covers all 12 parameters, the required-vs-optional contract, and failure modes for a mutation tool with no output schema. The one remaining gap is what the preview response actually contains, which would help an agent know what to inspect before confirming.

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?

With 0% schema description coverage, the description carries the full burden and does so: every parameter is explained, the channel_type and bidding_strategy allowed value sets (absent from the schema, which has no enums) are enumerated, target_cpa's conditional requirement is stated, and date formats and network_settings keys are spelled out.

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 ('Create a new campaign with a budget') and clarifies it builds the budget and campaign atomically, which differentiates it from calling create_budget separately. It never contrasts itself with the closely related create_performance_max_campaign sibling, so the differentiation is incomplete rather than absent.

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 context: the tool returns a preview first and must be re-invoked with confirm=True, and it is refused when budget_amount exceeds GOOGLE_ADS_MAX_DAILY_BUDGET. It does not say when to choose this over create_performance_max_campaign for a performance-max use case, so the alternative-selection guidance is implicit.

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

Deploy Server