Skip to main content
Glama
google-ads-mcp-write

google-ads-mcp-write

Set Ad Group Status

set_ad_group_status

Pause or resume a Google Ads ad group by specifying the customer ID, ad group ID, and desired status; an optional confirmation token supports guarded changes.

Instructions

Pause or resume an ad group.

Input Schema

NameRequiredDescriptionDefault
statusYes
ad_group_idYes
customer_idYes
confirm_tokenNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

C2.7/5.0
Behavior2/5

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

With no annotations, the description carries the full behavioral burden and does not meet it. It does not say that the operation is a mutation, what happens to serving during the pause, whether it is reversible, or that a confirm_token safety parameter exists and may be required.

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?

A single short sentence, front-loaded with the action and its scope, with no filler. Its brevity is efficient rather than padded, though the same brevity leaves required detail unstated.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The output schema is present so return values need not be explained, but for a four-parameter mutation tool with zero annotation coverage and zero schema descriptions, the definition omits prerequisites, the confirm_token gate, and any effect description. It is not sufficient for confident invocation.

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

Parameters2/5

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

Schema description coverage is 0% across four parameters, and the description only implicitly constrains the status parameter to two states (pause/resume). Nothing is said about customer_id, ad_group_id, or the confirm_token parameter, so most of the input surface is undocumented in both schema and description.

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 description names a specific verb pair ('Pause or resume') and a specific resource ('an ad group'), which distinguishes it from sibling status tools like set_campaign_status and set_keyword_status by level of entity. It stops short of explicitly contrasting with those siblings or with write_status, so it is clear but not fully differentiated.

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

Usage Guidelines2/5

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

There is no guidance on when to choose this tool over the sibling status setters, no preconditions, and no exclusions. The agent must infer from the name and the 'ad group' object that this is the ad-group-level status tool.

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