AdsAgent — Google Ads MCP

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

Far beyond the annotations: it enumerates the mutation classes (create/copy/edit/remove/delivery/budget/bid), states spend impact, sequential-not-atomic execution, stop-on-failure, per-item receipts, and how uncertain writes/host denials are never replayed. Annotations only supply destructive/openWorld flags; the description carries all the operational risk context.

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 with the core confirm/mismatch rule, but the block is long and repeats itself: the waiting_quota/retry_at agreement is stated twice, and 'user agreement' appears three times. Content earns its place but could be trimmed materially.

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 tool it covers everything an agent needs: required evidence, idempotency/repeat semantics, receipt handling, quota-deferred resumption, and no-replay guarantees for uncertain or denied writes.

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 compensate. It explains approval_ref, expected_plan_digest, and expected_changes semantically (matching the displayed plan/digest, one-entry-per-change). It does not clarify connection_context, leaving one of four params unaddressed.

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 ('Confirm a stored mixed advertising plan') and ties the inputs to their producer ('The exact expected_changes returned by prepare'). Combined with the sibling set (approval_plan_prepare/deny/get), an agent can immediately place it in the lifecycle.

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 preconditions: the prepare-returned expected_changes and the user's in-conversation agreement are required, the server rejects mismatches, and 'Changed or expired plans require review' gives an explicit when-not. Repeat-call behavior is also specified, so the agent knows how to re-invoke safely.

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?

Adds substantial behavior beyond the annotations: the approval is private and immutable, no ad changes are sent, source drafts become members and can no longer be confirmed separately, and edge-case policy is spelled out (waiting_quota retention, changed/expired plans require review, uncertain writes never replayed, URLs encrypted at rest and omitted from review). The annotations (readOnly=false, destructive=false) are consistent with this 'writes internal state only' framing.

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 in the first sentence and each subsequent sentence carries operational policy rather than filler. However, some lines are terse to the point of opacity ('Approval refs, draft IDs, digests and tokens are tool-traffic handles'), which costs a little clarity.

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 complex multi-draft approval tool with no output schema and no parameter descriptions, the description covers lifecycle, confirmation requirements, and failure/retry edge cases thoroughly. It still omits what the tool returns (only hinting at 'refs' and 'receipts') and never documents connection_context.

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 parameter meaning. It explains source_urls well (keyed by draft ID, original video source URL, encrypted at rest) and implies the constraints on draft_ids (1–20, owned, unexpired, unconfirmed), but connection_context is never described, leaving one 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?

