Skip to main content
Glama
trip-clear

google-ads-mcp

by trip-clear

Google 広告の広告グループを作成

google_ads_create_ad_group

Create an ad group inside a Google Ads search campaign; it starts paused by default and has no daily budget because budgets are set at campaign level.

Instructions

検索キャンペーンに広告グループを作る。日予算は持てない——Google 広告の予算はキャンペーンにしかない。既定は PAUSED。

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYes
statusNoENABLED / PAUSED。既定 PAUSED
cpc_bidNo上限クリック単価。通貨 1 単位(円なら円)
customer_idNo対象の顧客 ID(ハイフン有無どちらでも可)。省略時は GOOGLE_ADS_CUSTOMER_ID
campaign_resource_nameYescustomers/{cid}/campaigns/{id}

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.8/5.0
Behavior4/5

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

With annotations only covering readOnly=false, destructiveHint=false and openWorld=true, the description adds real behavioral context: the created ad group defaults to PAUSED, and budgets cannot live at ad-group level. These are non-obvious traits an agent needs. It still does not say what is returned or what happens on duplicate names.

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?

Three short sentences, zero filler, with the key constraint (no ad-group budget) and the default state front-loaded. Every clause earns its place, helped by the bolded emphasis.

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 create tool with no output schema, it covers the resource, the scope, the default status, and the budget limitation, which is enough to invoke it correctly. A brief note on the returned resource name or error conditions would make it fully complete.

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?

Schema description coverage is 80%, so the schema already documents name, status, cpc_bid, customer_id and campaign_resource_name. The description reinforces the budget/CPC semantics but adds no field-level detail beyond what the schema provides, so the baseline 3 applies.

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 gives a specific verb and resource (ad group creation) and scopes it to search campaigns. It does not explicitly distinguish itself from siblings like google_ads_create_campaign or google_ads_create_budget, but the scope phrase makes its role clear.

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

Usage Guidelines3/5

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

Usage is implied rather than stated: it must be inside a search campaign, and the budget note steers the agent away from trying to attach a budget here (use the campaign/budget tools instead). There is no explicit 'use this when X, use sibling when Y' guidance or prerequisite statement that the parent campaign must already exist.

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