AdsAgent — Google Ads MCP

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

Beyond the destructiveHint/openWorldHint annotations, it discloses a lot: sequential non-atomic execution at the provider, stop-on-failure behavior, per-item receipts, idempotent repeat semantics with quota-deferred resume after retry_at bounded by approval expiry, and that only registered executors with current permissions run. This is unusually rich behavioral context for a mutation tool.

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 core action is front-loaded, but the text is bloated and repetitive ('present one approval' and 'ask for one confirmation of the whole displayed plan' restate the same rule, and the expiry/retry_at rule is given twice). Much of it is agent chat-presentation policy rather than guidance for invoking this tool, which crowds out the operative information.

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, multi-resource, no-output-schema tool, the description covers failure handling, idempotency, permissions and item-level outcomes. It stops short of describing the receipt/result shape an agent should expect back, and omits the connection_context parameter.

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?

With 0% schema description coverage the description must carry the parameters, and it does substantially: approval_ref identifies the stored plan, expected_plan_digest must match, and expected_changes must be the exact values from prepare so the host can inspect targets and effects. Only connection_context is left unexplained.

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 (execute) and resource (the stored mixed advertising plan identified by approval_ref/expected_plan_digest), and it implicitly distinguishes itself from the prepare step by requiring values 'returned by prepare'. It does not name the sibling confirm/deny/get tools, so the differentiation is inferred rather than stated.

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 clearly states the precondition (explicit user approval of every displayed item) and several exclusions (never replay an uncertain write, never retry a host safety denial, changed/expired plans require review), plus the quota-deferred resume path. It never names approval_plan_prepare, approval_plan_deny or approval_plan_get as the alternatives, leaving routing to inference.

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?

Goes well beyond the annotations (destructiveHint=true). Explicitly states what is preserved ('preserving completed receipts') and that there are 'no Google changes', which are non-obvious and important behavioral guarantees that the structured fields do not 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?

Single sentence, front-loaded with the action and immediately followed by the two key behavioral guarantees. Zero 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?

Behavioral context is strong for a denial operation, but the 0% parameter coverage and absence of output schema mean the agent gets no guidance on approval_ref format or what expected_plan_digest is for. Complete enough to attempt the call, not to call it correctly under all conditions.

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 0% and there are no parameter descriptions anywhere. The description mentions 'prepared or quota-waiting' but does not explain approval_ref, expected_plan_digest (e.g., concurrency guard, stale plan detection), or connection_context. With three undocumented parameters, this is a significant gap.

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?

Clear verb+resource: 'Discard a prepared or quota-waiting mixed approval'. The qualifier 'mixed approval' and scope 'prepared or quota-waiting' distinguishes it from siblings like approval_plan_confirm (which proceeds) and approval_plan_get (reads). Not a perfect 5 because 'mixed approval' is an undefined term for external readers.

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 description scopes the action to 'prepared or quota-waiting' approvals, implicitly excluding already-confirmed ones. However, it does not explicitly name approval_plan_confirm as the alternative or state when to deny vs confirm, leaving some inference to the agent.

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, openWorldHint=false and destructiveHint=false, so the safety profile is fully covered. The description adds the useful detail that no live provider request is made, but that largely restates readOnly + no-network and discloses nothing about what state is read or how stale the stored plan may be.

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 front-loaded sentences with zero filler; the read-only/no-write constraint is stated immediately after the purpose.

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 agent gets only a hint that receipts are returned and no idea of the response shape, status fields, or failure modes. For a read tool whose safety annotations are complete, this is adequate but thin.

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 0%, so the description must carry parameter meaning, and it does not. 'one stored approval' loosely ties to approval_ref, but connection_context (with its mctx_v1_ pattern) is never explained and there is no indication how either value is obtained.

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 (Read) and resource (one stored mixed approval plus its receipts), and the phrasing implies it is the retrieval counterpart to approval_plan_prepare/confirm/deny. It does not explicitly name a sibling to contrast against, and 'mixed approval' is internal jargon an outsider cannot fully decode.

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 'No provider requests or writes' clause signals this is a safe pure-read path, but there is no explicit when-to-use guidance such as 'use after approval_plan_prepare to inspect a plan' or when to prefer approval_plan_confirm/deny. Usage is only implied by the name and sibling set.

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 declaring readOnlyHint=false and destructiveHint=false, the description carries substantial extra load: it states a private approval is stored, no advertising changes are sent, the approval is immutable, source drafts are consumed as members and cannot be confirmed individually, and it defines the waiting_quota confirmation-retention semantics and the no-replay/no-retry rules for uncertain writes and safety denials. These are real behavioral traits not conveyed by 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?

The purpose is front-loaded in sentence one, but the body runs long as a single dense block mixing workflow policy, error semantics, and a trailing parameter note. Sentences like 'Report each completed, submitted, waiting, failed or uncertain item accurately' are generic and dilute the sharper content. Content mostly earns its place, but structure could be tighter and better grouped.

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 does an adequate job covering return-relevant behavior: approval refs, draft IDs, digests, tokens, plan states, and expiry handling, plus where that data should be surfaced. Nested source_urls is addressed. Minor gaps remain, such as the unexplained connection_context parameter and no note on the shape of the prepared plan object.

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 0%, so the description must compensate. It explains that draft_ids are owned/unexpired/unconfirmed and capped at 1–20, and that source_urls must be keyed by draft ID for video uploads with URLs encrypted at rest and omitted from review. The third parameter, connection_context, is never mentioned in the description or schema, leaving one gap.

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 first sentence gives a specific verb and resource with concrete scope: 'Combine 1–20 owned, unexpired, unconfirmed advertising drafts into one immutable approval.' It also clarifies that no advertising changes are sent, which separates it from the confirm step. It never names its siblings (approval_plan_confirm/deny/get) explicitly, so differentiation is inferred from the workflow rather than stated.

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 clear usage context: this is the prepare step of a prepare/confirm flow, drafts cannot be confirmed separately, and the agent must 'ask for one confirmation of the whole displayed plan.' It also handles the waiting_quota resume case and the changed/expired-plan re-review case. It does not state when to choose this over the sibling approval tools, but the implied workflow is unambiguous.

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?

Goes well beyond the readOnlyHint annotation by disclosing quota behavior (MCP does not report remaining quota), the daily-cap error path, the exact supported MIME types, the 500 MiB size ceiling, and the mapping of failure conditions to error_codes and next_action values. This is unusually rich for a status tool.

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-loaded purpose, then tightly packed operational facts. Dense but every sentence carries information an agent needs; the enumeration of MIME types and error codes is verbose but justified by their absence from any output 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?

With no output schema, the description carries the return-shape burden and does so well by naming the fields an agent must react to (next_action, bind_url, error_code). It does not describe the success-path payload structure, which is the 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?

One parameter (connection_context) with 0% schema description coverage, and the description never explains it. It is likely a system-injected context token, so the gap is tolerable, but the description does nothing to compensate.

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?

Opens with a specific verb+resource+scope: 'Read-only Google Drive cloud-library status for the current user.' It explicitly disambiguates from a near sibling ('This is not the upload library'), which is exactly the differentiation an agent needs.

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 concrete operational guidance: when next_action is bind_in_browser/rebind_in_browser, surface bind_url, and clarifies that binding is done by a person in the dashboard rather than settings. It does not, however, state when to prefer this over creatives_list_cloud.

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 readOnlyHint/destructiveHint annotations, it discloses non-obvious behavior: empty folders are absent, no month parameter exists, null modified_time can't be month-bucketed, indexed_at is ingestion time not file month, and which error_codes block ad use. This is exactly the context annotations cannot 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?

Long but dense—nearly every sentence carries a constraint (size limits, type list, error semantics). Front-loaded with the core purpose, though the size/type enumeration could be tightened.

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?

No output schema exists, so the description carries return-value burden and does: it names the returned fields (modified_time, indexed_at, error_code) and their semantics. Combined with the constraints, an agent has enough to call and interpret results.

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 only 25% (only parent_id documented in-schema), and the description richly explains parent_id (not a URL, not an upload-library id) plus the deliberate absence of a month filter. However, q and limit remain unexplained in both schema and description, leaving gaps for two of four params.

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 ('List files from the Google Drive cloud-library index') and explicitly distinguishes itself from creatives_list_folders and the upload library. An agent can identify the tool 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?

Explicitly negates two alternatives (creatives_list_folders, upload library) and clarifies parent_id's provenance and what it is not. Lacks a positive 'use this when...' framing, but the negative routing is strong enough to steer selection.

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, destructiveHint=false and openWorldHint=false, so safety is covered. The description earns credit by adding behavioral context beyond that: discovery does not confer permission and restricted qualifications stay unverified, which tells the agent how to interpret the returned status.

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 sentences, no filler, with the read-only scope stated first and the caveat second. It is tight, though 'base evidence' and 'discovery' are jargon that cost clarity without costing many 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?

For a low-risk read-only tool with no output schema and only two parameters, this is minimally sufficient: the agent knows what it reads and that results carry caveats. However, what 'base evidence' actually returns and how the snapshot relates to eligibility remain unspecified, leaving a real gap for a discovery-style call.

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 only 50%: customer_id is documented in the schema, but connection_context (a strict mctx_v1_ pattern token) is undocumented. The description adds nothing about either parameter, so it fails to compensate for the coverage gap.

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 concrete verb ('Read') and enumerates the resource it returns: account status, currency, timezone and 'base evidence'. That is clear enough for an agent to know what it fetches, but nothing distinguishes it from nearby siblings like google_ads_accounts_list, google_ads_accounts_pull or setup_get_status, and the connection to 'eligibility' in the tool name is never made explicit.

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?

