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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the bolded 読み取り専用 is largely redundant. However, since there is no output schema, the description's enumeration of returned fields (name/currency/timezone/MCC flag) supplies genuinely useful behavioral context about what the call returns.

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

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

Two short sentences with zero waste; the return fields are front-loaded, the read-only property is emphasized, and the usage cues follow. Nothing is padded.

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

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

For a single-optional-parameter read-only lookup with full schema coverage and no output schema, the definition covers purpose, returns, and usage contexts adequately. It could be marginally richer (e.g. behavior on unresolved customer_id), but nothing essential for correct invocation is missing.

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

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

The single parameter has 100% schema description coverage, including the hyphen-optional format and the GOOGLE_ADS_CUSTOMER_ID fallback, so the schema fully carries the semantics. The description adds nothing about customer_id, making the baseline 3 correct.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a concrete verb (返す) and enumerates the exact resource fields returned — name, currency, timezone, and MCC status — so an agent knows precisely what this tool yields. It does not name a sibling alternative, but the enumerated fields make the tool's scope unambiguous against the many mutation/report siblings.

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

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

It gives explicit when-to-use conditions: 疎通確認 (connectivity/smoke check) and 通貨確認 before touching budgets. That is clear situational guidance. It stops short of naming a specific alternative tool, so it lands at 4 rather than 5.

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

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

Beyond the annotations (readOnlyHint=false, destructiveHint=false, openWorldHint=true), the description discloses a genuinely important trait: a keyword created as negative cannot later be converted to a normal keyword, so mistakes require delete-and-recreate. This is real behavioral context the annotations do not carry.

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

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

Two tightly written sentences, front-loaded with the core action before the high-risk caveat. Every clause earns its place with no redundancy.

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

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

For a mutation tool with no output schema and full schema coverage, the description supplies the key missing behavioral warning (negative-keyword irreversibility). It does not mention auth/customer resolution or return behavior, but the essential risk context is present.

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

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

Schema description coverage is 100%, so the schema already documents keywords, negative, match_type, customer_id, and ad_group_resource_name. The description reinforces the negative parameter's meaning and adds the irreversibility caveat, but the schema does the bulk of parameter documentation, matching the baseline 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb+resource: adding keywords to an ad group. It clearly tells an agent what the tool does, though it does not explicitly distinguish itself from sibling tools like google_ads_keywords or google_ads_mutate that could plausibly touch the same resource.

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

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

It explains the semantic effect of the negative=true parameter but gives no explicit when-to-use / when-not-to-use guidance relative to alternatives such as google_ads_mutate or google_ads_keywords. Usage is implied by the parameter note rather than stated as selection criteria.

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

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.

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.

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.

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.

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.

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.

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

Annotations only give readOnly=false/destructive=false/openWorld=true, but the description adds substantive behavior: atomic all-or-nothing request rejection by Google, the 5120 KB per-image limit, the default PAUSED status, and validate_only's dry-run semantics. These are meaningful traits beyond what annotations convey.

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

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

The purpose and the atomic-creation constraint are front-loaded, and the dense constraint list earns its place given the strict validation rules. It is long but nearly every clause carries required calling information, with only minor redundancy between description and schema.

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

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

For a 15-parameter, 10-required mutation tool with no output schema, the description covers atomicity, required asset counts and ratios, character-counting rules, image size limits, validate_only pre-checks, and the default status. Nothing essential to a correct call is missing.

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

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

Schema coverage is 100%, so baseline is 3, but the description adds semantics the schema lacks: images accept local file paths or http(s) URLs (not stated per-field), the full-width-counts-as-2 rule that halves Japanese character limits, and minimum/maximum counts for each asset type. These extend beyond the structured field descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource (creating a P-MAX asset group) and explicitly disambiguates from siblings by noting P-MAX has no ad groups or ads, unlike google_ads_create_ad_group. An agent can tell exactly what this produces without opening the schema.

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

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

