AdCopilot

Google Ads: pause or enable campaign

set_campaign_status

DestructiveIdempotent

Pauses or enables a Google Ads campaign.

It never deletes: status REMOVED is refused. PAUSED stops the campaign
serving and ENABLED switches it back on, at once: it serves again and can spend.

Args:
    customer_id: The Google Ads customer ID (numbers only, no hyphens).
    campaign_id: The ID of the campaign.
    status: The new status. One of: ENABLED, PAUSED.
    over_comfort_ack: The user's own words or reason when they asked to
        switch on a campaign whose daily budget is above their saved
        comfort (e.g. "user said turn it on at 6,000/day on 2026-09-23").
        Recorded with the change by the hosted connector; never sent to
        Google. Optional.

Returns:
    Dictionary with the updated resource name and confirmation message.

Tools revision: d80f65c0.

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>",
      "status": "<status>"
    },
    "name": "set_campaign_status"
  }
}

Input Schema

Name	Required	Description	Default
`status`	Yes
`campaign_id`	Yes
`customer_id`	Yes
`over_comfort_ack`	No

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 23, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations only declare destructiveHint=true and idempotentHint=true; the description adds the operational meaning: REMOVED is refused (no deletion path), PAUSED halts serving, and ENABLED resumes serving and permits spend — a real financial consequence the agent must surface. It also discloses that over_comfort_ack is captured by the hosted connector and withheld from Google, which no annotation 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-loaded with the core action, then Args/Returns blocks that map cleanly onto the schema. The over_comfort_ack entry is the longest segment but is densely informative rather than padded, which is warranted at 0% schema coverage. Minor tightening is possible in the phrasing of the ENABLED consequence.

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 spend-affecting mutation with no schema descriptions, the definition covers safety (no deletion), state semantics, argument formats, and the audit-acknowledgement requirement. An output schema exists, so the terse Returns line is sufficient rather than a gap.

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 coverage is 0% — none of the four properties has a description or enum. The tool description compensates fully: customer_id is numbers-only without dashes, status is constrained to ENABLED/PAUSED, and over_comfort_ack is explained with purpose, an example format, its recording destination, and the fact it is never transmitted to Google.

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?

The opening sentence names a specific verb pair and resource ("Pauses or enables a Google Ads campaign"), and the following clause bounds the scope by refusing the REMOVED status. That refusal separates it from any status/record deletion path and from broader mutators like update_campaign, which an agent can infer without opening another schema.

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?

The description states the two legal transitions and their consequences, so the agent knows exactly which values are in-scope and which are rejected. The over_comfort_ack parameter description also spells out when it must be supplied. It stops short of naming a sibling for adjacent needs (e.g. budget edits via update_campaign), so there is no explicit exclusion routing.

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

All AdCopilot tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?