There is no statement of when to call this versus the many accounts_* and setup_* siblings. The line about discovery not granting permission is a caveat about interpreting results, not guidance on tool selection. An agent must guess its place in the workflow.

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 safety is covered. The description adds genuine behavioral context beyond that: manager accounts appear in the result but are unusable for metrics, and results come from synced data unless overridden. Return format and pagination remain undisclosed, keeping it out of 5 territory.

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 sentences with no filler; the verb+resource leads and the caveat follows. Slightly dense in the second sentence, but every clause carries information an agent needs.

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 only partial parameter documentation, the description should say more about what the returned accounts look like and how connection_context must be supplied. The metric-eligibility caveat is valuable but leaves the auth parameter and result shape unaddressed.

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 50%: the 'source' enum is fully documented in the schema, and the description reinforces its default ('synced data by default'). connection_context has no description anywhere, and the description does not compensate. Baseline 3 is appropriate since the schema carries most of the parameter meaning.

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 ('List accessible Google Ads accounts') and scopes it to synced data by default. It does not name or contrast with the closely related siblings google_ads_accounts_pull, google_ads_accounts_sync, or google_ads_connections_list, so the agent must infer which of these to pick.

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 states a meaningful precondition for downstream use ('only enabled non-manager accounts can' be queried for metrics), which implies the tool's role. But it never says when to call this versus the pull/sync/connections siblings, and there is no explicit exclusion guidance, leaving selection to inference.

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?

Adds substantial context beyond the annotations: required permissions (mcp.assets.refresh, allow_pull), the customer_not_owned error for out-of-tenant accounts, quota/time budget behavior, and the empty-vs-needs_sync reading rule. 'No Google mutation' clarifies that refresh is local, consistent with destructiveHint=true referring to the local snapshot rather than Google state. It could still say more about what the local refresh destroys/overwrites.

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?

Single dense paragraph, front-loaded with the purpose and scope before the operational caveats. Sentences like the error-code and permission clauses earn their place, though the run-on packaging of quota, permissions, downstream reads, and empty semantics is heavier than needed.

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 write-to-local tool with no output schema and 2 undocumented params, the description covers most of what an agent needs: scope, permissions, quota, error behavior, and downstream read targets. The one gap is connection_context, which is neither in the schema nor the description.

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 0%, so the description must carry the parameter burden. It implies customer_ids ('named already-registered accounts', out-of-tenant returning customer_not_owned) but gives no format or limit guidance, and never mentions connection_context at all. Partial compensation only.

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 (Pull) plus exactly what is pulled: structure, daily and entity metrics, and the creative inventory. It immediately scopes the resource to 'named already-registered accounts only (no account discovery)', distinguishing it from discovery/list siblings, so an agent can identify it 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?

Clear when-to-use context: named already-registered accounts, no discovery, then read google_ads_insights_query_daily or the overview afterward. It also names the quota/time-budget constraints and the empty-vs-needs_sync interpretation. It does not explicitly contrast itself with the sibling google_ads_accounts_sync, which is the closest alternative, so the routing is slightly incomplete.

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 declare destructiveHint=true and readOnlyHint=false, and the description adds rich context beyond that: required permissions (mcp.assets.refresh, allow_pull), the exact scope boundary (no metrics/assets pull, no Google mutation, no MCC linking), and the fact that it reuses account discovery. This tells the agent precisely what state changes and what does not.

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 description is a tight, front-loaded block with no padding; each sentence carries prerequisite, scope, or sequencing information. It is dense with internal jargon (needs_sync, allow_pull, customer_not_owned) but does not waste 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?

No output schema exists, yet the description covers preconditions, scope limits, and the required post-sync re-read, so an agent knows how to invoke and sequence it. It stops short of full completeness only because parameter roles remain unstated.

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 0%, so the description must carry parameter meaning. It implies connection_ref identifies 'one owned connection', but connection_context is never explained, and neither parameter's format/role is clarified beyond the regex patterns already in the schema. This leaves most parameter semantics undocumented.

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 ('sync account registration for one owned connection') with explicit scope. It clearly separates itself from siblings like google_ads_accounts_list and the mutation/prepare-confirm pairs by naming what it does not do (no metrics/assets pull, no Google mutation, no MCC linking).

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 triggering conditions ('after needs_sync or a live-discovered account is missing from the ledger'), prerequisites ('Requires mcp.assets.refresh and allow_pull'), a follow-up action ('re-read google_ads_accounts_list before account reads'), and a caution ('Do not infer missing Google access from customer_not_owned'). This is a full when/when-not/next-step specification.

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=false, so the safety profile is covered. The description adds only 'confirm' and 'draft'—no side effects, irreversibility, auth requirements, or rate-limit context beyond what annotations provide.

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?

A single front-loaded sentence with no filler. It is appropriately terse for a confirm operation, though its extreme brevity overlaps with under-specification that other dimensions capture.

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 in a prepare/confirm pair, with a required but undocumented draft_id and no output schema, the description is too thin. It omits how the draft is produced and what confirmation actually results in.

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 only 33% (only customer_id is documented). The description mentions no parameters at all, so draft_id and connection_context receive no semantic clarification from either the description or 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?

States a verb and resource, but 'confirm' is ambiguous about whether it executes creation, validates approval, or finalizes a draft. It does not differentiate from google_ads_ad_group_create_prepare or other confirm siblings, leaving the actual effect vague.

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 guidance, no mention that it should follow google_ads_ad_group_create_prepare, and no prerequisites or alternatives are named. The agent must infer the prepare/confirm workflow from the tool name alone.

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=false, so the safety profile is partly covered. The description does add one genuinely useful behavioral fact beyond the annotations: the created ad group is paused. It does not, however, explain the prepare/confirm handshake, whether anything is mutated before confirmation, or how long the preparation remains valid.

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?

It is a single front-loaded sentence with no wasted words, which is structurally fine. But at six words it is under-specified rather than truly concise, omitting information the caller needs.

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 six-parameter mutation tool with 17% schema coverage, no output schema and no annotations covering the workflow, the description omits the two-step prepare/confirm contract, all non-trivial parameter meaning, and what the caller receives or does after preparing. It leaves too much to be inferred from sibling names.

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 only 17% (just customer_id), so the description carries the burden of clarifying name, campaign_id, ad_group_type, cpc_bid_micros and connection_context. It adds nothing about any parameter — not the micros unit for cpc_bid_micros, not the allowed ad_group_type values, and not the meaning of connection_context.

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?

"Prepare creating a paused ad group" names a verb (prepare) and a resource (ad group), and the word "paused" hints at the resulting state. However, the bare verb "prepare" is ambiguous on its own (draft? task? step in a workflow?) and the description never distinguishes this tool from its obvious sibling google_ads_ad_group_create_confirm, so an agent cannot fully route between them from the text alone.

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?

