ADM Google Ads

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

Annotations declare readOnlyHint=true / destructiveHint=false, and the description confirms 'it changes nothing in Google Ads,' which aligns rather than contradicts. It goes well beyond the annotations by disclosing auth/plan requirements (read_write key, paid plan), the async cost profile (several AI calls per invocation), timing (1-3 minutes), and the explicit anti-retry warning.

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

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

Front-loads the operation and its non-mutating nature in the first clause, then layers in the AI behavior, polling, handoff, and constraints. Dense but every sentence carries a distinct decision-relevant fact.

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 an async tool with no output schema, the description fully covers what is returned (draft_id), how to retrieve the result (polling interval), what the result is (ad_groups), and how to consume it, leaving no gap an agent needs to call it 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 100%, so the baseline is 3. The description adds semantic role beyond the schema by explaining that the landing page content drives keyword grouping and ad text, and that the finished ad_groups flow verbatim into add_ad_groups, but it does not add per-parameter syntax or constraints the schema omits.

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: 'Starts an AI draft of ad groups for an existing Search campaign and returns draft_id at once.' It also distinguishes itself from siblings by naming get_ad_group_draft (polling) and add_ad_groups (the next step), so an agent can place it in the workflow 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?

Explicit when-to-use and how-to-proceed: poll get_ad_group_draft every poll_after_seconds, preview before passing to add_ad_groups, and do not repeat the call for the same input while a draft is pending or running. Alternatives and the sequencing are spelled out.

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=true, destructiveHint=false, idempotentHint=false), the description discloses async behavior, typical 1-3 minute completion, cost in AI calls, the read_write key + paid plan requirement, and the anti-duplication rule that aligns with idempotentHint=false. This is rich context an agent needs before invoking.

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 dense single paragraph but front-loads the core action and return value, and every sentence carries operational information (polling, handoff, preconditions, dedup warning). It is slightly information-packed for one paragraph, but 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 complex async tool with 11 parameters and no output schema, the description covers the entire lifecycle: initiation, async polling, completion handoff, budget-gap handling, and prerequisites. Nothing essential to correct invocation is missing.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds cross-parameter flow meaning: the keywords/explore_keywords interaction, the daily_budget → missing_fields handoff before create_search_campaign, and business_goal only guiding exploration, giving the agent sequencing context beyond raw field docs.

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 ('Starts an AI draft of a NEW Search campaign'), names the immediate return value (draft_id), and explicitly clarifies it is non-mutating ('changes nothing in Google Ads'). It effectively distinguishes itself from create_search_campaign and the get_campaign_draft polling sibling.

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 spells out the full workflow: poll get_campaign_draft every poll_after_seconds, then pass the draft verbatim to create_search_campaign (preview first). It also states when NOT to call it ('do not repeat it for the same input while a draft is pending or running') and its key/plan preconditions.

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

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

With annotations already covering the read-only/idempotent profile, the description adds substantial non-obvious behavior: exact/phrase mirror ADM optimizer matching, broad requires every negative word as a whole word, close variants are not detected, and results are paginated via cursor. These are traits the annotations cannot express.

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

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

Front-loads the core outcome, then matching semantics, then hypothetical-mode rules. Dense and mostly every sentence earns its place, though the matching-type clause is compressed enough to require a second 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?