It gives actionable operational guidance: run validate_only=true first to pre-check, and explains that everything must be created in a single mutate call per Google's requirement. It does not explicitly contrast with google_ads_mutate for partial updates, so usage is clear but not exhaustively scoped.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds the server-side micro-conversion behavior and the ordering dependency, but says nothing about permissions, whether duplicate names are rejected, or what the call returns — modest added value over the annotations.

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

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

Three short clauses: purpose, the ordering rationale, and the unit rule. Nothing redundant, and the functional statement is front-loaded.

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

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

For a mutation tool with no output schema, the description omits what is returned — notably the created budget's resource ID, which the agent needs to attach the budget to a campaign, the very workflow the description describes. Ordering and units are covered, so it is adequate but not complete.

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

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

Schema description coverage is 100%, so the schema already documents all three parameters including the currency-unit rule. The description restates the unit convention for daily_amount but adds no semantics the schema lacks (e.g. the customer_id environment-variable fallback is only in the schema). Baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (作る/create) and resource (キャンペーン予算), and explicitly distinguishes it from the campaign resource by noting that budget is a separate Google Ads resource. An agent can immediately tell this apart from google_ads_create_campaign.

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

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

Gives a clear ordering rule: create the budget before the campaign. What is missing is exclusion guidance against the sibling google_ads_update_budget, which handles the modify-existing case; without that, an agent might reach for this tool to adjust an existing budget.

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

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

Annotations cover the safety profile (readOnlyHint=false, destructiveHint=false, openWorldHint=true), and the description adds real behavioral context beyond that: default PAUSED status, network-targeting defaults off for Search, and the P-MAX constraint that no manual bidding, ad groups, or ads exist. It does not discuss auth, quotas, or failure modes.

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

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

Front-loads the core action and the critical default (既定は PAUSED), then layers dependencies and P-MAX caveats. Bold emphasis aids scanning. It is dense but every clause carries operational information; no filler.

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

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

For a mutation tool with an output-less schema, the description supplies the essential preconditions (budget resource name source, P-MAX asset-group requirement, default paused state) an agent needs to call it correctly. Remaining gaps are minor and would be covered by per-parameter schema text.

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

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

Schema description coverage is 91%, so the schema already documents nearly every parameter, including the PAUSED default and enum meanings the description repeats. The description adds only the provenance of budget_resource_name and the P-MAX bidding caveat, so baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource (キャンペーンを作る) and immediately scopes it to the two supported channel types (検索 / P-MAX), which distinguishes it from siblings like create_ad_group or create_asset_group. An agent can identify what this tool produces without opening the schema.

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

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

Names concrete dependencies and routes to siblings: budget_resource_name comes from google_ads_create_budget, and P-MAX requires google_ads_create_asset_group ('無いと配信できない'). It also clarifies that creation and serving-enablement are separate operations. No explicit when-not-to-use guidance, but the context is clear.

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

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

Annotations cover the safety profile (readOnlyHint=false, destructiveHint=false), so the description only needs to add constraints. It does so well: the default PAUSED status (a safe-create behavior) and the exact validation bounds for headlines and descriptions. It stops short of describing the response or whether the ad is returned/attached.

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

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

Compact and front-loaded: the action comes first, then the constraints, then the default status. Every sentence carries content. Slightly dense for non-Japanese readers but no waste.

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

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

All 8 parameters are documented in the schema and the key validation rules are restated in the description, but with no output schema the description never says what is returned (e.g., the created ad resource name/id) or what auth/account scoping applies beyond the customer_id default. Adequate but with a clear gap.

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

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

Schema coverage is 100%, so the baseline is 3. The description earns an extra point by explaining the full-width character-counting rule and its consequence (Japanese limits effectively halved: 15/45), which is the non-obvious part of validating these fields.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource (レスポンシブ検索広告を作る) that is immediately distinguishable from siblings like create_campaign, create_ad_group and create_asset_group. An agent knows exactly which ad type is produced.

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

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

It never says when to use this tool versus the other creation siblings, nor states prerequisites explicitly. The required ad_group_resource_name implicitly signals an existing ad group is needed, but that is inference, not guidance.

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

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