There is no when-to-use guidance, no statement that this is the first step of a prepare/confirm pair, and no mention of prerequisites such as an existing campaign or the need to later call the confirm tool. The only routing signal comes from the sibling tool names, not the description.

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 flag destructiveHint=true, and the description adds real behavioral context beyond that: approval gating, draft matching, verification of operation kind/approval integrity/state drift before sending, and a no-replay rule for uncertain outcomes.

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 dense sentences, front-loaded with the action and gate, followed by acceptance constraints and the failure-handling rule. 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 destructive, no-output-schema mutation tool this covers approval, validation, and uncertain-outcome handling well. It stops short of describing error/failure surfaces or what a successful confirmation returns, which leaves a small 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 only 33% – only customer_id is documented in the schema. The description adds meaning for draft_id by tying it to the prepare step, but says nothing about customer_id or the connection_context token, so it only partially compensates for the coverage gap.

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 ('change one supported ad's status'), names the exact allowed values (PAUSED or ENABLED), and explicitly ties itself to the sibling google_ads_ad_status_update_prepare, distinguishing it from the other confirm tools.

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 preconditions ('After explicit approval', 'Accepts only a matching draft from google_ads_ad_status_update_prepare'), an explicit prohibition ('Uncertain outcomes must be reconciled without replay'), and the reconciliation route instead of retrying.

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 tell the agent this is a non-read, non-destructive, closed-world operation. The description adds substantive behavior beyond that: it runs Google validate-only, saves a private draft plus a complete affected-resource snapshot, and explicitly does NOT send the change — the key fact an agent needs to avoid assuming the mutation happened.

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 purpose and behavior, ending with the required next action. No filler or redundant restatement of the 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?

With no output schema, the description carries the return-value burden and does explain the artifact produced (a private draft, validated, with a resource snapshot) and how to act on it. The remaining gap is the unexamined 'supported ad' restriction and how the agent should verify eligibility.

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 only 33% (only customer_id is documented; body fields and connection_context are not). The description partially compensates by identifying the target as a single supported ad and its status values, but it never explains customer_id format, connection_context, or what 'supported' excludes. Baseline 3 given the partial compensation.

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 ('Prepare to change ... ad's status to PAUSED or ENABLED'), scopes it to 'one supported ad', and names the enum values. It is clearly distinguishable from its confirm sibling, which it names explicitly.

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 description lays out the full workflow condition: call this to stage the change, show the draft for explicit approval, then call google_ads_ad_status_update_confirm. Use-of-alternative is explicit rather than implied.

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 known. The description adds real value beyond that: it requires explicit approval, discloses internal verification of operation kind, approval integrity and state drift, and states a no-replay reconciliation policy for uncertain outcomes. It does not say whether the replacement is reversible or what a partial failure returns, keeping it short of a 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?

Three tight sentences, each carrying distinct information: action/scope first, then the input precondition, then verification and reconciliation behavior. No filler and the most decision-relevant fact (approval required) 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 destructive confirm tool with no output schema and only safety annotations, the description covers the approval gate, validation steps, and failure-handling policy an agent needs. It stops short of describing the success/failure response shape or partial-application semantics, which are minor gaps given no output schema exists.

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 low (33%): only customer_id is documented in the schema. The description meaningfully clarifies draft_id by requiring a matching draft from the prepare tool, but says nothing about connection_context and adds no format or constraint detail for customer_id. Partial compensation for a low-coverage schema lands at 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 (replace) and resource (Display, Demand Gen or App ad headlines and descriptions) with an explicit scope (the explicitly listed ad groups). It also names the sibling it depends on (google_ads_ad_text_update_prepare), so an agent can distinguish it from the prepare step and the many other *_confirm tools 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?

Gives a clear precondition ("After explicit approval") and a hard input constraint ("Accepts only a matching draft from google_ads_ad_text_update_prepare"). It also implies the correct path for ambiguous results ("reconciled without replay"), though it never names google_ads_mutation_reconcile as the alternative, leaving the agent to infer the tool.

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 say readOnlyHint=false and destructiveHint=false; the description adds substantial behavioral context beyond them: it saves a private draft, runs Google validate-only, takes a complete affected-resource snapshot, and crucially does not send the change. That is exactly what an agent needs to know about a mutation-prepare tool. Auth requirements and rate limits are not covered, hence not a 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 tight sentences with the core scope front-loaded ahead of the workflow and safety note. No filler; slightly dense but every clause earns its place.

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 nested-body mutation-prepare tool with no output schema, the description covers the workflow, the safety stance (no send), and the handoff to confirm. It could add a note on what the draft/snapshot returns, but nothing essential 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 only 33%, so the description must carry param meaning. It maps well to headlines, descriptions, and affected_ad_group_ids ('explicitly listed ad groups'), but leaves ad_id and the ad_format enum (DISPLAY/DEMAND_GEN/APP) implicit. It partially, not fully, compensates for the coverage gap.

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?

Specific verb (replace) plus resource (Display/Demand Gen/App ad headlines and descriptions) and scope (explicitly listed ad groups). It also names the sibling google_ads_ad_text_update_confirm, so an agent can distinguish this prepare step from the confirm step 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?

Explicitly states the next step and the condition that gates it: show the draft for approval before calling google_ads_ad_text_update_confirm. It does not state when NOT to use this tool or other alternatives, but the prepare/confirm routing 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, destructiveHint=false and openWorldHint=false, so the safety profile is covered and the description carries a lower bar. It nonetheless adds nothing beyond the name: no indication of whether families are static or connection-scoped, and no return shape (there is no output schema either).

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?

A single front-loaded sentence with no filler, which is proportionate for a simple read-only listing tool. The sparseness is a completeness problem more than a structural one, so it stays at 4 rather than 5.

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 one-parameter, no-output-schema listing tool, an agent still needs to know what a "family" is and what the response looks like, neither of which is stated. Safety behavior is covered by annotations, so the remaining gap is the opaque connection_context and undefined return values.

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 connection_context has 0% schema description coverage and a strict regex pattern, yet the description says nothing about it — not whether it is optional, what a connection context represents, or when it must be supplied. With a parameter present the baseline-4 zero-parameter allowance does not apply, and the description fails to compensate.

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 ("List supported deep-analysis families"), which is clearly distinct from the sibling google_ads_deep_analysis_query/export that consume those families. It stops short of naming that relationship explicitly, so an agent must infer that this is the enumeration step preceding a deep-analysis query.

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 guidance, no prerequisites, and no mention of the two obvious sibling tools (google_ads_deep_analysis_query, google_ads_deep_analysis_export) that the returned families presumably feed into. The agent is left to guess why it would call this list.

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 readOnly, non-destructive, and non-open-world, so the safety profile is covered. The description adds genuine behavioral context beyond that: the output is evidence rather than approval, and per-asset attribution should not be fabricated. That tells the agent how to treat the results, not just that the call is safe.

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 no filler, and the scope statement is front-loaded before the caveat. The phrasing of the caveat ('no invented per-asset attribution') is terse enough to be slightly cryptic, but nothing is wasted.

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 nested-body diagnostics tool with no output schema and two-thirds of parameters undocumented, the description does not explain the shape or meaning of the result, what distinguishes 'policy' coverage from 'observed' coverage, or what the date range controls. Annotations cover safety but the functional gaps remain large.

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 only 33% — just customer_id ('10-digit Google Ads customer id'). The nested body fields (campaign_id, date_from, date_to) and connection_context carry no description in either the schema or the tool description, and the description contributes no parameter meaning at all, so it fails to compensate for the low coverage.

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 verb ('Read') and resource area ('policy and observed asset coverage evidence with campaign metrics') are stated, so an agent knows this is a read-oriented diagnostics call. However, 'coverage evidence' is abstract jargon and the description never differentiates it from close siblings such as google_ads_asset_inventory_list or google_ads_asset_requirements_get. The agent can guess the domain but not what it actually returns.

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?

There is no when-to-use statement and no named alternative among the many asset-related siblings. The only guidance present ('Missing policy is not approval') is an interpretation caveat about the data, not a condition for selecting this tool over another.

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 write/safety profile is covered. The description adds genuinely new context beyond that: approval gating, operation-kind and state-drift verification before sending, and the no-replay reconciliation rule. It stops short of describing what a partial failure leaves behind or the response shape, so not a 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?

Three tight sentences with no filler; the precondition leads and the verification/reconciliation behavior follows. Every clause carries operational weight.

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 confirm tool with no output schema, the description covers approval, input provenance, pre-send validation, and the uncertain-outcome rule. It omits what success returns or how a rejected draft surfaces, which keeps it short of 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 coverage is only 33%, with customer_id described and draft_id and connection_context bare. The description compensates for draft_id by defining it as a draft produced by the prepare tool, but adds nothing about connection_context or the customer id format beyond the schema. Partial compensation justifies the mid 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 resource ('link an existing asset to a Performance Max asset group') and names the sibling that produces its required input (google_ads_asset_group_link_prepare). An agent can distinguish it from google_ads_asset_link_confirm and the unlink variants 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?

Gives an explicit precondition ('After explicit approval'), restricts valid input to a matching draft from the prepare tool, and prescribes behavior for the uncertain-outcome case ('reconciled without replay'). When-to-use, prerequisite, and failure-path guidance are all present.

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 declare readOnlyHint=false, destructiveHint=false, openWorldHint=false. The description adds genuinely new behavior: Google validate-only execution, a private persisted draft, a 'complete affected-resource snapshot', and the fact that no change is actually sent. That resolves the ambiguity of a mutating-looking tool that does not mutate.

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 sentences, all load-bearing: what it does, what it persists/does not send, and the required approval step. The purpose is front-loaded and there is 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 prepare/stage tool with no output schema, the description covers the workflow, the side effect (draft + snapshot) and the handoff to confirm, and 'Show the draft' implies the draft is returned. It stops short of describing what the draft object contains or how long it stays valid, which is the only 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 coverage is only 33% (only customer_id is documented), so the description must compensate. It conveys that an asset and an asset group are involved, mapping to asset_id and asset_group_id, but says nothing about field_type (the enum that determines placement) or connection_context. Partial compensation only.

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 ('prepare to link an existing asset to a Performance Max asset group') and explicitly distinguishes itself from the sibling google_ads_asset_group_link_confirm, which it names. An agent can pick it 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?

Gives explicit ordering: call this to stage, show the draft for approval, then call google_ads_asset_group_link_confirm. It also names the alternative sibling, so the when-to-use and when-to-use-next conditions are both covered.

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 mutation profile is covered. The description adds substantive context beyond that: pre-send verification of operation kind, approval integrity and state drift, plus the rule that uncertain outcomes must be reconciled rather than replayed. It stops short of disclosing reversibility or downstream effects on the Performance Max campaign.

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 dense sentences, no filler. The approval prerequisite and draft binding come first, then verification behavior, then failure handling, which is the correct order for an agent deciding whether it may invoke this.

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?

No output schema exists, but the description covers the invocation precondition, the pre-send checks and the failure-mode policy. What remains missing is what the tool returns on success and how the caller should reconcile an uncertain result.

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 only 33% (only customer_id is documented). The description gives some meaning to draft_id by tying it to the prepare sibling's output, but connection_context and its mctx_v1 format are explained nowhere, and no parameter formats, constraints or error conditions are added.

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: remove an existing asset link from a Performance Max asset group. This distinguishes it from the many sibling confirm/prepare pairs, including the non-asset-group google_ads_asset_unlink_confirm and the opposite-direction google_ads_asset_group_link_confirm.

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?

Explicit prerequisites and routing: 'After explicit approval' and 'Accepts only a matching draft from google_ads_asset_group_unlink_prepare'. An agent knows it must first call the prepare sibling and cannot substitute a draft from a different operation.

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?

Goes well beyond the annotations by disclosing that the tool runs a Google validate-only pass, captures a complete affected-resource snapshot, stores a private draft, and does not transmit the change. That behavior (a prepare/draft that is non-destructive but writes state, consistent with readOnlyHint=false and destructiveHint=false) is not inferable from the structured fields.

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 sentences, front-loaded with purpose, then behavior, then the required follow-up step. Every sentence adds information; no filler or restatement of the tool name.

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 a nested body object, the description still conveys what the tool produces (a private draft plus snapshot) and the required downstream call. The main remaining gap is the undocumented field_type enum, which the agent must infer from the schema alone.

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 only 33% (just customer_id), and the description adds no parameter-level meaning. The nested body fields asset_group_id, asset_id, and especially field_type (an enum of link types) are never explained in prose, so the description does not compensate for the coverage gap.

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: prepare removal of an existing asset link from a Performance Max asset group. It is clearly distinguishable from the sibling google_ads_asset_group_link_prepare (adds vs removes) and google_ads_asset_unlink_prepare (asset-group level vs asset level). No tautology.

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 states the workflow: prepare a draft, show it for approval, then call google_ads_asset_group_unlink_confirm. The named alternative and the gating condition are clear, though it never states when NOT to choose this over the plain asset-level unlink prepare.

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 flag destructiveHint=true and openWorldHint=false, but the description adds genuinely non-redundant behavior: it verifies operation kind, approval integrity and state drift before sending, and it warns that uncertain outcomes must not be replayed. That replay/idempotency guidance is not derivable from the annotations and is the highest-value content here.

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 action and gated on approval before any mechanism detail. Slightly dense with unglossed terms like 'operation kind' and 'state drift', but no filler sentences.

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 confirm tool with no output schema, the description covers the approval gate, input provenance, pre-send verification and failure handling. It stops short of saying what the agent should do next on an uncertain outcome beyond 'reconcile', which is a small gap against the 33% param coverage.

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 only 33% (only customer_id is described), so the description carries extra burden. It does clarify that draft_id must be a 'matching draft' produced by the prepare tool, which adds real meaning, but connection_context and the draft_id format remain undocumented in both description and 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?

States a specific verb and resource: 'replace a Performance Max asset group's status or final URLs.' It is immediately distinguishable from its prepare sibling, which the description names explicitly, so an agent knows this is the execution half of a two-step flow.

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 precondition ('After explicit approval'), a hard input constraint ('Accepts only a matching draft from google_ads_asset_group_update_prepare'), and an anti-pattern ('Uncertain outcomes must be reconciled without replay'). It lacks a pointer to the concrete reconciliation path (e.g. google_ads_mutation_reconcile), which is the only missing routing hint.

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 cover safety flags (write-but-not-destructive, non-open-world); the description adds real behavior: a private draft is saved, Google validate-only runs, a complete affected-resource snapshot is captured, and no change is sent. That is meaningful context an agent needs before calling.

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 sentences, purpose front-loaded, each sentence adding distinct information (what it does, how it validates/stores, what to do next). 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?

Complete enough for a prepare tool: purpose, validation, snapshot, and next step are stated, and no output schema exists to duplicate. It does not say what the response contains (e.g., a draft/plan identifier) or how the draft is retrieved, which is a minor gap for the approval handoff.

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 only 33% (only customer_id is documented), so the description must compensate. It does name the two key body fields (status, final URLs), but says nothing about asset_group_id, the enum values, the URL array limits, or connection_context. Baseline 3 for partial compensation.

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: 'Prepare to replace a Performance Max asset group's status or final URLs,' naming the exact mutable fields and entity. It is immediately distinguishable from the sibling google_ads_asset_group_update_confirm, which it names.

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 sequencing: prepare first, then 'Show the draft for explicit approval before calling google_ads_asset_group_update_confirm.' It also states the negative condition ('does not send the change'), so the agent knows not to use this for execution.

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=false and openWorldHint=false, so the safety profile is covered. The description adds substantive behavior beyond that: snapshot-bound pagination, the 'unknown, not empty' semantic for unsynced data, and the no-live-pull guarantee. It omits freshness/rate-limit or auth details, so not a 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?

Three tight sentences with the core purpose front-loaded and no filler. Each sentence adds a distinct, load-bearing constraint (snapshot source, unknown-vs-empty semantics, pagination rule).

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 7-parameter read tool with no output schema and low schema coverage, the description supplies the key behavioral caveats but leaves most parameters unexplained. It is adequate for the tool's core semantics but incomplete for correct invocation of its filters.

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 only 14% (just customer_id documented), so the description must carry parameter meaning. It only partially does: it explains continuation must be paired with the same customer and filters, but sort, search, page_size, asset_type and connection_context remain undocumented in both schema and description.

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: reading the last complete stored creative inventory, and clarifies it is a stored snapshot rather than a live Google pull. It does not name the closest sibling (google_ads_assets_list) to disambiguate, so an agent must infer which inventory source it wants.

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?

Provides an explicit rule for continuation reuse ('same customer and filters') and warns that missing sync means unknown, not empty, and that it never pulls live data. However, it never states when to prefer this tool over siblings like google_ads_assets_list or creatives_list_cloud, leaving the selection decision implicit.

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 covered structurally. The description adds nothing beyond that: it does not state that the draft becomes live, whether the action is reversible, whether the draft is consumed, or any permission requirements. With annotations carrying the safety burden, the added context here is close to zero.

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?

A single front-loaded sentence with no filler or repetition. It is appropriately short for its content, though brevity here stems partly from under-specification rather than disciplined editing.

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 mutation tool with no output schema and two-thirds of its parameters undocumented, the definition is materially incomplete. The essential workflow facts — that a draft_id from a prepare step is required and that this commits the change — are absent, leaving the agent dependent on inference from sibling names.

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 only 33% — customer_id is documented, but draft_id and connection_context are not. The description adds no parameter meaning whatsoever; the phrase "asset-link draft" only faintly hints that draft_id identifies a previously prepared draft. It does not compensate for the coverage gap.

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 names a specific verb and resource ("confirm" + "asset-link draft"), so it is more than a bare tautology. However, it never explains what confirming actually does (applies/commits the prepared draft) and gives no differentiation from the many sibling confirm tools (asset_group_link_confirm, asset_unlink_confirm, etc.) beyond the resource word in the name.

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?

There is no when-to-use guidance. Critically, the description never says a draft must first be created via the sibling google_ads_asset_link_prepare tool, nor what conditions make confirming appropriate versus abandoning the draft. The agent must infer the entire prepare/confirm workflow from naming conventions alone.

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 declare readOnlyHint=false, destructiveHint=false, openWorldHint=false, so the safety profile is partly covered. The description adds nothing beyond the word 'Prepare' – it does not say that no change is applied until the matching confirm tool runs, whether the prepared state expires, or what the tool returns to feed the confirm call.

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?

A single front-loaded sentence with no filler, naming the operation and its scope immediately. It is efficient, though the brevity is more under-specification than concision given the six-parameter surface.

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 six-parameter, four-required mutation-staging tool with no output schema and near-zero schema descriptions, the single sentence leaves major gaps: the confirm follow-up, the meaning of field_type/target_type values, and identification of the asset. Not sufficient for correct invocation.

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 only 17% (customer_id is the sole documented property), so the description must compensate. It lightly maps target_type by naming the four target kinds, but field_type, asset_resource_name, and target_id are given no meaning, and the expected connection_context pattern is never referenced.

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 ('Prepare linking') and resource ('an asset') plus the four candidate target scopes, so the intent is clear. What is missing is differentiation from the very similar sibling google_ads_asset_group_link_prepare, which the listed targets ('asset group') visibly overlap with.

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 guidance, no mention that this is the staging half of a prepare/confirm pair (google_ads_asset_link_confirm is a sibling), and no exclusions relative to asset_group_link_prepare or asset_unlink_prepare. The agent must infer the workflow from the naming pattern alone.

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, openWorldHint=false, destructiveHint=false, so the safe-read profile is covered. The description adds that results are scoped by channel type, but says nothing about output shape or whether requirements vary by customer, which would matter for a lookup tool.

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?

One short, front-loaded sentence with no waste. Appropriately sized, though it is perhaps too terse given the gaps in parameter semantics.

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?

A three-parameter lookup with no output schema and poor schema coverage needs more than one sentence. The absent enum for channel_type and the unexplained connection_context parameter are material omissions for an agent trying to call this correctly.

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 only 33%: customer_id is documented, but channel_type has no description and no enum, and connection_context is unexplained. The description does not compensate by listing valid channel types or explaining the connection_context requirement.

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: returns asset requirements for a channel type. Clear what it does, but doesn't differentiate from nearby creation-prep tools like google_ads_creation_capabilities_get or asset_upload_prepare which also touch asset requirements.

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 guidance on when to use this versus alternates such as google_ads_creation_capabilities_get, google_ads_field_metadata, or the asset_upload_prepare flow. The agent must infer that this is a lookup step before asset creation.

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, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds only that the page is bounded; it says nothing about ordering, default page contents, or truncation behavior beyond what the schema's limit description provides.

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?

A single compact sentence with no filler and the scope constraint ('one customer') front-loaded. It is perhaps too terse given the surrounding operational toolset, but nothing is wasted.

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 read-list tool in a large mutation-oriented sibling set, the description omits how results are ordered, what truncation metadata looks like (no output schema), and which alternative to use for inventory versus page listing. Annotations carry only the safety profile, so the gap is significant.

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 67% and the schema itself documents limit and customer_id, including bounds and truncation metadata. connection_context is undocumented in both schema and description, so the description adds no parameter meaning beyond the schema 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 (List) and resource (Google Ads creative assets) scoped to one customer. It is distinguishable from asset_upload/asset_link and from asset_inventory_list, though it doesn't explicitly differentiate from the closely named inventory list.

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 guidance, no exclusions, and no pointer to alternatives such as google_ads_asset_inventory_list or google_ads_asset_diagnostics. The description only supplies purpose, not selection context.

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 risky nature is signalled structurally. The description adds nothing beyond that: it does not say the unlink is irreversible, what the asset is being detached from, or whether a mutation receipt is returned. It essentially restates the title.

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?

One short, front-loaded sentence with zero filler. It is concise but that brevity comes at the cost of being under-specified for a destructive operation, so it earns a middling score rather than a high one.

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 mutation with no output schema and two of three parameters undocumented, the description is far too thin. It omits the prerequisite draft, the effect of confirmation, and any result information, leaving real gaps an agent would need to guess at.

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 only 33% (only customer_id is documented), and draft_id and connection_context are undocumented. The description mentions 'draft' but adds no format, source, or meaning for draft_id, so it fails to compensate for the coverage gap.

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 ('Confirm an asset-unlink draft'), so the agent knows this finalizes a pending unlink. However, it does not distinguish itself from the obvious sibling google_ads_asset_unlink_prepare, nor does it explain what 'confirm' actually executes. It is minimally viable rather than differentiating.

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?

There is no when-to-use guidance beyond the implicit requirement that a draft must already exist. The description never names google_ads_asset_unlink_prepare as the prerequisite step or explains when confirmation should be withheld, despite the whole family being built on a prepare/confirm workflow.

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 declare readOnlyHint=false and destructiveHint=false, which is somewhat counterintuitive for an 'unlink' operation but does signal that this call itself is non-destructive. The description adds nothing beyond restating the name: it does not explain that this stages a pending operation requiring confirmation, what state it leaves behind, or any 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?

A single, front-loaded sentence with no filler or repetition. It is efficient, though its terseness borders on under-specification for a 6-parameter mutation-staging tool.

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 tool with 6 parameters, low schema coverage, and no output schema, the description is inadequate. It omits the confirm follow-up, the meaning of the target/field parameters, and any behavioral context, leaving an agent unable to invoke it confidently without inspecting the schema.

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 only 17% (just customer_id), and the description does not compensate. The target levels mentioned loosely hint at target_type, but target_id, field_type, asset_resource_name, and connection_context remain undocumented in both schema and description, including no allowed values for the string-typed target_type/field_type.

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 ('Prepare unlinking') and resource ('an asset'), and enumerates the four target levels (customer/campaign/ad group/asset group). It is clearly understandable on its own, though it never explicitly distinguishes itself from the sibling google_ads_asset_unlink_confirm, leaving the prepare-vs-execute split to be inferred from the name.

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?

There is no guidance on when to use this tool versus alternatives, nor any mention that a prepare step is normally followed by google_ads_asset_unlink_confirm. The two-step staging workflow that the naming convention implies is left entirely unstated.

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 declare readOnlyHint=false (a write) but destructiveHint=false, so the safety profile is already given. The description usefully adds that confirmation requires re-sending identical data, implying an idempotency/verification check, but says nothing about failure behavior on a payload mismatch.

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?

A single front-loaded sentence with zero filler; the confirmation mechanism is stated first and no redundant restatement of the name or title is present.

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 confirm step with no output schema and annotations covering safety, the description covers the core mechanic but omits the link to the prepare step and the draft_id it generates, leaving the agent to infer the workflow.

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 only 20% (customer_id alone is documented), so the description must carry more weight. It does clarify the semantics of base64_data (must be the same data) and the gdrive: prefix for selection_key, but draft_id and content_type remain entirely unexplained.

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?

Clear specific verb ('Confirm') and resource ('image asset upload'), and it names the exact payload mechanism needed (same base64 data or same gdrive: selection_key). It reads clearly as the second half of the prepare/confirm pair with google_ads_asset_upload_prepare, though it never names that sibling explicitly.

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 'resubmitting the same base64 image data or the same gdrive: selection_key' clause is real guidance on how to invoke it, but there is no statement of when to call this versus the prepare step, what happens if the data differs, or any precondition tied to draft_id.

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 declare readOnlyHint=false, destructiveHint=false and openWorldHint=false, so safety is partly covered; the description's 'No Google mutate' usefully clarifies that the non-read-only flag reflects internal staging rather than an external write. It says nothing about whether an approval/task handle is produced, whether the prepared upload expires, or what permissions are required.

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, front-loaded with the action and input forms, with the scope-limiting 'No Google mutate' note kept to a fragment. No redundancy, though the clipped fragment style slightly reduces readability.

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 no annotations explaining staging behavior, the description should say what preparation yields (e.g. a task/receipt id) and what the agent does next. It covers the input contract but leaves the outcome and confirm handoff unstated for a 5-parameter, 4-required 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 only 20% (just customer_id), so the description must compensate. It does add real meaning for base64_data, which can be either raw base64 or a 'gdrive: selection_key' string, but filename, content_type and connection_context remain undocumented in both places.

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 ('Prepare an image asset upload') plus the accepted input forms, which cleanly distinguishes it from the sibling google_ads_asset_upload_confirm. It does not explicitly name that sibling, but the prepare/confirm naming and 'No Google mutate' make the stage 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?

Tells the agent two ways to supply the payload: raw base64 image data, or a 'gdrive: selection_key' obtained from creatives_list_cloud, which implicitly routes to that sibling for sourcing assets. It never states when not to use it or that a confirm step follows the prepare, so usage is only implied.

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 establish readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so safety is covered. The description adds genuinely new behavioral context: restricted services demand fresh server-verified access and will refuse otherwise, and no writes or access grants occur. It stops short of defining what 'restricted' or 'fresh' mean, but it clears the lower bar set by 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 tight sentences with the core read purpose front-loaded, followed by the access constraint and the no-write guarantee. Slightly jargon-heavy ('bounded native', 'fresh server-verified'), but 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?

No output schema exists and the input contains a required nested object with an enum-constrained dimension list, yet the description explains neither the request body shape nor the returned insight. For a tool with this schema complexity, the description leaves too much for the agent to infer.

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 only 33% — just customer_id is documented — and the description adds nothing about the nested body object, its required dimensions/query_text fields, the five-item dimension cap, or connection_context. With low coverage the description is expected to compensate and it does not.

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 (Read) and resource (native audience_attributes insight), which maps directly onto the tool name and distinguishes it from sibling data tools such as google_ads_audience_dates and google_ads_insights_overview_query. It does not, however, explain what the insight actually contains or how it differs from the other insight/audience siblings, so the differentiation is only implicit.

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 description gives an access precondition ('Restricted services require fresh server-verified access and otherwise refuse') but never says when to choose this tool over the many sibling insight and audience tools, nor when not to use it. Usage is only implied by the resource name.

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, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description does add real behavioral context beyond that: restricted services require fresh server-verified access and otherwise refuse, and there are no writes or access grants. The gap is that 'restricted services' is left undefined and no return/scope behavior is described.

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 with the purpose front-loaded and no filler. The phrasing is dense with undefined terms ('bounded', 'native', 'restricted services'), which costs a little clarity, but the structure is otherwise efficient.

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?

No output schema exists, so the description could carry more about what the insight returns, but it does not. For a read-only tool whose annotations already cover safety, it is minimally adequate, yet the empty body object and connection_context remain unexplained and the access precondition is vague. There are clear remaining gaps.

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 only 33%: customer_id is documented, but body (an empty nested object) and connection_context (pattern-only) are undocumented in both schema and description. The description adds no parameter meaning whatsoever, so it fails to compensate for the low coverage. With effectively one meaningful documented parameter, this is below 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?

The description gives a verb (Read) and a resource (audience_dates insight), so the general action is clear. However, 'bounded native audience_dates insight' is opaque jargon and the description never distinguishes this from close siblings like google_ads_audience_attributes or google_ads_benchmark_dates. An agent knows it reads something, but not clearly what or how it differs.

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?

There is no explicit when-to-use guidance and no named alternative among the many audience/insight siblings. The only conditional statement ('Restricted services require fresh server-verified access and otherwise refuse') is a precondition, not a routing rule. The agent must infer usage from the name alone.

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, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds that restricted services need fresh server-verified access and will otherwise refuse, which is genuine extra context about an auth/refusal behavior. It stops short of saying what happens on refusal or how fresh access is established.

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, purpose front-loaded, no padding. But two of the sentences are vague or redundant — "No writes or access grants" merely re-states the readOnlyHint annotation, and the access sentence is opaque rather than informative.

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?

No output schema, 33% param coverage, and a nested empty body object leave the agent without enough information to invoke this confidently. The description never explains what a "benchmark_dates" result contains or how it relates to the other benchmark endpoints.

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 only 33% (only customer_id is documented). The body is an empty object with additionalProperties=false and connection_context has a pattern but no prose, so the description's single word "bounded" is the only hint about what the body accepts or what the bounding constraint is. It does not compensate for the coverage gap.

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 verb ("Read") and a resource ("benchmark_dates insight"), so the basic action is legible. However, it largely restates the tool name and does nothing to distinguish it from the four sibling benchmark tools (benchmark_locations, benchmark_metrics, benchmark_products, benchmark_sources). What "dates" returns versus the other benchmark dimensions is left to inference.

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?

There is no statement of when to call this versus the benchmark_sources/locations/metrics/products siblings, nor any precondition tied to customer_id or connection_context. The only usage-adjacent sentence ("Restricted services require fresh server-verified access and otherwise refuse") is a cryptic constraint rather than guidance on tool selection.

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, destructiveHint=false, and openWorldHint=false, so "No writes or access grants" is largely redundant. The description does add one piece of context beyond annotations: that restricted services require fresh server-verified access and will otherwise refuse, which hints at an auth failure mode. It says nothing about rate limits, response shape, or what "bounded" means.

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 the action front-loaded, so it is not bloated. But the compression comes at the cost of clarity — phrases like "bounded native" and "access grants" are cryptic rather than efficient, so the brevity is only partially earned.

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 tool with a nested object parameter, an empty body schema, 33% schema coverage, and no output schema, the description is far too thin. It omits what the body should contain, what the response returns, and how this tool relates to its benchmark siblings.

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 only 33% (just customer_id), and the body parameter is an empty object with additionalProperties=false whose required fields or payload shape are entirely undocumented. The description provides no parameter information at all, so it fails to compensate for the low schema coverage.

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 verb ("Read") and a resource ("benchmark_locations insight"), so the basic action is discernible. However, the qualifiers "bounded native" are opaque jargon, and nothing distinguishes this from the many sibling benchmark tools (benchmark_dates, benchmark_metrics, benchmark_products, benchmark_sources). An agent must fall back on the tool name alone to tell it apart.

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 only guidance offered is an access constraint ("Restricted services require fresh server-verified access and otherwise refuse"), which is a precondition, not a when-to-use. No alternative tool is named and no scenario or exclusion is described, so the agent gets no routing help.

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 establish readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds genuinely useful context beyond that: restricted services need fresh server-verified access and otherwise refuse, and it explicitly disclaims writes and access grants. This helps the agent anticipate refusal behavior, though return format is still unexplained.

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 with the read-only nature and access constraint front-loaded; little waste. It loses a point for vague filler like 'bounded native' that consumes space without adding meaning.

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?

There is no output schema and the tool takes a rich nested body whose sub-fields are undocumented. The description omits what metrics are returned, the shape of the response, and guidance on the body payload, so it is not complete enough for an agent to call this correctly without additional assumptions.

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 only 33% (customer_id is documented, the nested body and connection_context are not), so the description should compensate and instead mentions no parameters at all. The required nested body fields (location_id, industry_vertical_id, product_codes, dates, currency_code) are left entirely to the schema, which does not describe 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?

The description states a verb and resource ('Read ... benchmark_metrics insight'), so the core purpose is inferable. However, the phrasing is jargon-heavy ('bounded native') and it offers no differentiation from the several sibling benchmark tools (google_ads_benchmark_dates, _locations, _products, _sources), leaving the agent to guess what is unique here.

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?

There is no when-to-use guidance and no comparison to alternatives. The sentence about 'restricted services require fresh server-verified access' is an access precondition rather than a statement of when this tool should be selected over siblings.

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, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds context beyond that: it discloses an authorization precondition (restricted services need fresh server-verified access and otherwise refuse) and reinforces scope ('No writes or access grants'). It stops short of explaining what 'bounded' means or what the refusal looks like, hence a 4 rather than a 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?

Three short sentences, front-loaded with the core read purpose before the caveats, with no filler. It loses a point only because the opening clause 'bounded native benchmark_products insight' is compressed to the point of being cryptic rather than efficient.

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 no explanation of what the 'benchmark_products insight' actually contains, the description leaves the agent unable to anticipate the return shape or the semantics of the body argument. For a 3-parameter tool with a nested object and low schema coverage, more explanation is required than 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 only 33%: only customer_id is documented ('10-digit Google Ads customer id'), while body and connection_context carry no description. The description adds nothing about any parameter, so it does not compensate for the gap. Notably it never explains the body object at all, which appears to have no properties, leaving the agent unclear on what to send.

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 names a verb ('Read') and a resource ('benchmark_products insight'), so the general intent is recoverable. But 'bounded native' is unexplained jargon, and the tool is not distinguished from its close siblings google_ads_benchmark_dates/locations/metrics/sources beyond the shared 'benchmark_products' label. An agent can guess the domain but not precisely what this returns.

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?

There is no statement of when to choose this tool over the four other google_ads_benchmark_* siblings, nor when-not to use it. The only conditional ('Restricted services require fresh server-verified access and otherwise refuse') is an auth precondition, not usage routing. No guidance is provided for the actual selection decision.

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=false, so 'No writes or access grants' largely restates structured data. The one genuine addition is that restricted services demand fresh server-verified access and otherwise refuse, which discloses an auth/failure behavior not in 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, front-loaded sentences with no filler; the read action leads and constraints follow. Slightly dense jargon ('bounded native') costs it the top score.

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 read-only tool with no output schema and safety annotations, the description covers the access constraint but omits return-shape expectations and leaves the empty required 'body' parameter unaddressed. Adequate but with visible gaps.

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 only 33%, yet the description says nothing about any parameter. The required 'body' object is empty with additionalProperties=false, which is unexplained, and connection_context's purpose is left to the schema pattern alone.

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 ('Read') and resource ('benchmark_sources insight'), and the resource name cleanly separates it from the benchmark_dates/locations/metrics/products siblings. The qualifier 'bounded native' is jargon that adds little precision, but the core action is identifiable.

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 guidance on when to choose this tool over the sibling benchmark_* tools, nor when it is appropriate versus google_ads_insights_* tools. The 'restricted services require fresh server-verified access' line is a precondition, not usage routing.

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, readOnlyHint=false and openWorldHint=false, so the safety profile is covered structurally. The description adds nothing beyond that: it does not state that the change is applied irreversibly, what gets mutated, or whether confirmation consumes/invalidates the draft.

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?

A single front-loaded sentence with no filler or redundancy. It is appropriately terse, though the brevity borders on under-specification rather than deliberate economy.

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 mutation in a two-phase confirm flow with no output schema and sparse parameter documentation, the description omits prerequisites (draft must exist), the irreversible nature of confirmation, and any indication of what the agent receives back. It is not sufficient to call the tool correctly with confidence.

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 only 33% (only customer_id is documented). draft_id and connection_context have no schema description, and the description supplies no meaning for them, nor does it clarify that draft_id comes from the prepare step. The description fails to compensate for the low coverage.

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 ('Confirm') and resource ('bidding update draft'), and the name pair with google_ads_bidding_update_prepare makes the two-phase flow evident. However, the description never explains what confirming actually does (execute/apply the drafted bid change), so it is clear but not fully differentiated in the text itself.

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 guidance, no stated prerequisite that a draft must first exist via google_ads_bidding_update_prepare, and no mention of when confirmation is inappropriate. The agent must infer the entire prepare-then-confirm workflow from sibling naming.

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 state readOnlyHint=false, destructiveHint=false and openWorldHint=false, so the safety profile is partly covered. However, the description never explains the defining behavioral trait of a 'prepare' tool in this family — that it stages a change and does not apply it until confirm — nor does it mention permissions or approval 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?

It is a single clean, front-loaded sentence with no filler, which is structurally fine. But at eight words it is under-specified rather than concise — the brevity comes at the cost of all actionable detail.

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 six-parameter mutation-staging tool with no output schema and near-empty parameter coverage, the description should carry the workflow and parameter burden. It omits the confirm counterpart, what the prepare step returns, and the meaning of the strategy/roas/amount_micros 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 only 17% (just customer_id), leaving strategy, roas, amount_micros, campaign_id and connection_context undocumented. The phrase 'bidding strategy' loosely gestures at the strategy param but supplies none of the allowed strategy values or the ROAS/micros relationship, so it fails to compensate for the coverage gap.

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 pairs a specific verb ('Prepare updating') with a specific resource ('a campaign bidding strategy'), so the agent knows exactly which object is touched. It does not, however, distinguish this from its sibling google_ads_bidding_update_confirm or explain what 'prepare' produces, so it stops short of a 5.

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?

There is no when-to-use guidance, no mention of the required follow-up confirm step, and no reference to alternatives despite a near-identical confirm sibling in the tool list. The agent must infer the two-phase workflow entirely from naming.

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, openWorldHint=false and destructiveHint=false, so the safety profile is covered. The description adds real value by disclosing the default read source and explicitly bounding scope ('No invoice retrieval'), but it says nothing about what the returned setup contains or freshness/auth requirements beyond the ledger/live distinction.

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, front-loaded sentences with no filler. It is efficient, though the terse phrasing ('Billing setup for one customer') leans on the tool name to disambiguate that this is a read.

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 read-only tool with annotations covering safety and no output schema, the description covers scope but not the shape of the returned billing setup. It is adequate but leaves a gap an agent would want filled given the missing output schema.

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 67%: customer_id and source are documented in the schema, while connection_context has only a pattern and no description. The description reinforces the source default but adds no syntax or meaning beyond the schema, so the baseline 3 fits.

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: retrieving the billing setup for one customer. The parenthetical '(ledger by default)' and 'No invoice retrieval' sharpen scope, but no sibling tool is named for contrast, so it stops short of a 5.

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 invoice retrieval' is a useful when-not exclusion, and the '(ledger by default)' note implies the synced-data read path. However, there is no explicit statement of when to call this versus other account/billing-adjacent tools, so usage is only implied.

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 description is not the sole source of the safety profile. Still, for a destructive mutation it adds nothing: it does not say the live budget is actually changed, whether the change is reversible, or that confirmation is final.

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?

A single short sentence with the action front-loaded and zero filler. It is efficient, though arguably under-specified rather than genuinely well-structured.

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 mutation with no output schema, 33% parameter coverage, and an unaddressed sibling (shared budget confirm), the description is too thin. It omits the prepare-then-confirm workflow and any note on what the confirmation actually commits.

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 only 33% — only customer_id is documented, while draft_id and connection_context have no schema descriptions. The description's mention of 'draft' loosely maps to draft_id but adds no format, origin, or provenance detail to compensate for the gap.

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 verb 'Confirm' and resource 'budget update draft' are specific enough to tell this is the commit step of a prepare/confirm pair. However, it does not distinguish itself from the near-identical sibling google_ads_shared_budget_update_confirm, so the scope (campaign budget vs shared budget) is left to the reader.

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 word 'draft' hints that a prior prepare step is required, but the description never names google_ads_budget_update_prepare or states the precondition that a draft_id must already exist. There is no when-to-use vs when-not-to-use guidance at all.

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 declare readOnlyHint=false, destructiveHint=false, and openWorldHint=false, so the agent knows this is a non-destructive write path. The description adds nothing beyond that: it does not say whether the call actually changes the budget or only stages it, whether the change awaits a separate confirm, or whether it is idempotent. No contradiction with annotations, but no added behavioral value either.

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?

A single front-loaded sentence with no padding or redundancy. It is not verbose, but its brevity comes at the cost of specification rather than from efficient communication, so it sits at the minimum-viable level rather than being a model of concision.

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-preparation tool with four parameters, no output schema, and a low-coverage input schema, the description omits everything an agent needs beyond the bare action: the unit of amount_micros, the required follow-up confirm step, and what the prepare call returns. The burden falls almost entirely on the agent's inference from sibling names.

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 only 25% (just customer_id). The description contributes no parameter meaning at all, and critically omits that amount_micros is denominated in micros (1/1,000,000 of a currency unit), which is the single most error-prone field here. 'connection_context' is likewise left semantically undefined.

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 names a verb ('Prepare updating') and a resource ('a campaign daily budget'), which is more specific than a tautology. However, it does not explain what 'prepare' actually produces (a draft, a task, a confirmation token) and offers no differentiation from the sibling 'google_ads_budget_update_confirm' or from 'google_ads_shared_budget_update_prepare', leaving the agent to infer the tool's role from naming alone.

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?

There is no statement of when to use this tool versus the confirm variant, no prerequisite checks (customer access, connection context), and no indication of what must happen after the prepare call. The two-phase prepare/confirm workflow is only guessable from sibling names, not from the description.

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=false, so the safety profile is partly covered. The description adds nothing beyond that: it does not say whether confirmation executes the real campaign creation, whether it is irreversible, whether it is idempotent, or what happens if the draft is stale. For a mutation step this is thin.

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?

It is a single front-loaded sentence, but here brevity is achieved by omission rather than economy. The description is under-specified rather than genuinely concise, so the short form does not earn its place.

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 only a third of its parameters documented, the description is far too sparse. An agent lacks the lifecycle context, prerequisite, and parameter meaning needed to invoke this correctly.

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 only 33%: customer_id is documented, but draft_id and connection_context are not. The description adds no parameter meaning whatsoever, so it fails to compensate for the low coverage, leaving two of three parameters undocumented.

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: confirming a campaign-create draft. An agent can tell this is the approval step of a draft lifecycle. It does not, however, name or contrast with the paired google_ads_campaign_create_prepare tool or any sibling, so it stops short of full differentiation.

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?

There is no when-to-use guidance at all. The description never says that a draft must first be produced by google_ads_campaign_create_prepare, nor when confirmation is required versus skipped. The prepare/confirm pairing is only inferable from the tool name, not the description.

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?

Adds real behavior beyond the annotations: the campaign is created PAUSED, and the tool returns needs_input rather than silently defaulting to a worldwide campaign. With destructiveHint=false and readOnlyHint=false already covered by annotations, these extra disclosures are meaningful context about what the prepare step does and refuses to do.

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 sentences, zero filler, and the most important constraint (SEARCH needs targeting, never worldwide) is front-loaded after the core purpose. Every clause earns its place.

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 14-parameter, 5-required creation-prepare tool with no output schema, the description covers the critical gotcha but omits budget/name/channel essentials and what the prepare step returns (an approval plan). Adequate but with clear gaps for something this complex.

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?

With only 43% schema description coverage across 14 params, the description compensates partially by reinforcing the location_ids/language_ids requirement, but it says nothing about roas, strategy, channel_type, geo_target_type, targeting_source, excluded_location_ids, or the required contains_eu_political_advertising flag. Baseline 3 given the schema does describe the two most nuanced params.

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 (prepare/create) and resources (paused campaign + budget), which cleanly distinguishes it from the sibling google_ads_campaign_create_confirm that executes. It doesn't name that sibling explicitly, but the prepare/confirm pairing is signaled by the name and description.

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 one concrete conditional rule (SEARCH campaigns require location_ids and language_ids, else needs_input), which is genuinely useful usage guidance. However, it never states when to call this versus campaign_create_confirm, or what the prerequisite flow is, so guidance is implied rather than explicit.

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 destructive=true and readOnly=false, but the description goes well beyond them: it discloses timezone semantics, the approval-gating requirement, the internal verifications performed (operation kind, approval integrity, state drift), and the no-replay reconciliation rule for uncertain outcomes. This is unusually rich behavioral context for a mutation tool.

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 tightly packed sentences with the approval precondition front-loaded, followed by acceptance rules and the reconciliation constraint. No filler; every clause carries operational meaning.

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 mutation with no output schema, the description covers the key gaps: preconditions, verification behavior, and failure handling via the no-replay reconciliation instruction. It lacks any indication of what a successful response contains, but the essential calling 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 coverage is only 33% (only customer_id is documented). The description partially compensates by clarifying that draft_id must be a matching draft produced by the prepare tool, but it says nothing about connection_context or its expected format, leaving a third of the parameters undocumented in both schema and description.

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 precise verb and resource ('replace a campaign's start and end dates in its account timezone') and explicitly names the sibling it pairs with (google_ads_campaign_dates_update_prepare), so an agent can distinguish it from the prepare step and from other date-related tools.

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 precondition ('After explicit approval') and a hard routing constraint ('Accepts only a matching draft from ...prepare'), which tells the agent exactly when this tool is callable. It stops short of stating when-not-to-use or what to do if the draft does not match, so it is not a full 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?

Annotations declare destructiveHint=false and readOnlyHint=false, but the description adds crucial context beyond them: it saves a private draft, runs Google validate-only, snapshots affected resources, and does NOT send the mutation. That is a substantial behavioral disclosure. It does not mention required auth scopes or rate limits, so not a 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 sentences, front-loaded with purpose, second sentence covers the draft/approval lifecycle. No filler and every clause adds information.

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 non-mutating prepare tool with no output schema, the description covers the lifecycle (validate → draft → approval → confirm) and scope. Missing details like where the draft lives or its TTL, but the confirmation workflow is clear enough for an agent to act correctly.

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 only 33%; customer_id is documented but body's campaign_id/start_date/end_date are not described. The description mentions the resource ('campaign's start and end dates') but doesn't clarify date formats, timezone handling beyond 'account timezone', or why end_date is required with start_date optional. Baseline 3 given partial schema help.

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 ('replace a campaign's start and end dates') with a precise scope modifier ('in its account timezone'). Clearly distinguishes from its confirm sibling and other prepare tools by naming the follow-up 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 states when to use it ('Prepare to replace… does not send the change') and names the alternative/next step ('Show the draft for explicit approval before calling google_ads_campaign_dates_update_confirm'). The when-not-send behavior is unambiguous.

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 declare destructiveHint=true and readOnlyHint=false, so the agent knows this is a mutating, destructive operation. The description adds nothing beyond that: it never says whether setting a flag to false revokes existing capabilities, whether the change is idempotent, what authorization level is needed, or how it interacts with in-flight operations — exactly the context a destructiveHint warrants.

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?

A single front-loaded sentence with zero filler; the scope constraint lands first. It is efficient but arguably too compressed for a destructive five-parameter tool, leaving no room for the clarifications an agent needs.

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 mutation with no output schema, zero schema description coverage, and five parameters, the description is substantially under-specified. It omits permission prerequisites, the effect of disabling each flag, and identifier requirements, leaving the agent to guess before making a destructive call.

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 0%, so the description carries the full burden. It names the three policy axes (pull/create/decision) corresponding to allow_pull/allow_create/allow_decision, but gives no meaning for true vs false, and leaves connection_ref and connection_context (including their required ID formats) entirely unexplained.

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 (Set) and resource (pull/create/decision policy) scoped to 'one owned Google connection', which maps cleanly onto the allow_pull/allow_create/allow_decision parameters and separates it from google_ads_connections_list. It does not explicitly name or contrast with the nearest sibling, google_ads_customer_route_permissions_set, so the reader must infer the scope difference.

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?

There is no when-to-use, when-not-to-use, or alternative routing guidance. The only constraint offered is the embedded phrase 'one owned Google connection', which implies ownership but never states prerequisites or what to do for non-owned connections.

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=false, and openWorldHint=false, covering the safety profile. The description's only additional signal is the ambiguous word 'safe', which is never explained, and it omits any statement about return shape or filtering despite there being no output schema.

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?

A single front-loaded sentence with no padding or preamble. It is efficient, though the word 'safe' adds noise rather than information.

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 tool with an unexplained required-format parameter and no output schema, the description is too thin: it neither clarifies the opaque connection_context identifier nor explains what 'health' and 'operation policy fields' contain. Annotations cover the safety profile, but the core semantics remain underspecified.

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 connection_context has 0% schema description coverage and is not mentioned at all in the description. The constraint-heavy pattern (^mctx_v1_[0-9a-f]{64}$) is left entirely unexplained, so the description does nothing to compensate for the coverage gap.

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?

It states a verb ('List') and a resource area ('Google connection health and operation policy fields'), so the general action is clear. However, the qualifier 'safe' is undefined and the phrase 'health and operation policy fields' is jargon that doesn't pin down what is actually returned, nor distinguish it from siblings like google_ads_accounts_list or google_ads_connection_permissions_set.

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?

There is no when-to-use guidance, no prerequisites, and no mention of the adjacent sibling tools (e.g. google_ads_connection_permissions_set). The agent is left to infer the call context entirely.

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 and destructiveHint=true, so the agent knows this is a mutating operation, and 'Confirm' is consistent with that. The description adds the draft-confirmation concept but says nothing about what actually gets created, whether the operation is idempotent, 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?

A single tight sentence with the verb and object front-loaded and no filler. It is arguably under-specified rather than verbose, but as pure structure it is clean.

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 should say more about the outcome of confirming (what is created, what happens to the draft) and the required upstream prepare step. Annotations carry the safety profile, but the workflow context is thin for a destructive write 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 coverage is only 33%: only customer_id is documented. The description alludes to a 'draft' (hinting at draft_id) but does not explain draft_id's origin or what connection_context is, so it fails to compensate for the coverage gap.

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 (Confirm) and resource (WEBPAGE conversion-action create draft), and the word 'prepared' plus 'draft' implicitly ties it to the prepare sibling. It is distinguishable from google_ads_conversion_action_create_prepare, but it never names that sibling explicitly.

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?

'Confirm one prepared ... draft' implies the two-step prepare/confirm workflow, but does not explicitly instruct the agent to call google_ads_conversion_action_create_prepare first or state when this tool should not be used. 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 the full safety profile (readOnlyHint=false, destructiveHint=false, openWorldHint=false), lowering the burden. The description adds that execution is validate-only and that primary_for_goal defaults to false, which is useful, but it says nothing about what the prepared artifact is, its lifetime, or how it is consumed next.

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 with the purpose front-loaded and no filler. It is efficient as written, though the extreme brevity for a 12-parameter tool borders on under-specification rather than true conciseness.

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 12-parameter, 8%-covered, no-output-schema creation tool, the description omits the confirm follow-up, the prepared-plan identifier, prerequisites such as connection_context, and almost all parameter meaning. An agent could invoke it, but not confidently.

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 only 8% across 12 parameters, so the description must carry the load, yet it only clarifies two things: the type is WEBPAGE and primary_for_goal defaults to false. Ten parameters (name, category, counting_type, default_value, currency, lookback windows, connection_context, always_use_default_value) remain unexplained anywhere.

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 (prepare) plus resource and type scope ('one WEBPAGE conversion action'), so it is distinguishable from sibling create/update/remove conversion-action tools. It does not explicitly name the confirm counterpart, but the prepare/confirm naming pattern makes intent legible.

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?

'Runs validate-only' implies this is a dry-run staging step ahead of google_ads_conversion_action_create_confirm, which is actionable context. However, no explicit when-to-use, when-not-to-use, or named alternative is given, so usage must be inferred from the naming convention.

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 covered. The description does add meaning beyond that by stressing 'permanent removal' of exactly 'one' action, but it omits any warning that the operation is irreversible or what happens to the referenced draft.

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?

A single tight sentence with the key constraint ('permanent') front-loaded and zero filler. Nothing could be trimmed without losing information.

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 confirm step with no output schema and two undocumented parameters, the description is adequate but thin. It establishes the action and its permanence, yet omits the prerequisite prepare step and the meaning of draft_id, leaving gaps an agent must infer.

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 only 33% (only customer_id is documented) and the description supplies nothing about draft_id or connection_context. The agent gets no explanation of where draft_id comes from or that it references the prepared mutation, so the description fails to compensate for the coverage gap.

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 names a specific verb (confirm permanent removal), the resource (conversion action), and scopes it to a single prepared WEBPAGE conversion action. It implicitly pairs with the remove_prepare sibling via 'prepared', though it never names that sibling outright.

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 only implied: 'prepared' hints this is the second half of a prepare/confirm workflow, but the description never states that a prior google_ads_conversion_action_remove_prepare call is required, nor when not to call it. No alternatives are named.

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=false, so the safety profile is mostly covered. The description adds that removal is 'permanent' and limited to 'owned WEBPAGE' actions, but omits what the prepare step creates (e.g., a plan id) or that a confirm call is required before any actual deletion.

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?

Single front-loaded sentence with no filler; every word contributes to scope and action.

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-prepare tool with no output schema and low schema coverage, the description is too thin: it doesn't tell the agent how prepare relates to confirm, what a successful prepare returns, or the required connection context. The agent can identify the tool but lacks the workflow context to invoke it confidently.

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 only 33% (customer_id is documented, conversion_action_id and connection_context are not). The description adds a meaningful constraint for conversion_action_id — it must reference an owned WEBPAGE conversion action — but leaves connection_context and the required format of conversion_action_id unexplained.

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 ('Prepare permanent removal') and resource ('one owned WEBPAGE conversion action'), scoping the entity type and ownership. The 'Prepare' prefix distinguishes it from the paired confirm tool, but it never names that sibling to make the two-step workflow explicit.

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 guidance, alternatives, or prerequisites are given beyond the implied prepare-before-confirm pattern. It does not mention google_ads_conversion_action_remove_confirm or other removal-prepare siblings, leaving selection to inference.

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, destructiveHint=false, openWorldHint=false, so the safety profile is covered. The description adds genuine value by disclosing the key output side effect (yielding conversion_customer_id needed for writes) and the 'effective' customer scoping, but says nothing about pagination, limit behavior, or result shape.

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 no padding, and the core action plus its scoping qualifier are front-loaded. The second sentence is slightly terse ('required for writes' leaves the specific write workflow implicit) but earns its place.

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?

Without an output schema, the description usefully names one returned value, but omits the rest of the return shape, pagination/limit semantics, and how connection_context should be supplied. Adequate for a simple list tool but with clear gaps.

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 only 33% – only customer_id is documented. The description adds no meaning for the two undocumented parameters (limit with its default/max, and connection_context with its mctx_v1 pattern), so it fails to compensate for the coverage gap on a 3-parameter tool.

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?

Specific verb+resource ('List conversion actions') plus a scoping qualifier ('for the effective Google Ads conversion customer'), which tells an agent this lists existing conversion actions rather than creating/updating one of the many sibling conversion_action_* tools. It stops short of explicitly naming the confirm/prepare siblings it complements, so it is clear but not maximally differentiated.

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 clause 'Returns the conversion_customer_id required for writes' implies this is a prerequisite call before conversion-action write flows, which is useful implied usage. However, it never states when to choose this over alternatives (e.g., accounts_list), nor any preconditions or exclusions.

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 mutation/safety profile is covered. The description adds no behavioral context beyond the workflow framing: it never says the live conversion action is mutated, that the change is irreversible, whether the draft is consumed, or what happens when confirmation fails.

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?

A single front-loaded sentence with no filler; the object of the action and its scope are immediately clear.

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 mutation with no output schema and two undocumented parameters, the description is too thin. An agent cannot tell what confirming applies, whether it is reversible, or how to recover from a failed/expired draft.

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 only 33% — customer_id is documented but draft_id and connection_context are not. The description only alludes to 'one prepared ... draft', giving no format, source, or lifetime for draft_id and no explanation of connection_context, so it fails to compensate for the coverage gap.

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 (Confirm) and a specific resource (a prepared WEBPAGE conversion-action update draft), scoping it to one draft, one action type. It is distinguishable from its prepare counterpart by the verb alone, though it never names the sibling explicitly.

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 phrase 'prepared ... draft' implies the confirm step must follow a prior prepare call, which is useful implied workflow guidance. There is no explicit when-to-use/when-not, no stated alternative, and no mention of what to do if the draft is stale or missing.

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=false), lowering the bar. The description usefully adds that this is a preparation step and that type is immutable, but does not disclose what preparation yields (a staged mutation, a token for confirm, validation-only) or whether any resource is actually changed.

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, front-loaded sentences with no filler: the action is stated first, the key constraint second. Nothing is redundant. It is terse to the point of under-specification, but not bloated.

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 14-parameter mutation-preparation tool with no output schema, low schema coverage, and a required prepare→confirm handshake, the description omits far too much: which fields are updatable, what preparation returns, and how the confirm step consumes it. An agent cannot call this correctly without opening the schema and guessing at the workflow.

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 only 7% — customer_id is the sole documented parameter — so the description carries the burden and largely fails. It conveys only that type is a fixed WEBPAGE and immutable, leaving name, status, category, counting_type, values, lookback windows, and connection_context unexplained beyond bare enums.

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?