No output schema exists, and the description does cover what results represent (keyword plus blocking negative with level/id/text) and pagination. It does not specify the returned field names or ordering, a minor gap for a tool with no 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 100%, so the baseline is 3, but the description adds real inference the schema does not: a hypothetical keyword needs a campaign_id (falling back to the tool's campaign_id), ad-group negatives only apply when an ad_group_id is present, and campaign_id restricts checks to one campaign while account negatives persist. The nested-object shape is only sketched, keeping it below 5.

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

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

States a precise verb+resource: lists positive keywords blocked by negatives, and identifies which negative blocks them with level/id/text. Clearly distinguishable from get_negative_keywords and get_keywords in the sibling 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?

Gives conditions for the 'hypothetical' mode (pass negatives and/or keywords to check words not yet added) and the scope effect of campaign_id, including that account negatives still apply. It does not name a sibling tool to use instead when the user only wants existing negatives (get_negative_keywords), so it stops short of explicit alternatives.

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/idempotent/closed-world, and the description adds real context on top: the exact composition of the response (plan, API key scope read vs read_write, remaining campaign-creation quota, remaining write calls/queries/write items today) and the no-account fallback link. It also discloses why skill_version is passed and what it controls (whether the ADM skill file needs an update), which is behavioral knowledge not present anywhere in the structured fields.

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

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

Front-loaded with the imperative "Call this first," which is the highest-value sentence. The middle sentence is a dense comma-separated inventory of returned fields that borders on listy, but every item is decision-relevant and nothing is repeated from the schema or annotations.

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

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

No output schema exists, so the description carries the full burden of describing returns — and it does so concretely, including quotas, plan, key scope, and the no-account link. Combined with the required customer_id handoff instruction, an agent has everything needed to call this first and correctly use its result.

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

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

Schema coverage is 100% and the single optional parameter is already documented, so baseline is 3. The description adds marginal meaning by explaining the downstream effect of skill_version (the response can flag whether the skill file needs updating), which clarifies why an agent would supply it rather than just what format to use.

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 (lists the Google Ads accounts connected to the ADM account) and immediately differentiates itself from the ~20 get_* siblings by declaring itself the entry point: "Call this first." It also enumerates the non-obvious secondary payload (plan, key scope, quota, write items) so the agent knows this is more than a plain listing.

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 sequencing guidance: "Call this first" plus "Use the returned customer_id in every other tool," which is exactly the dependency an agent needs. It also covers the failure path ("If no account is connected, returns a link where the user can connect one"), so both the happy path and the empty-state branch are specified.

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 readOnly/idempotent/non-destructive; the description adds genuinely new behavior: draft retention of 24 hours, the state lifecycle, and what the error field means on failure. 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?

Four tight sentences covering state, follow-up actions, failure handling, and retention, each earning 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?

No output schema exists, yet the description names the payload fields (ad_groups, primary_ad_group, error) and the 24-hour window, giving the agent everything needed to poll and act.

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

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

Schema coverage is 100% with draft_id already documented as the value returned by draft_ad_groups, so the schema carries the parameter. The description reinforces it by naming the originating sibling in prose, though it adds no new syntax or format detail.

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 (returns the state) and resource (a draft started by draft_ad_groups), with the exact possible states enumerated. Clearly distinguishes itself from the sibling draft_ad_groups (which starts the draft) and get_campaign_draft (a different draft resource).

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

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

Explicitly names the sibling that starts the draft, and routes the agent on what to do in each state: pass ad_groups to add_ad_groups when done, start a new draft when failed. This is a model poll-then-act workflow 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 readOnly/idempotent/closed-world, but the description adds real behavior beyond them: PAUSED groups are included and REMOVED are never returned, results are sorted by campaign then ad group, and supplying days changes the sort to cost descending. It does not mention rate limits or quota behavior, 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 dense sentences, front-loaded with purpose and returned fields, then filters, then pagination/sorting, then the sibling routing. It is packed but every clause carries information; the long parenthetical field list is the only slight density cost.

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 description compensates by enumerating returned fields and the extra performance metrics added by days, plus ordering and cursor pagination. For a 6-parameter list tool this is complete enough to call correctly without further guessing.

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

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

Schema description coverage is 100%, so the baseline is 3, but the description adds semantics the schema does not: that days (1-30) appends performance metrics per ad group and re-sorts by cost, and that restricting status to ENABLED/PAUSED still keeps everything else intact. It does not restate limit/cursor beyond what the schema already documents.

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 ('Lists ad groups') and then enumerates the returned fields (id, name, status, campaign name/status, max_cpc, bidding_strategy_type, keyword_count, ad_count), which no sibling tool claims. It also explicitly distinguishes itself from get_campaign_setup.

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

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

Gives an explicit alternative and the condition that selects it: 'Use this instead of get_campaign_setup when you only need ad group status across many campaigns.' Optional filters (single campaign, ENABLED/PAUSED, days for performance) are framed with their use conditions.

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

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

Annotations only cover safety (readOnly, idempotent, closed-world); the description adds substantial behavior beyond them: PAUSED ads included but REMOVED excluded, sort order (cost descending), cursor pagination, url_options omitted when empty, and an explicit prompt-injection warning that ad text is third-party data, not instructions. That last point is unusually valuable for an agent.

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 content is front-loaded with what gets returned, but it is a single dense paragraph with a long field enumeration. The enumeration is defensible given there is no output schema, yet it could be broken into scannable sentences rather than one wall of text.

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 exhaustive field list (metrics, policy topics, approval/review status, url_options behavior) is exactly what an agent needs to know what comes back. Adds pagination, sort, and data-trust caveats, so nothing material is missing 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 coverage is 100%, so the baseline is 3, but the description adds semantic effect beyond the schema for the filters: approval_status as a filter returns only ads with that review outcome, and text_contains is a case-insensitive substring match on headline/description. Defaults like days and limit are left to the schema, which already handles 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?

Names a specific verb and resource ('Lists ads') and immediately scopes it ('including PAUSED, never REMOVED') with performance metrics for the last N days. An agent can distinguish this from get_ad_groups or get_campaigns without opening any schema, since the description enumerates exactly what an ad record contains.

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 clear operating context: filter by campaign or ad group, use compact=true for a slimmer payload, use approval_status/text_contains to narrow results, and notes 'id is the ad id for update_ads and set_ad_status'. It does not name an alternative tool or state when NOT to use this one, so it falls short of 5.

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

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

Annotations already establish readOnlyHint=true, idempotentHint=true and openWorldHint=false, so the safety profile is covered. The description adds meaningful behavior beyond annotations: removed links are excluded, results are paginated via cursor, campaign_id without level returns campaign, ad group and customer-level assets, and asset text is third-party data. It does not cover auth requirements or rate limits.

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 front-loaded with the core purpose and avoids repetition. Its exhaustive parenthetical listing of returned content fields is information-dense but somewhat unwieldy, so it is not as cleanly structured as it could be.

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 appropriately describes returned asset content, link_status behavior, pagination, and campaign_id scoping. Annotations cover the read-only safety profile, and the schema documents all eight parameters, so the definition is complete enough for an agent to call it 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 100%, establishing a baseline of 3. The description adds value beyond the schema by explaining the interaction between campaign_id and level and by clarifying that level, types, asset_ids and link_status are filters, not just parameter names.

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 opens with a specific verb and resource ("Lists ... assets") and enumerates the exact asset types covered, making it immediately distinguishable from sibling get_ads and other get_* tools. It also states the scoping dimension (level) and returned data, so 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?

It explains that level, types, asset_ids and link_status act as filters and clarifies the important campaign_id-without-level behavior, giving clear contextual guidance for invocation. However, it does not name alternative tools or state when not to use this tool, so it falls short of full when/when-not/alternatives 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 establish a safe, idempotent, closed-world read, so the bar is lower; the description adds real value by disclosing the return shape (id, name, type, target CPA/ROAS, CPC ceiling, attached campaigns with status), which matters because there is no output schema. It doesn't cover pagination or result-size limits.

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 dense sentences with the returned-field list and the routing guidance front-loaded; every clause (including the get_campaign_setup exclusion) 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?

With no output schema, the description correctly compensates by enumerating return fields, and it closes the main ambiguity risk (portfolio vs. campaign bidding) by pointing elsewhere. An agent has everything needed to select and call it.

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?

Only one parameter, and the schema documents it fully at 100% coverage, including where the customer ID comes from. The description adds no format or origin detail beyond the schema, so the baseline 3 applies.

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

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

Specific verb ("Lists") plus a precisely scoped resource ("the account's portfolio (shared) bidding strategies"), and it enumerates the returned fields. It also explicitly distinguishes itself from get_campaign_setup, which covers per-campaign bidding.

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?

States the downstream consumers of the returned id (attach_bidding_strategy and update_bidding_strategy) and names the alternative tool (get_campaign_setup) with the condition that selects it. 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 readOnlyHint, idempotentHint and destructiveHint=false, but the description adds genuinely non-structured behavior: a 24-hour retention window, the fact that failed states carry an explanatory error, and the missing_fields remediation flow. These are lifecycle and recovery facts an agent cannot get from annotations or 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?

Front-loads the return contract (the four states) before the action guidance, and every sentence carries load: state enumeration, happy-path routing, missing-field handling, failure handling, TTL. 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?

No output schema exists, yet the description fully covers what comes back (state names, campaign payload, missing_fields, error text) and what to do in each case. For a single-parameter polling tool this leaves nothing an agent needs missing.

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

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

Only one parameter exists with 100% schema description coverage; the schema already says draft_id is 'returned by draft_campaign'. The description reinforces the linkage to draft_campaign but adds no format or constraint detail beyond the schema, so the baseline 3 is appropriate.

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

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

States a specific verb and resource ('Returns the state of a draft started by draft_campaign') and enumerates the exact possible states (pending, running, done, failed). This clearly distinguishes it from siblings like draft_campaign (which creates the draft) and get_ad_group_draft (a different draft type).

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 branch-by-branch guidance: when done, pass campaign verbatim to create_search_campaign after previewing; when missing_fields is non-empty, ask the user and set fields; when failed, read the error and start a new draft. This is a full decision tree for the agent, not just a use 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?

Goes well beyond the readOnly/idempotent annotations: it discloses the exclusion of REMOVED campaigns, the exclusion of today from the window, currency handling (major units), portfolio-strategy fallback behavior, sort order (cost descending), and cursor pagination semantics.

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

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

Front-loads the scope and window before the metric list, and each sentence carries real information. The long enumeration of returned fields is dense but justified given there is no 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 compensates by naming the returned fields, unit conventions (ctr 0-1, money in major units), and pagination behavior. Nothing essential for correct invocation is missing.

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

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

Schema description coverage is 100%, so the schema already documents days, limit, cursor, status, and customer_id in detail. The description adds only marginal parameter notes (e.g., passing next_cursor back as cursor), so the baseline 3 applies.

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

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

States a specific verb and resource (lists campaigns in one account) and enumerates the returned settings and performance metrics. It is clearly distinguishable from siblings like get_campaign_setup and get_campaign_draft because it is the reporting-oriented listing tool.

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

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

Gives clear usage context: last N complete days with today excluded, REMOVED campaigns never returned, and status filtering with ENABLED/PAUSED. It does not explicitly name an alternative sibling to use instead, so it falls short of a 5.

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

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

Annotations already cover read-only/idempotent/closed-world, so the description's job is to add context, and it does: PAUSED items are included, device bid adjustments are returned only when non-zero with '-100 excludes that device', url_options are omitted when empty, and money is in account currency in major units. It does not cover auth/permission requirements or failure behavior, 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?

Opens with the essential scope statement, so it is front-loaded correctly, but the middle is a dense single-sentence enumeration of every returned field. That enumeration has real value given there is no output schema, yet it reads as a wall of text rather than being structured.

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

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

With no output schema and a closed-world read tool, the description carries the return-shape burden itself and does so thoroughly, enumerating the snapshot fields, include semantics, dependency rules, and units. Nothing an agent needs to call it correctly is missing.

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

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

Schema coverage is 100%, yet the description still adds material meaning beyond the schema: it documents the four selectable sections, the default composition (ad_groups, keywords, ads, without assets), and the undocumented-in-schema dependency that 'keywords and ads require ad_groups'.

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 the full configuration snapshot of one campaign') and immediately scopes it with '(no metrics)', which cleanly separates it from performance-oriented siblings like get_device_performance or get_search_terms, and from the list-shaped get_campaigns.

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 clear usage contexts ('Use it to inspect, copy or verify a campaign') and spells out the include semantics, defaults, and the dependency that keywords and ads require ad_groups. It stops short of explicitly naming an alternative (e.g. get_campaign_draft) for the related use case, so a 4 rather than a 5.

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

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint=false, so the safety profile is covered. The description adds real behavioral context beyond that: the implicit filter to non-removed actions, the 30-day window on metrics, and the note that include_in_conversions is an alias of primary_for_goal (Google replaced the old field). It does not mention result limits or pagination.

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 verb and scope, then the parameter guidance. The long field enumeration in the first sentence is dense but each item earns its place given there is no output schema. Two sentences, 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?

With no output schema, the description compensates by enumerating the returned fields and the flag semantics, and annotations cover the safety profile. Only minor gaps remain (no mention of result volume/pagination or ordering), which are unlikely to block a correct 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 coverage is 100%, so both parameters are already documented, including the exact metrics returned by include_metrics. The description's explanation of include_metrics largely restates the schema; its additional value (the primary/include_in_conversions alias) concerns an output field rather than an input parameter. Baseline 3 is appropriate.

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

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

Specific verb ('Lists') plus resource ('conversion actions'), with an explicit scope qualifier ('that are not removed') and an enumeration of the fields returned. No sibling covers conversion actions, so the agent can select this tool unambiguously from the get_* list family.

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 conditional guidance for the optional parameter ('Pass include_metrics=true to add...'), which is useful usage context, but it never states when to reach for this tool versus other reporting tools (e.g. get_campaign_setup or performance tools). Usage is implied by the resource name rather than stated.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true and openWorldHint=false, so the safety profile is covered. The description adds genuine scope context (values exist at three hierarchy levels) and explains the default fallback and length-limit counting behavior, but says nothing about return shape, volume, or pagination.

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

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

Three sentences, front-loaded with the core purpose, and no filler. The syntax/default sentences are useful but lean toward explaining downstream consumption of the data rather than the invocation itself.

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

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

For a single-parameter read tool with no output schema, the description does state what is returned (attributes and values) and at which levels, which is the key completeness question. It stops short of describing result format or pagination, but nothing critical is missing for a correct 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?

Only one parameter and schema description coverage is 100%, so the schema already fully documents customer_id, including the 'from get_accounts' provenance and format example. The description adds no parameter-level detail, making 3 the correct 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?

Clear verb+resource: lists ad customizer attributes and their values, with the scope specified as account, campaign and ad group level. No sibling tool covers customizers, so there is no confusion risk, but the description never explicitly distinguishes itself from the other 'get_*' listing tools.

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

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

Usage is implied rather than stated: the description explains how to reference the returned attribute values in responsive search ad text, which hints at why you would call it, but gives no when-to-use guidance, prerequisites beyond the required customer_id, or alternatives.

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

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

Annotations already cover the safety profile (readOnly, idempotent, openWorld=false), and the description adds real behavioral context beyond them: sorted by cost descending, cursor pagination, data-completeness caveats on recent days, and the bid-adjustment override rules (ad group overrides campaign except campaign -100%).

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

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

Front-loads the core purpose, then progressively adds metrics, scope, level semantics, and bid-adjustment rules. It is dense and runs long, but nearly every clause carries information an agent would otherwise have to guess; the metrics enumeration is the only borderline section.

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

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

With no output schema, the description carries the return-value burden and does so: it lists the metrics, explains bid_adjustment_percent/source semantics, states sort order and pagination. Nothing an agent needs to call or interpret this tool is missing.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaning beyond the schema — what level actually changes at row granularity and what bid_adjustment_percent / bid_adjustment_source values mean. It also clarifies that level is a plain string rather than encoding an enum.

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 — device-split performance for the last N complete days — and enumerates the metrics returned. It is clearly distinguishable from sibling performance tools such as get_location_performance and get_search_terms by naming the device dimension and the campaign-only scope.

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 clear context: 'Search campaigns only', the level=campaign default vs level=ad_group row semantics, and routes mutation to set_device_bid_adjustments. It does not explicitly contrast against sibling read tools (e.g. get_campaigns) for the same data, but the when-to-use picture is solid.

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, idempotentHint and openWorldHint=false, so safety is covered. The description adds genuinely non-structured behavior: REMOVED keywords are excluded, results are sorted by cost descending (ad group then id when compact), and paging is cursor-based. It could still say more about performance-data staleness bounds, but this is well beyond annotation coverage.

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?

Effectively one dense paragraph but front-loaded with scope, then fields, then filters, then sorting/pagination and the sibling pointer. Every clause carries information, though the run-on delivery of the returned-field list is denser than it needs to be.

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

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

With no output schema, the description carries the return-value burden and does so by enumerating the returned metric and dimension fields plus the compact field subset. Combined with the disclosed sort order, pagination, and filter semantics, an agent has everything needed to call this correctly for a 10-parameter 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 100%, so the baseline is 3, but the description adds real meaning: the Google text notation ('phrase', [exact], bare = broad), the note that text_contains is case-insensitive and ignores quotes/brackets, and exactly which five fields compact=true returns. These are semantic clarifications the schema alone does not convey.

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 opens with a specific verb and resource plus a crucial scope qualifier: 'Lists positive keywords (including PAUSED, never REMOVED) with performance for the last N complete days.' It explicitly routes the disjoint sibling case at the end ('Negative keywords are in get_negative_keywords'), so an agent can distinguish it from the other ~20 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?

Gives clear routing for the main ambiguity (negative keywords live in a sibling tool) and states how to use compact=true versus full output. It stops short of explicitly contrasting with adjacent tools like get_search_terms, so it is strong context without a complete alternatives map.

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

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

With readOnlyHint already covering the safety profile, the description goes well beyond: it discloses sort order (cost descending), the 10,000-row cap with truncated=true, cursor pagination, and the subtle targeting_status states including the non-obvious 'a city inside a targeted country is none.' It even notes bid_adjustment_percent only appears when targeted and non-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?

Front-loaded with purpose and scope, then behavior, then routing and output fields. Information-dense with little waste, though the targeting_status and output-field sentences are packed tightly enough that it reads as a long single block rather than scannable segments.

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 description compensates by enumerating the returned row fields (location_id, impressions, clicks, cost, conversions, ctr, etc.). Combined with granularity semantics, truncation, and pagination, an agent has everything needed to call and interpret 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 100% so the baseline is 3; the description adds real meaning by defining granularity levels (region defaults to states/provinces, city is the most specific Google reports) and by tying location_id to the write siblings. It does not, however, expand on days/limit/cursor beyond the schema 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 resource (location performance) with two sharp scoping constraints: 'where the user actually was (not locations they showed interest in)' and 'Search campaigns only.' This separates it cleanly from geotarget interest data and from get_device_performance 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?

Names concrete alternatives with the condition that selects them: set_location_bid_adjustments to change a targeted bid, and update_campaign_locations (add_exclusions/add_targets) with location_id to exclude or target. Routes the agent explicitly rather than leaving write-vs-read to inference.

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

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

Goes beyond annotations (readOnlyHint, idempotentHint) by disclosing the four-level result structure, the Google notation format for match types, and the non-obvious rule that account-level negatives are always returned even when campaign_id is set. Doesn't mention pagination or result-size limits, so not a 5.

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

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

Single dense sentence that front-loads the core purpose then layers the level detail and the campaign_id condition. Some readers may find the parenthetical notation examples and level enumeration heavy, 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?

With no output schema, the description compensates by describing the returned structure (levels, shared list fields id/name/keywords/attached_campaigns) and the match-type notation. Annotations cover safety. Only missing pagination/limit behavior for a potentially large list.

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

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

Schema coverage is 100%, so both parameters are already documented. The description adds a behavioral consequence of campaign_id (shared lists limited to attachments) which the schema's one-liner does not, but doesn't add syntax or format beyond that. Baseline 3 is appropriate given the schema does the primary work.

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?

Description names a specific verb (Lists) and resource (negative keywords) and adds distinctive scoping detail: grouped by level, Google notation, and enumerates the four levels returned. This distinguishes it from sibling get_keywords (positive keywords) and find_negative_conflicts.

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 condition for campaign_id: limits campaign and ad group levels to that campaign and only returns shared lists attached to it, while account level is always returned. This tells the agent exactly when the parameter changes results. No explicit when-not-to-use or pointer to find_negative_conflicts, but the filtering semantics are fully spelled out.

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

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

Annotations only cover read-only/idempotent/open-world. The description adds real behavioral context beyond them: the full set of result states, the phase and resource_map of what was actually created, and the safety rationale (check before retrying so nothing is created twice). It also implies the tool is side-effect-free, 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?

Front-loaded with the verb, resource, and key, and every clause carries information (field list, then the decision guidance). It is a single dense run-on sentence, so it is information-efficient but not ideally parsed.

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, so return values must be described here and they are: the result enum, phase, resource_map, error, and timestamps. Combined with the retry guidance, an agent has everything needed to call it 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?

With one parameter at 100% schema coverage, the baseline is 3. The description adds provenance ('returned by every write tool') and ties the parameter to the retry workflow, which is slightly more than the schema's terse 'returned by a write 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?

States a specific verb ('looks up') and resource ('a write operation') keyed on operation_id, then enumerates exactly what comes back (result states, phase, resource_map, error, timestamps). No sibling tool looks up an operation, so there is no ambiguity to resolve.

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

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

Gives an explicit trigger condition: call it after a timeout, result_unknown, or partial result, before deciding to retry. It does not name a when-not or an alternative, but no plausible alternative exists among the siblings, so the gap is minor.

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/idempotent safety, and the description adds substantial behavior beyond them: 200-row per-level truncation, truncated=true semantics, count as the full number, parent_paused=true meaning, and that REMOVED entities are excluded. These are exactly the operational details an agent needs to interpret results correctly.

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 what is counted, then layered with the truncation, parent_paused, and REMOVED constraints in tight clauses. Every sentence carries distinct information; nothing is boilerplate.

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, so the description must explain the return shape, and it does: id/name per entity, per-level row cap, truncated flag, full count, and parent_paused. Nothing needed to interpret the response or call the tool is missing.

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

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

With one parameter and 100% schema description coverage, the schema already documents customer_id with format and source (get_accounts). The description adds no parameter-level meaning, so the baseline 3 for high schema coverage applies.

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

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

States a specific verb (counts) and precise resource set (paused campaigns, ad groups, keywords, ads), including the Google-notation caveat for keywords. It clearly distinguishes itself from sibling list tools like get_campaigns and get_keywords, which return all entities rather than only paused ones.

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 final sentence gives an explicit when-to-use: 'Use this before enable everything that is paused.' That is a clear workflow context, but no explicit alternative or exclusion is named, so it falls short of a full when/when-not/alternative statement.

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 only the safety profile (readOnly, idempotent, closed-world). The description adds substantial behavior beyond them: cost-descending sort order, the 10000-row pre-filter read limit and the truncated=true data-loss caveat, cursor pagination semantics, and a prompt-injection warning that search terms are third-party text to treat as data.

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 long but dense and front-loaded, leading with the core resource and return fields before the filters and caveats. Every clause carries information; the only mild cost is that it is delivered as one unbroken paragraph rather than scannable sections.

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, so the description carries the burden and does so by enumerating returned columns for both default and group_by modes. Combined with the pagination and truncation notes, an agent has everything needed to call it 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 100%, so baseline is 3, but the description genuinely adds meaning: it decodes the status values (added / excluded / added_excluded / none), explains that min_cost is in account currency and applies to the total under group_by, and clarifies group_by's row shape. The truncation interaction with min_cost is also useful 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?

States a specific verb and resource: it lists 'the actual search queries that triggered ads' in the last N complete days, and enumerates the returned columns. This is clearly distinguishable from siblings like get_keywords or get_negative_keywords.

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 clear context for the main variants: when to use group_by="search_term", min_cost, text_contains, campaign/ad_group limits, and how to paginate with cursor. It never names an alternative sibling tool and no explicit when-not-to-use is given, so it stops short of 5.

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