Annotations already declare readOnlyHint, destructiveHint, and openWorldHint, so the safety profile is covered and the redundant '読み取り専用' adds nothing. However, the description discloses two genuinely useful behavioral facts beyond the annotations: bid amounts are in micro units (1,000,000 = 1 currency unit) and related keyword suggestions are also returned.

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

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

Three tight sentences, front-loaded with the primary purpose followed by the micro-unit caveat and the return content. Only the bolded '読み取り専用' is wasted space since it duplicates the readOnlyHint annotation.

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

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

With no output schema, the description correctly names the returned fields (volume, competition, bid range, related keywords) and flags the micro-unit format. Combined with the safety annotations and fully covered schema, an agent has enough to call it correctly; only rate-limit or auth context is absent, which is minor here.

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

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

Schema description coverage is 100%, so all four parameters (keywords, customer_id, language_id, geo_target_ids) are already fully documented with examples in the schema. The description adds no parameter-level syntax or constraints beyond that, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: retrieve monthly average search volume, competition, and bid range for keywords via Keyword Planner. This is clearly distinct from the mutation-oriented sibling google_ads_add_keywords, so an agent can route correctly without opening either schema.

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

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

The retrieval purpose implies when to reach for this tool (researching keyword metrics before bidding), but there is no explicit when-to-use, no exclusions, and no named alternative — notably the easy-to-confuse google_ads_add_keywords is never mentioned. Usage is inferred rather than stated.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the repeated 読み取り専用 marker earns no extra credit. However, the description adds real behavioral value beyond annotations by disclosing a return limitation: names are not included in the response.

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

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

Three short clauses, front-loaded with the action and scope, then safety, then the caveat/redirect. Every sentence carries information and none is padding.

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

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

With no output schema, the description compensates by stating exactly what the response contains (customer IDs only, no names) and where to get the missing piece. For a zero-parameter read tool with full annotation coverage, nothing needed to call it correctly is missing.

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

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

The tool takes zero parameters, so there is nothing to document and the baseline of 4 applies. The description correctly adds no parameter discussion.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (一覧する/list) and resource (顧客 ID / customer IDs) plus the access scope (directly accessible from the linked account). It also distinguishes itself from the sibling that returns names, so an agent can tell what this returns without opening a schema.

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

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

Implies this is the discovery step for customer IDs and explicitly routes the agent to google_ads_account_info when human-readable names are needed. It lacks an explicit 'use this first when...' framing, but the relationship to the sibling tool is clear.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description's '読み取り専用' is redundant. It adds useful context about status values (ENABLED/PAUSED, not ACTIVE) and that REMOVED are excluded, plus that daily budget only exists on campaigns. These are valuable behavioral details beyond annotations.

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

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

Concise single paragraph with bold emphasis on key points. Front-loads the main purpose and critical constraints. No wasted words.

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

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

Complete enough for a list tool: what it lists, status filtering behavior, budget location, and read-only nature. The absence of an output schema means return format isn't described, but that's a minor gap for a listing tool.

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

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

Schema description coverage is 100%, so the schema fully documents all three parameters including defaults and enums. The description adds no parameter-specific syntax or format details, so the baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a clear verb (list) and resources (campaign/ad group/ad), distinguishing it from creation/update siblings. However, it doesn't explicitly differentiate from google_ads_search, google_ads_report, or google_ads_keywords, which may also retrieve entities. Still, the scope is clear.

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

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

Implies usage for listing campaigns, ad groups, and ads, but doesn't say when to prefer this over other read tools like google_ads_search or google_ads_report. No exclusions or prerequisites are mentioned.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=true, openWorldHint=true, so the safety profile is covered. The description adds genuine value on top: it documents the validate_only=true dry-run behavior ('検算だけ、何も変更しない') and the recommended validate-then-commit sequence. It doesn't discuss rate limits, partial failure, or auth expectations, keeping it below 5.

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

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

Two compact sentences, front-loaded with the tool's role and followed by the dry-run guidance. No filler, no repetition of the title, and the most decision-relevant information (last resort + validate first) leads.

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

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

