Skip to main content
Glama
Sign In
Google Ads MCP Server

Google Ads MCP Server

by nexoradev-stack
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

set_ad_group_status

DestructiveIdempotent

Pause, enable, or remove a Google Ads ad group by updating its status; enable and remove actions require confirmation after a preview.

Instructions

Set an ad group's status (enable, pause, or remove).

Safety: PAUSED applies immediately; ENABLED and REMOVED return a preview
first and need confirm=True.

Args:
    customer_id: Google Ads customer ID.
    ad_group_id: Ad group ID.
    status: New status -- 'ENABLED', 'PAUSED', or 'REMOVED'.
    confirm: Must be True to enable or remove.

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

Input Schema

NameRequiredDescriptionDefault
statusYes
confirmNo
ad_group_idYes
customer_idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A4.3/5.0
Behavior4/5

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

Beyond the annotations, the description discloses a two-step preview/confirm protocol and the asymmetry between PAUSED and the other statuses, which the annotations alone (destructiveHint, idempotentHint, openWorldHint) cannot convey. It does not say whether REMOVED is irreversible or what the preview response contains, leaving some mutation risk undisclosed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose, then safety constraint, then a compact Args block — everything is front-loaded and no sentence is redundant. The structure matches how an agent scans a mutation tool before calling it.

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 destructive, open-world mutation with no output schema, the definition covers the critical items: parameter meanings, enum values, and the confirm gate. The remaining gap is outcome detail — what the preview returns and whether REMOVED can be undone — which matters for a destructive operation.

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% and the schema defines no enum for status, so the description carries the full burden: it documents all four parameters, supplies the exact enum values 'ENABLED', 'PAUSED', 'REMOVED', and explains that confirm must be True for enable/remove. This is meaning the schema does not provide.

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?

The first sentence gives a specific verb (Set), resource (ad group's status), and the three allowed values, which cleanly separates it from set_ad_status and set_campaign_status by resource scope. It stops short of explicitly naming those siblings, but the resource specificity is enough to disambiguate.

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 Safety line tells the agent when the operation applies immediately (PAUSED) versus when a preview is returned and confirm=True is required (ENABLED, REMOVED), which is actionable invocation guidance. It does not discuss when to prefer this over related tools like update_ad_group or set_ad_status, so it stops short of explicit alternatives guidance.

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