States a specific verb and resource with explicit scope: 'Combine 1–20 owned, unexpired, unconfirmed advertising drafts into one immutable approval.' The two-phase semantics ('sends no advertising changes', 'Confirmation requires the user's agreement') clearly separate it from approval_plan_confirm/deny without needing to name them.

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 prerequisites for the drafts (owned, unexpired, unconfirmed) and a conditional usage rule ('For video uploads supply the original source URL in source_urls keyed by draft ID'). It does not explicitly state when to prefer this over other prepare tools or what to do if drafts fail the eligibility conditions, so it stops short of full when/when-not guidance.

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

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

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 declare destructiveHint=true and readOnlyHint=false, yet the description still adds real value: it discloses that the call validates operation kind, approval integrity, and state drift before sending, and that it is draft-bound and must not be replayed. These are non-obvious execution behaviours an agent cannot infer from 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, front-loading the action and target, then the prerequisite, then the failure-handling rule. No filler or repetition.

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

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

For a destructive mutation with annotations covering the safety profile and no output schema, the description supplies prerequisite, validation, and reconciliation guidance. It leaves the response/outcome shape and the connection_context parameter unexplained, but otherwise an agent has what it needs to invoke 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% (only customer_id is documented). The description partially compensates by tying draft_id to a matching draft from the prepare tool, but it says nothing about connection_context or the expected draft_id format, leaving a documented 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), resource (one supported ad's status), and the exact value domain (PAUSED or ENABLED), and names the sibling prepare tool it consumes drafts from. An agent can distinguish this from google_ads_status_pause_confirm or google_ads_ad_status_update_prepare without opening a schema.

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

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

Explicitly names the required upstream tool (google_ads_ad_status_update_prepare) and the condition that a matching draft must exist, plus the reconcile-without-replay rule for uncertain outcomes. It does not spell out when the operation should be abandoned or declined, so it falls just short of full when/when-not coverage.

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 the safety flags (readOnlyHint=false, destructiveHint=false, openWorldHint=false). The description goes well beyond them, disclosing that it runs a Google validate-only check, stores a private draft, captures a complete affected-resource snapshot, and defers execution to a separate confirm step.

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 operation, then the side effects, then the routing/authorization requirement. No filler or repetition.

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

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

For a prepare-step tool with no output schema, it fully explains the workflow (validate-only, draft, snapshot, deferral) and the confirm handoff. The remaining gap is parameter-level detail, which the low-coverage schema does not supply and the description does not fill.

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%, so the description is expected to compensate. It surfaces the status values but says nothing about ad_id, ad_group_id, customer_id, or connection_context, nor about the nested body structure, leaving the identifiers 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+resource ('Prepare to change one supported ad's status') and names the two allowed values (PAUSED/ENABLED). It explicitly contrasts itself with google_ads_ad_status_update_confirm, so an agent can distinguish the pair 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 when-to-use (this is the draft/preparation step), what it does not do ('does not send the change'), the alternative to call next (the confirm tool), and a prerequisite ('execution requires the user's agreement in the conversation'). Nothing is left 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 destructiveHint=true and readOnlyHint=false, so the write/safety profile is covered. The description adds real context beyond that: it verifies operation kind, approval integrity and state drift before sending, and it names the failure-handling rule (reconcile, don't replay). It does not say whether the replacement is irreversible or what a partial failure leaves behind.

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

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

Four dense sentences that are front-loaded with the operation and its scope, then the prerequisite, then the verification/failure rule. Every sentence carries information, though the phrasing is packed tightly enough that it borders on terse.

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 must carry the result story; it hints at uncertainty handling and reconciliation but never says what a successful confirm returns (e.g. a receipt) nor names the reconcile sibling. For a destructive two-required-param confirm tool, the prerequisite and verification coverage make this nearly complete.

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

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

Schema description coverage is only 33% (only customer_id is documented), so the description must compensate. It does name customer_id and draft_id and clarifies that draft_id must be a matching draft from the prepare step, but connection_context is left entirely to the schema pattern with no explanatory text.

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 (confirm replacing Display, Demand Gen or App ad headlines and descriptions across explicitly listed ad groups) and scopes it with the two required identifiers. It is cleanly distinguishable from its sibling google_ads_ad_text_update_prepare, which it names directly.

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 precondition: it accepts only a matching draft produced by google_ads_ad_text_update_prepare, and warns against replaying on uncertain outcomes. It does not state explicit exclusions beyond that prerequisite, so it falls just short of a full when/when-not treatment.

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

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

Beyond the annotations (readOnlyHint=false, destructiveHint=false, openWorldHint=false), the description adds real behavioral detail: it saves a private draft after Google validate-only and a full affected-resource snapshot, and explicitly does not send the change. This tells the agent what side effects to expect and why the operation is non-destructive, consistent with 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, front-loaded with purpose then behavior then routing. Every sentence earns its place with 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 mutation tool with no output schema, the description covers purpose, side effects, non-execution, and the confirm handoff. It omits what the saved draft/snapshot contains or how it is later referenced, but is otherwise 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 33% (only customer_id is documented). The description adds meaning for affected_ad_group_ids (must be explicitly listed) and implies headlines/descriptions content, but does not clarify ad_format, ad_id, or connection_context beyond the schema itself. Partial compensation merits the 3 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 (prepare to replace) plus the exact resource (Display, Demand Gen or App ad headlines and descriptions) and scope (explicitly listed ad groups). An agent can distinguish this from google_ads_ad_text_update_confirm and the other *_prepare tools immediately.

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

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

Explicitly names the follow-up confirmation tool (google_ads_ad_text_update_confirm) and states that execution requires the user's agreement in the conversation. It clearly establishes this as the non-committing first step of a two-phase flow, leaving nothing 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 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 safety profile is covered. The description adds genuine value beyond them: it discloses that operation kind, approval integrity, and state drift are verified before sending, and that uncertain outcomes must be reconciled without replay. These behavioral rules are 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 front-loaded sentences with no filler; purpose comes first, then the precondition, then the reconciliation rule. The "Confirm link" phrasing is slightly awkward but the structure is 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 return values need not be described, and the description covers the mutation's verification and reconciliation behavior well. It stops short of explaining connection_context, which is the one remaining gap for a destructive confirm operation.

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 compensates partially by tying draft_id to a matching draft from the prepare tool, but leaves connection_context undocumented in both schema and description, and adds no format detail beyond 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 specific verb+resource+scope: confirming the link of an existing asset to a Performance Max asset group, keyed on customer_id and draft_id. It names the prepare sibling it depends on. It does not, however, distinguish itself from the very close sibling google_ads_asset_link_confirm, so sibling differentiation is only partial.

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?

"Accepts only a matching draft from google_ads_asset_group_link_prepare" gives an explicit precondition that routes the agent through the prepare/confirm workflow. No explicit when-not-to-use is stated, but the required upstream step 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 only declare the generic safety profile (readOnlyHint=false, destructiveHint=false); the description adds the operational traits that matter: it saves a private draft, runs Google validate-only, captures a complete affected-resource snapshot, and explicitly does NOT send the change. That is exactly the side-effect disclosure needed to decide whether to call it.

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 its effect, then the handoff. No filler, no restatement of the tool name, and the most decision-relevant fact ('does not send the change') is placed prominently.

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 tool with no output schema, the description covers purpose, non-mutation guarantee, validation behavior, and the confirm handoff, so an agent has what it needs to call it. Minor gaps remain around what the saved draft exposes and how it relates to the approval_plan/task retrieval siblings, but nothing blocking.

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 at all — it never mentions customer_id, asset_group_id, asset_id, or the field_type enum that determines which asset slot is targeted. With coverage well under 50%, the description was required to compensate and 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 and resource ('Prepare to link an existing asset to a Performance Max asset group') and names the exact sibling it hands off to (google_ads_asset_group_link_confirm). An agent can distinguish this from the confirm tool and the other prepare/confirm pairs without opening any schema.

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

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

Explicitly names the follow-up tool and the gating condition: 'The confirmation tool is google_ads_asset_group_link_confirm; execution requires the user's agreement in the conversation.' This tells the agent both the alternative and when to route to it, rather than leaving the two-step pattern 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 establish destructiveHint=true and readOnlyHint=false, so safety is covered structurally. The description adds real behavioral context beyond that: pre-send verification of operation kind, approval integrity and state drift, plus the constraint that uncertain outcomes must be reconciled rather than replayed. It does not detail failure modes or the reconcile route by name, keeping it at a 4.

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 that are front-loaded with the action and immediately follow with the precondition and safety behavior. Every sentence carries weight, though the final sentence about reconciliation is slightly oblique about the intended follow-up 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 destructive confirm tool with annotations covering the safety profile and no output schema, the description supplies the missing pieces an agent needs: the prepare prerequisite and the no-replay reconciliation rule. It stops short of naming the reconcile sibling or describing the success/failure signaling, leaving 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%: customer_id carries the '10-digit' description in the schema, while draft_id and connection_context are bare. The description adds meaning to draft_id (must be a matching draft from the prepare call), but says nothing about connection_context format or the customer_id/draft_id pairing mechanics beyond restating them.

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

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

States a specific verb-and-resource pair: confirming removal of an existing asset link from a Performance Max asset group. It explicitly names its precondition tool (google_ads_asset_group_unlink_prepare), which lets an agent distinguish it from the many *_confirm/*_prepare siblings 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?

Clearly ties usage to the two-step pattern by stating it accepts 'only a matching draft from google_ads_asset_group_unlink_prepare', which is the condition that selects this tool over the prepare sibling. It lacks an explicit when-not-to-use or fallback routing (e.g., what to do if no matching draft exists), so it stops short of full guidance.

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

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

Annotations already declare readOnlyHint=false and destructiveHint=false, and the description adds substantial operational context: it performs Google validate-only, saves a private draft with a complete affected-resource snapshot, and does not send the change. It also clarifies that confirmation requires the user's agreement in the conversation, which goes well beyond the structured 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 description is three tightly written sentences that front-load the action and then add only workflow and safety context. Every sentence carries useful information, and none is redundant.

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?

The description is complete regarding the prepare-confirm workflow and the non-executing safety behavior. However, for a nested-body mutation-prepare tool with low schema description coverage and an unexplained connection_context parameter, it does not provide enough parameter guidance for an agent 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 33%, and the description does not explain customer_id, asset_group_id, asset_id, field_type, or connection_context beyond the general phrase 'asset link from a Performance Max asset group.' With low schema coverage, the description should compensate by clarifying parameter meaning, but 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 and resource: preparing to remove an asset link from a Performance Max asset group. It explicitly names the confirmation sibling, so an agent can distinguish this prepare step from google_ads_asset_group_unlink_confirm without opening either schema.

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

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

The description explains the two-step workflow and directs the agent to the confirmation tool, with the condition that execution requires the user's agreement. It does not explicitly state when not to use this tool or compare it against other unlink prepare tools, but the immediate usage context is clear.

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

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

Annotations declare destructiveHint=true and readOnlyHint=false, and the description is consistent with that. It adds real behavioral context beyond the annotations: it verifies operation kind, approval integrity, and state drift before sending, and warns that uncertain outcomes must be reconciled rather than replayed.

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 verb and resource, then prerequisites, then the failure-mode warning. Every sentence carries information; no filler.

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

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

For a destructive confirm tool with no output schema and three parameters, the description covers the prerequisite draft, the pre-send verification, and the no-replay rule. The only real gap is the undocumented 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?

Schema coverage is only 33% (only customer_id is documented as a 10-digit id). The description clarifies that draft_id must be a matching draft from the prepare step, adding meaning beyond the schema, but connection_context is never explained in either place.

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: confirm the replace of a Performance Max asset group's status or final URLs. It is clearly differentiated from the prepare sibling by naming the matching draft it consumes.

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 requires a draft produced by google_ads_asset_group_update_prepare, which tells the agent this is the second half of a two-step flow. The line about reconciling uncertain outcomes points toward the reconcile path, though the specific tool is not named as an alternative.

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 revealing the prepare/confirm workflow: it saves a private draft, runs a Google validate-only pass, captures a complete affected-resource snapshot, and does not send the change. This explains the real side effects (draft persisted) despite readOnlyHint=false, so the agent understands nothing is committed yet.

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 no filler, front-loading the action and scope, then the safety/sequencing constraints and the named alternative. Every sentence 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 prepare tool with no output schema, the description covers the workflow, side effects, and the confirmation path, which is what an agent needs. The remaining gap is parameter-level detail for the nested body, but the core calling contract is 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% and the description mentions only the mutable fields ('status or final URLs'), adding some meaning over the bare schema. However, it gives no format, ID, or constraint detail for final_urls, status, or the nested body beyond what the schema already implies.

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 to replace'), resource ('Performance Max asset group'), and scope ('status or final URLs'), which clearly differentiates it from the confirm sibling and from other asset-group tools. An agent knows exactly what this tool stages without reading 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 states when to use it (to stage the change) and when not to expect a real mutation ('does not send the change'), and names the exact follow-up tool google_ads_asset_group_update_confirm. It even notes the precondition that execution requires the user's agreement in the conversation.

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 disclose destructiveHint=true, readOnlyHint=false and openWorldHint=false, so the mutation/safety profile is covered. The description adds that confirmation requires a previously prepared draft or approval and a 'complete expected_changes' guard, but says nothing about reversibility, failure modes, or how to recover/reconcile afterwards.

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 leading with the action, with no filler. It is dense and slightly run-on in the conditional clause, but every fragment contributes to invocation.

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?

The description covers the confirmation inputs adequately for a 6-parameter mutation with no output schema, but for a destructive confirm it omits downstream behavior — success/failure reporting and the existence of google_ads_mutation_receipt_get / google_ads_mutation_reconcile for verification. Enough to invoke, not enough to use safely on failure.

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 17% (customer_id alone), so the description must carry the load; it names five of six parameters and, more importantly, encodes the mutually exclusive credential pairings and the completeness requirement on expected_changes that the bare schema types do not convey. It still omits the expected_plan_digest format and the role 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?

The description gives a specific verb ('Confirm') and object ('a prepared change'), which places it clearly as the terminal step of the prepare/confirm pair alongside google_ads_bidding_update_prepare. It does not explicitly name that sibling or state the resource is a bidding update, so an agent must infer the pairing from the tool 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?

It distinguishes two invocation modes (customer_id + draft_id, or approval_ref + expected_plan_digest) plus the required expected_changes, which is useful conditional guidance. However, it never states the precondition that a prepare call must have run first, nor when to choose one credential path over the other.

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, which gives a partial safety profile. The description adds nothing beyond that: it does not say this stages rather than executes a mutation, does not mention the 10-item cap on items, and gives no auth or rate-limit context.

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 short sentence with no padding, and the verb+resource are front-loaded. The brevity is under-specification rather than effective conciseness for a 7-parameter mutation-prep 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 7-parameter staging tool with no output schema and very low schema coverage, the description is far too thin. It omits what the preparation returns (a plan/task id?), how it pairs with the confirm sibling, and how the batch items relate to the top-level fields.

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 14% (just customer_id), and the description supplies no meaning for roas, strategy, amount_micros, campaign_id, or connection_context, nor for the items[] nested structure. The phrase 'bidding strategy' loosely gestures at the strategy parameters but clarifies nothing about format, units, or interplay between top-level and per-item fields.

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

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

The description names a specific verb (prepare) and resource (campaign bidding strategy), so it is distinguishable from unrelated siblings like budget or portfolio target updates. However, it does not explain what 'prepare' means in a prepare/confirm workflow, nor does it distinguish itself from the directly paired google_ads_bidding_update_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?

There is no statement of when to call this versus the confirm tool, no mention of a required follow-up confirmation step, and no prerequisites or conditions. The agent must infer the entire prepare/confirm pattern 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=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 safety profile is known. The description adds useful workflow context (this consumes a prepared draft or an approval reference, and requires a plan digest plus the complete change set), hinting at verification before commit. It still omits what happens on digest mismatch, idempotency, and reversibility of the applied change.

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 sentence leads with the verb and packs the two alternate invocation paths without filler. The phrasing gets tangled in the second clause, 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 destructive, irreversible commit with 6 parameters, 17% schema coverage and no output schema, this is thin: the agent still lacks the meaning of "complete expected_changes," the connection_context requirement, and what the tool returns on success or digest failure.

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 must carry the load — and it does: it documents 5 of 6 parameters and, crucially, the mutually exclusive relationship between (customer_id, draft_id) and (approval_ref, expected_plan_digest, expected_changes), plus the requirement that expected_changes be complete. 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 verb is clear ("Confirm a prepared change") but the resource is left generic — the description never says it applies a budget change, relying on the tool name to disambiguate it from the ~40 other *_confirm siblings. Without the name, an agent could not tell this apart from google_ads_bidding_update_confirm or google_ads_campaign_create_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?

It implies the intended position in the workflow (confirming something previously prepared) and gives conditional routing between two invocation paths (customer_id+draft_id vs approval_ref+expected_plan_digest). However, it never names the prepare counterpart explicitly, gives no when-not guidance, and does not warn that this step commits the change.

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 disclose a generic non-readonly, non-destructive profile, which is the minimum bar here. The description adds nothing about the prepare semantics: whether it creates a pending approval, whether it is reversible, what the preparation returns, or that the actual budget change only lands on confirm. For a mutation-prepare tool this is a meaningful gap.

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 that is front-loaded and free of waste. It is not verbose, but it is under-specified rather than genuinely concise, and the brevity costs it the ability to explain the workflow.

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 5 parameters at 20% schema coverage and no output schema, the description carries the burden of explaining the prepare/confirm flow and the amount_micros/items semantics — and does none of it. An agent could call this tool without knowing a confirm step is required.

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 20% — only customer_id is documented. The description implies campaign_id and amount_micros but never explains that amounts are in micros, that an items array supports batching up to 10 budgets, or how the array form relates to the single campaign_id/amount_micros form. It leaves the poorly documented parameters unclarified.

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 resource (campaign daily budget) and the workflow action (prepare/update), so the agent knows the target area. However, "Prepare updating" is vague about what preparation actually produces — a pending mutation, a token, an approval request — and it does not distinguish this tool from its direct sibling google_ads_budget_update_confirm or from google_ads_shared_budget_update_prepare.

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 is given. Most critically, the description never states that this is the first step of a two-phase flow that must be followed by google_ads_budget_update_confirm, even though that sibling exists. The agent must infer the workflow from the naming convention 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 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 flag destructiveHint=true and readOnlyHint=false, but the description adds genuine behavioral context beyond them: pre-send verification of operation kind, approval integrity and state drift, plus the no-replay rule for uncertain outcomes. It does not say what permissions are needed or what a failure returns, so it stops 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, front-loaded with the action and scope, then preconditions, then the failure rule. No filler, though 'Confirm replace' is slightly awkward phrasing that costs a little clarity.

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, the description covers preconditions, integrity checks and the reconciliation obligation — the essentials an agent needs. Missing permission/auth requirements and any indication of what a successful or failed call yields.

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 compensates partially by giving draft_id its provenance (must be a matching draft from prepare) and tying both ids to the operation, but connection_context remains undocumented in both schema and description. Baseline 3 for partial compensation under 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 and resource: 'Confirm replace a campaign's start and end dates in its account timezone', with the two required identifiers named. It is clearly distinguished from its sibling google_ads_campaign_dates_update_prepare by being the confirmation half of the pair.

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 gates usage: 'Accepts only a matching draft from google_ads_campaign_dates_update_prepare', so the agent knows prepare must run first and the draft must match. It also states the rule for uncertain outcomes, but does not name the reconcile tool (google_ads_mutation_reconcile) that would satisfy 'reconciled without replay'.

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

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

Annotations only give safety hints (readOnlyHint=false, destructiveHint=false). The description adds real behavioral context beyond them: it runs Google validate-only, saves a private draft, takes a complete affected-resource snapshot, and does NOT send the change. It stops short of noting auth/permission requirements or draft lifecycle.

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 core purpose, then the draft/validation behavior, then the routing to the confirm tool. No wasted words, though it could be marginally tighter.

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 step in a prepare/confirm workflow with no output schema, the description covers the essential workflow context well (validate-only, draft, snapshot, no send, confirmation routing). The main residual gap is parameter-level detail for the nested body.

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 described), so the description carries more burden but adds almost nothing about parameters. It implies start/end dates and account timezone but never explains the nested body structure, the required end_date, the campaign_id pattern, or the connection_context token.

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 replace a campaign's start and end dates.' It explicitly distinguishes itself from the confirm sibling by naming google_ads_campaign_dates_update_confirm and clarifying it does not send the change, so an agent can tell the prepare/confirm pair apart 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?

Names the alternative tool (the confirm sibling) and gives the condition for the eventual execution ('requires the user's agreement in the conversation'). It clearly frames this as the draft/validation step, though it does not spell out explicit when-not conditions beyond that.

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.