For a destructive, open-world mutation tool with no output schema, the description covers why it exists, when to prefer it, and the safe dry-run path. It leaves unstated what a successful mutate returns and how errors/partial failures surface, which is a minor gap given the schema handles the inputs.

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

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

Schema description coverage is 100%, so the baseline is 3. The description reiterates validate_only's meaning (already in the schema) and says nothing about customer_id's env-var fallback or the MutateOperation array shape beyond what the schema states. It neither compensates for nor undermines the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific action (raw write via googleAds:mutate) and positions it as the fallback for writes the typed tools don't cover, which distinguishes it from the create_*/update_*/remove siblings. It clearly conveys 'escape hatch for mutations not otherwise expressible'. It stops short of 5 only because it doesn't spell out what a MutateOperation targets beyond the parenthetical.

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

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

It names the alternative (the typed tools) and the condition that selects this one ('足りない書き込み' = writes the typed tools lack), plus a concrete workflow: run validate_only=true first for complex operations before committing. That is explicit when-to-use and how-to-sequence, which is exactly what the dimension asks for.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the safety profile is partly covered. The description nonetheless reinforces irreversibility in bold ('元に戻せない') and steers toward the reversible pause path, which is valuable emphasis for a destructive tool, though it omits things like cascade effects on children or permission requirements.

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

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

Two tight sentences plus a parenthetical; the destructive warning and the safer alternative are front-loaded. Nothing is padding.

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

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

For a no-output-schema destructive tool with fully covered parameters, the description supplies the essential facts: what is deleted, that it cannot be undone, and the alternative. It stops short of stating downstream effects or required permissions, a minor remaining gap.

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

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

Schema description coverage is 100%, so all three parameters (kind enum with default, object_id, customer_id) are already documented. The description restates the composite '広告グループID~広告ID' key for kind=ad, which is useful but duplicated from the schema's own wording, so it adds little beyond the baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (削除する) and enumerates the exact resources (キャンペーン / 広告グループ / 広告), distinguishing it from the many create/update siblings. An agent can immediately tell this is the destructive removal tool.

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

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

Explicitly names the alternative (google_ads_update_status with PAUSED) and the condition that selects it ('止めたいだけなら'), i.e. when NOT to delete. This is precisely the routing guidance an agent needs before performing an irreversible action.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description redundantly but consistently states 読み取り専用. Beyond that it adds genuinely valuable behavior: costMicros must be divided by 1,000,000 uniformly across currencies, conversions may be fractional, and int64 fields are serialized as strings under proto3 JSON rules. It stops short of disclosing limits, pagination, or whether large date ranges are truncated.

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

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

Four compact sentences with zero filler, and the most important fact (what is returned and that it is read-only) is front-loaded before the unit-conversion caveats. Nothing is repeated from the schema or annotations.

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

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

With no output schema, the description carries the burden of explaining return values, and it does so for the trickiest cases: micros conversion, fractional conversions, and string-encoded int64s, plus the explicit note that CTR/CPC are not provided. It omits the shape of the result set (columns/rows), pagination, and row limits, which leaves a modest gap.

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

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

Schema description coverage is 100%, so all five parameters (including the level enum default and the customer_id fallback to GOOGLE_ADS_CUSTOMER_ID) are already documented. The description adds no parameter-level detail beyond the schema, so the baseline of 3 applies; its value-unit notes concern returned fields rather than inputs.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource (Google 広告の実績を取得) and enumerates the exact metrics returned (費用・表示・クリック・CV・CV 値), so an agent knows precisely what data comes back. It does not, however, differentiate itself from metric-bearing siblings such as google_ads_search or google_ads_keywords, leaving some ambiguity about which tool supplies report-style aggregates.

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

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

No when-to-use or when-not-to-use guidance is given, and no sibling alternative is named. The closest thing to guidance is the instruction to compute CTR/CPC downstream, which is about post-processing, not about selecting this tool over google_ads_search.

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

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

Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=true), and the description reinforces the read-only nature. It adds genuinely new behavioral context absent from annotations and schema: field names must be snake_case, returned keys are camelCase, and int64 values are returned as strings. No mention of pagination behavior or failure modes, keeping it out of the 5 band.

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

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

Front-loads the verb and resource, then read-only status, then when-to-use, then the output-format quirks. Every clause carries information; no filler or repetition.

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

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

With no output schema, the description compensates by explaining return-key casing and int64-as-string behavior, which is exactly what an agent needs to consume results. Minor gaps remain around pagination/row-limit interaction and error handling, so not a full 5.

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

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

Schema coverage is 100% (baseline 3), and the description layers on query-authoring semantics the schema omits: a concrete example query plus the snake_case field-name convention that governs the required 'query' parameter. row_limit and customer_id are left to the schema, which already documents them.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (execute) plus resource (arbitrary GAQL via googleAds:searchStream) and immediately distinguishes it from the typed sibling tools by naming the query categories it uniquely unlocks (search terms, per-keyword performance, assets, region). An agent can tell it apart from google_ads_report/google_ads_keywords without opening any schema.

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

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

Explicitly scopes usage to data the typed tools cannot retrieve, which implicitly routes the agent here as a fallback and away from siblings. It stops short of naming a specific alternative tool or stating an exclusion/exhaustive condition, so it falls just below the top band.

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

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

Annotations already declare write (readOnlyHint=false), non-destructive, open-world. The description adds genuinely useful behavioral context beyond that: the amount is expressed in whole currency units, not micros, which is a real trap in the Google Ads API. It doesn't cover reversibility, rate limits, or propagation delay.

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

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

Three short sentences, front-loaded with the action and the single most important pitfall (budget resource vs campaign), then the id source, then unit semantics. No filler.

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

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

For a mutation tool with no output schema and full annotation coverage of the safety profile, the description supplies the two things an agent most needs: the correct id source and the unit convention. Minor gaps remain around side effects and confirmation of what the call returns.

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

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

Schema description coverage is 100%, so both budget_id and daily_amount are already documented, including the 'not a campaign ID' warning and the currency-unit note. The description reinforces but does not add meaning beyond the schema, so baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (日予算を変える = change daily budget) and resource, and explicitly distinguishes the target from the near-miss sibling concept by stressing the destination is the budget resource, not the campaign. An agent can route between this, google_ads_create_budget, and google_ads_update_status without opening schemas.

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

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

It tells the agent where to obtain the required id (google_ads_list_objects returns campaignBudget.id), which is concrete usage context. It does not state exclusions or when to prefer google_ads_mutate instead, so it stops short of full routing guidance.

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

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

The annotations only establish readOnly=false, destructive=false, and openWorld. The description adds real behavioral context beyond that: enabling may begin billing/charging, the accepted status is ENABLED not ACTIVE, and ad IDs require a composite 'ad group ID~ad ID' key. These are the exact gotchas an agent needs before mutating delivery state.

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

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

Dense and front-loaded: the primary action, the billing warning, the ID format caveat, and the deletion alternative are each one tight clause with zero padding.

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

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

With no output schema and annotations already covering the safety profile, the description still supplies the operationally critical details (billing risk, status value, ID format, delete alternative). Nothing an agent needs to invoke this status-change tool correctly is missing.

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

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

Schema description coverage is 100%, so all four parameters are already documented in the schema (including the composite-key note and the customer_id default). The description reinforces the composite-key format for kind=ad but adds no new parameter syntax beyond the schema, so the 3 baseline applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (start/stop delivery) plus the three target resources (campaign/ad_group/ad), and explicitly routes deletion to the sibling google_ads_remove. The agent can distinguish this from google_ads_remove and the create_* siblings without opening a schema.

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

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

Gives explicit conditions: use this to ENABLE/PAUSE, use google_ads_remove to delete. Also clarifies the ACTIVE-vs-ENABLED terminology confusion. It does not address when to prefer this over google_ads_mutate, which is a plausible alternative for status changes, so it stops short of full when-not coverage.

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