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

Without annotations, the description carries full responsibility and does an excellent job by disclosing that this is a draft operation, not an immediate write, and that it returns a draftId requiring confirm_write to apply. This is crucial behavioral information beyond the tool name and 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?

The description is two sentences, front-loaded with the core action and immediate result. Every word earns its place, with no redundancy or fluff.

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 two parameters and no output schema, the description covers the input (keywords to an existing ad group), the return value (draftId), and the necessary next step (confirm_write). It is self-contained and leaves no critical 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?

The schema provides a description for adGroupId and an enum for matchType, but the description itself only mentions 'keyword criteria' without elaborating on the parameters. With 50% schema coverage, the description adds little beyond what is already in the schema, so it's adequate but not compensating.

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 clearly states the tool drafts adding one or more keyword criteria to an existing ad group, which is specific and distinguishes it from sibling tools like add_negative_keywords and update_keyword_status. It also mentions the return of a draftId and the confirm_write step, making the purpose unmistakable.

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 conveys a clear usage context: use this to draft keyword additions to an existing ad group, then call confirm_write to apply. It doesn't explicitly list alternatives or exclusions, but the workflow is clear enough that an agent can infer when to use it versus other tools like add_negative_keywords or update_keyword_status.

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 no annotations provided, the description carries the burden of disclosing behavioral traits. It clearly states that the tool only creates a draft, does not apply changes immediately, and returns a draftId that requires confirm_write. This is critical behavioral information beyond the schema and significantly improves transparency.

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 exceptionally concise: two sentences that front-load the action and purpose, then disclose the draft flow and next step. Every word earns its place with no redundant 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 two parameters and no output schema, the description is quite complete. It explains the draft behavior, return value (draftId), and follow-up action (confirm_write). It does not mention potential errors, permissions, or limits, but for the core use case it provides sufficient 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 description coverage is 50% (only adGroupId has a description). The description provides high-level context ('negative keyword criteria') but does not elaborate on the 'keywords' structure or matchType semantics. The schema already explains adGroupId, so the description adds marginal value over the schema for 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?

The description clearly states the tool's function: 'Draft adding one or more negative keyword criteria to an ad group, to stop ads showing for those terms.' This is a specific verb-resource-action combination that distinguishes it from the sibling tool 'add_keywords' (which adds positive keywords). The purpose is unambiguous and well-scoped.

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 explicitly guides usage by noting this is a 'Draft' operation and instructing to 'call confirm_write to actually apply it.' This tells the agent when to use this tool versus a direct mutation. However, it does not explicitly contrast with alternatives like 'add_keywords' or provide when-not-to-use scenarios, but the draft/confirm flow 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?

With no annotations, the description must disclose behavioral traits. It does state that the tool 'actually changes the Google Ads account,' which is a key side effect. However, it does not mention idempotency (what happens if called twice with the same draftId), preconditions beyond existence of the draft, or potential failure modes. These are relevant for a commit-like operation, so the transparency is adequate but incomplete.

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 two compact sentences, front-loaded with the primary action. Both sentences carry essential information: the first defines the action and source, the second emphasizes its unique role. There is no verbosity 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?

The tool is simple (one parameter, no output schema), and the description covers its core purpose, source context, and critical behavioral constraint. However, it does not specify the return value or any post-confirmation behaviors (e.g., whether the draft is marked as applied). For a commit-style tool, this is a minor but notable 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 0%, so the description must add meaning to the 'draftId' parameter. It does so by explaining that the draft comes from create_campaign, update_campaign_status, or add_keywords, clarifying that the ID refers to a previously drafted write. This gives the parameter operational context beyond the raw UUID schema.

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

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

The description clearly states the tool's action: 'Execute a previously drafted write... for real.' It names the resource (Google Ads account) and scope (only tool that actually changes it), which distinguishes it from sibling drafting tools like create_campaign, update_campaign_status, and add_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?

The description explicitly identifies when to use the tool: after creating a draft via specific sibling tools (create_campaign, update_campaign_status, add_keywords). It also states 'This is the only tool that actually changes the Google Ads account,' providing a clear selection criterion versus the drafting tools.

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 no annotations provided, the description carries the full burden. It discloses the draft behavior, that it returns a draftId, and that the actual creation happens later via confirm_write. However, it does not describe what happens to the draft if left unconfirmed or any permission requirements, leaving some gaps.

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 concise, front-loaded with the core action, and provides essential follow-up in a second sentence without waste. Parameter descriptions are also succinct and relevant.

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 tool has no annotations or output schema, so the description must convey the return value and side effects. It does state the return (draftId) and the need for confirm_write, covering the main context. It could be more explicit about the lifecycle of the draft, but overall it is sufficiently complete for a simple draft 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?

The schema covers 67% of parameters (campaignId and startEnabled have descriptions). The main description adds value by mentioning 'inside an existing campaign', reinforcing campaignId's meaning, but does not elaborate on the name parameter. With moderate schema coverage, the description does not fully compensate for the undocumented name field.

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 clearly states the tool drafts a new ad group inside an existing campaign, with a specific verb 'draft' and resource 'ad group'. It distinguishes itself from siblings like create_campaign and confirm_write by explaining it is only a draft and requires a follow-up confirm call.

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 explicitly tells the user to call confirm_write to actually create the ad group, clarifying when to use this tool versus the confirm step. It also implies the campaign must already exist, but does not explicitly exclude scenarios or name alternative tools for creating campaigns.

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 no annotations, the description fully carries the transparency burden. It discloses several critical behaviors: the campaign is created PAUSED by default to prevent spending, it returns a draftId, and final creation requires confirm_write. This goes beyond simple mutation and explains the draft-then-confirm pattern.

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 two sentences, front-loaded with the primary action, followed by key behavioral details. Every sentence provides essential context with no wasted words.

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

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

For a 4-param tool with no output schema and no annotations, the description covers the core workflow (draft, paused, draftId, confirm_write). It lacks some peripheral details like what happens to the draft after creation or prerequisites, but it is sufficient for an agent to use the tool 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 25% (only startEnabled has a description). The description adds meaning for dailyBudgetDollars ('its own daily budget') and startEnabled ('PAUSED by default'), but name and channelType are left to the schema's basic types/enums. It partially compensates 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 description clearly states the action: 'Draft a new campaign with its own daily budget.' It distinguishes this from a final creation by explicitly noting it returns a draftId and requires confirm_write to actually create. This sets it apart from siblings like confirm_write and update_campaign_status.

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 implies when to use it: when you want to draft a campaign rather than immediately activate it. It also instructs to 'call confirm_write to actually create it,' providing a clear next step. It doesn't explicitly mention alternatives like create_responsive_search_ad, but the workflow is well-defined.

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?

Since no annotations are provided, the description carries the full burden of behavioral disclosure. It clearly discloses that the ad is created PAUSED by default and that this is a draft operation returning a draftId for later confirmation. This goes beyond a simple 'creates' statement and reveals the two-phase behavior. However, it doesn't clarify interaction with the startEnabled parameter or the exact side effects, which prevents a higher score.

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 two concise sentences, front-loaded with the main action and essential workflow details. Every word earns its place, with no redundancy or filler. It efficiently conveys the draft/confirm mechanism and default paused status.

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 captures the essential workflow and return value (draftId), which is critical given the absence of an output schema. It sufficiently explains the tool's role within the sibling set. However, it leaves some gaps, such as the exact structure of the response beyond draftId and any prerequisites or error conditions, but these are not severe given the tool's simplicity.

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 schema covers 60% of parameters, and the description adds minimal semantic value: it explains the default paused behavior (relevant to startEnabled) and places the ad 'in an ad group' (relevant to adGroupId). However, it provides no added meaning for finalUrls, headlines, or descriptions beyond the schema constraints. Given the moderate coverage, this is adequate but not exceptional.

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 clearly states the action ('Draft a new responsive search ad'), the target resource ('responsive search ad'), and the location ('in an ad group'). It also distinguishes itself from the sibling tool confirm_write by explicitly saying that confirm_write is needed to actually create the ad. This is specific and differentiates it from other creation tools like create_campaign or create_ad_group.

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 implies a two-step workflow: use this tool to draft, then call confirm_write to commit. This provides clear context on when to use the tool. However, it doesn't explicitly state when not to use it or mention alternative tools for similar tasks (e.g., creating a different ad type), 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?

No annotations are provided, so the description carries the full burden. 'List' signals a read-only operation, and it discloses return content (status and metrics). However, it omits details like pagination behavior, default limit, or required permissions, leaving some behavioral uncertainty.

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 single, front-loaded sentence that efficiently conveys the action, scope, and return contents without unnecessary words 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?

Given no output schema and limited parameter descriptions, the description provides a basic understanding of the tool's purpose and output but lacks details about limit defaults, status filtering, and response shape. It is adequate for selection but not fully complete.

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

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

Schema description coverage is only 33%: only campaignId has a description. The description adds context for campaignId ('optionally filtered to one campaign') but does not explain the limit parameter's effect or the status parameter's filtering role, leaving two of three parameters underdocumented.

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 uses the specific verb 'List' with the explicit resource 'ad groups' and adds scope ('optionally filtered to one campaign') plus return content ('status and core performance metrics'). This clearly differentiates it from sibling tools like get_campaigns and get_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?

The description implies this tool is for listing ad groups with optional filtering by campaign, but it does not explicitly state when to prefer it over alternatives like search_gaql or get_campaigns. No exclusions or alternative-recommendation language is present.

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

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

Since no annotations are provided, the description carries the full burden for behavioral disclosure. It implies a read-only operation via 'List', but it does not disclose pagination behavior, the exact meaning of 'core performance metrics', or any potential side effects. The description is adequate for a simple list operation but lacks depth.

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 single, concise sentence that front-loads the primary action. It avoids unnecessary words and is easy to parse, making it an exemplary model of 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?

Given the tool's simplicity (2 params, no output schema, no annotations), the description is mostly adequate but lacks important details such as what 'core performance metrics' refers to, how the status filter works, and the effect of the limit parameter. It is sufficient for a basic understanding but leaves some 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?

The schema covers only 50% of parameters (status has a description, limit does not). The description does not compensate for this gap, as it only mentions status as a field in the output, not as a filter parameter. It also fails to explain the limit parameter or its default behavior, leaving the agent with incomplete information.

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 clearly states the tool lists campaigns on the configured customer account, with a specific verb ('List') and resource ('campaigns'). It distinguishes from sibling tools like get_ad_groups and get_keywords by focusing on campaigns and mentions the inclusion of status, budget, and core performance metrics.

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 provides clear context by specifying the scope ('configured customer account'), which implies it should be used for accessing campaigns on the default account. However, it does not explicitly mention alternatives or exclusions, such as when to use search_gaql for complex queries instead.

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?

No annotations are provided, so the description carries the full burden. It discloses that the tool returns match type, status, and performance metrics and supports optional filters, but it does not mention default behavior, pagination, or side effects. As a read-only listing operation, some transparency is present but lacks detail on default scope or 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 a single sentence that front-loads the main action and includes the key optional filters and returned fields. No unnecessary words 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 tool with no output schema, the description communicates that the result is a list of keyword criteria with specific attributes. It provides essential usage context (optional filters) and return indications, though it omits details like default result limits and status-as-filter, which are visible in 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?

The schema only provides descriptions for half of the parameters, so the description's mention of filtering by ad group or campaign directly adds meaning to adGroupId and campaignId. However, it does not explain the limit parameter or that status can also be used as a filter, leaving some parameter semantics implicit despite partial compensation.

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

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

The description uses a specific verb 'list' and the resource 'keyword criteria', clarifying it returns keyword data with match type, status, and performance metrics. It clearly distinguishes from sibling tools like get_campaigns and get_search_terms by targeting keywords specifically.

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 states that results can be optionally filtered to one ad group or campaign, which tells the agent when to use this tool for keyword-level data. It does not explicitly name alternatives or exclusions, but the filter options provide clear context for typical use cases.

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?

In the absence of annotations, the description relies on the verb 'List' to signal a read-only report operation. However, it does not disclose any potential caveats such as result limits, ordering, or permission requirements beyond what is implicitly suggested.

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 two succinct sentences that front-load the core purpose and then add a practical use case, with no redundant 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?

The tool has no output schema and no annotations, and the description gives only a broad 'performance metrics' without specifying which metrics are returned or how the optional parameters affect results, leaving some ambiguity for an agent.

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 schema describes campaignId but not limit or dateRange, and the description does not elaborate on any parameter semantics. With only 33% schema description coverage, the description should compensate but 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?

The description states the tool 'list[s] the actual search terms that triggered your ads, with performance metrics,' which clearly identifies the resource (search terms) and the action (list with metrics), distinguishing it from sibling tools like get_keywords or search_gaql.

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 'Useful for finding negative keyword candidates' provides a specific use case, but it does not mention when not to use the tool or name alternative tools for other scenarios.

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 no annotations provided, the description carries full responsibility for behavioral disclosure. It mentions the 'configured refresh token' as an auth context and indicates a read-only list operation by saying 'List'. However, it does not disclose pagination, rate limits, error behavior, or the exact response structure beyond 'resource names'.

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

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

The description is a single, focused sentence that is front-loaded with the action ('List') and resource. Every word earns its place, with no redundancy or extraneous detail.

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

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

Given that this is a parameterless list operation with a simple purpose, the description is largely complete. It identifies the output ('resource names') and the auth context. However, the absence of an output schema means the description could have been more explicit about the exact response format, but the level of detail is adequate for a simple 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?

The tool has zero parameters, so the baseline is 4. The description does not need to explain parameter semantics, and there is no ambiguity in invocation since no arguments are required.

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 clearly states the verb 'List' and the resource 'accessible customers' (Google Ads customer account resource names). It also specifies the scope ('reachable with the configured refresh token'), which distinguishes it from sibling tools that target campaigns, ad groups, or 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?

The description implies usage when needing to discover accessible customer accounts, but it does not explicitly state when to use this tool over alternatives like search_gaql or other list tools. There is no mention of exclusions or complementary tools, so guidance 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?

With no annotations, the description states 'Read-only' which discloses the key behavioral trait that no data is modified. However, it does not warn about potential performance issues, error handling for invalid GAQL queries, or access permissions, leaving some transparency gaps for a raw query tool.

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

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

The description is two concise sentences; the first defines the action and read-only nature, the second provides usage guidance. There is no verbosity.

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-only tool, the description gives the purpose, scope, read-only nature, and a usage guideline. It lacks explicit details about error handling or response format, but with no output schema, the description adequately covers the essentials for an agent to invoke 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?

The single parameter 'query' is fully described in the schema with an example, so the description adds little parameter-specific meaning. The tool-level description mentions raw GAQL but doesn't further elaborate on the parameter's format 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?

The description clearly states the tool runs a raw GAQL SELECT query against the configured customer account, with a specific verb and resource. It also distinguishes itself from get_campaigns by noting it's for custom reports beyond that tool's coverage.

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 explicitly recommends using this tool for custom reports beyond what get_campaigns covers, which implies get_campaigns is the alternative for standard reports. However, it doesn't enumerate other sibling tools or explicitly state when not to use, but the guidance is sufficient.

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 no annotations, the description carries the full burden of behavioral disclosure. It transparently reveals the critical non-immediate behavior: it returns a draftId and requires confirm_write to apply. This is a significant behavioral trait beyond what the schema implies. It also notes the target is 'an existing ad group,' hinting at validation. However, it does not mention error conditions, permissions, or side effects of removal.

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 exactly two sentences, front-loaded with the primary action and immediately followed by the critical return value and next step. Every word earns its place; there is no fluff or redundancy. This is a model of concise, structured documentation.

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?

Given the tool has only 2 parameters, no output schema, and no annotations, the description provides essential operational details: it is a draft operation, returns a draftId, and requires confirm_write to finalize. This is sufficient for an agent to understand the workflow. It lacks explicit notes on error handling or permissions, but those are not critical for this simple 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?

The schema describes adGroupId as 'Numeric ad group ID' but leaves status without a description. The tool description lists the possible status values (enabling, pausing, removing), which adds semantic context. However, it does not clarify parameter formats or provide additional meaning beyond the schema's enum. With schema coverage at 50%, the description only partially compensates for the missing status 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?

The description clearly states the tool's function: 'Draft enabling, pausing, or removing an existing ad group.' It uses a specific verb-resource combination and explicitly lists the three possible status changes. The mention of 'Draft' and 'confirm_write' distinguishes it from direct update tools like update_campaign_status or update_keyword_status, which likely apply 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?

The description provides clear context that this tool stages changes (returns a draftId) and that confirm_write is needed to apply them. However, it does not explicitly name alternatives or state when not to use this tool. The sibling list includes similar update tools, but the description itself does not compare or exclude them, leaving some ambiguity for 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?

With no annotations, the description carries the burden of behavioral disclosure. It clearly explains that this is a draft operation and that the actual change requires confirm_write. This is important behavioral context. It could additionally state that no changes are applied until confirmation, but the phrase 'to actually apply it' covers this.

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 concise sentences with no waste. The action is front-loaded, and the second sentence adds critical workflow information about the returned draftId and next step.

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?

Given no output schema, the description provides necessary output info (draftId) and the follow-up step. It doesn't cover prerequisites like campaign existence or permission requirements, but for a draft operation with simple parameters, it is reasonably complete. A 5 would require more detail on error conditions or limitations.

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 description adds no parameter-specific meaning beyond the schema. The schema describes campaignId but not newDailyBudgetDollars, and the description only references 'daily budget amount' generically. The parameter name is self-explanatory, but the description fails to compensate for the undocumented parameter or clarify constraints like units or positivity.

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 clearly specifies the verb 'draft changing', the resource 'daily budget amount for an existing campaign', and that it returns a draftId. This distinguishes it from sibling tools like update_campaign_status (which directly changes status) and create_campaign (which creates a campaign).

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

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

The description explicitly instructs to call confirm_write to apply the change, establishing a two-step workflow. It implies this tool is for drafting changes, not applying them, which is useful guidance. However, it doesn't explicitly state when not to use this tool or mention alternatives, though no direct budget update sibling exists.

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 no annotations, the description carries the full burden of disclosing behavior. It clearly indicates this is a draft operation that returns a draftId and requires a subsequent confirm_write call to take effect. This is a critical non-obvious behavior. However, it does not disclose potential side effects, reversibility, or prerequisites like campaign existence.

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 extremely concise, consisting of two short sentences. It front-loads the core purpose, then adds the critical draft/confirm_write detail without any fluff. Every word 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 two-parameter tool with no output schema, the description covers the essential context: what the tool does, the draft mechanism, and the required next step. It lacks some details like error handling or the meaning of 'removed', but it is sufficient for basic usage and clearly links to the confirm_write sibling.

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 schema describes campaignId but leaves status without description. The description compensates by explaining the status values as 'enabling, pausing, or removing', adding meaning to the enum. It also implies campaignId refers to an existing campaign. This goes beyond the 50% schema coverage, providing useful semantic 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 clearly states the verb and resource: enabling, pausing, or removing an existing campaign. It distinguishes from sibling tools like update_ad_group_status and update_keyword_status by specifying 'campaign'. The draft behavior is also highlighted, making the intent unambiguous.

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 provides clear context for when to use this tool: when you want to change a campaign's status, and it explicitly instructs to call confirm_write to apply the change. It implies this is a two-phase commit, but does not give explicit exclusions or compare with alternatives beyond confirming the follow-up step.

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 no annotations provided, the description carries the full burden. It explicitly discloses the most important behavior: the operation is a draft, returns a draftId, and only takes effect after calling confirm_write. While it doesn't mention error cases or permissions, the critical delayed-application trait is transparent.

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 concise, front-loaded sentences with zero filler. The action, target, and draft-draftId-confirm_write flow are efficiently communicated in a readable structure.

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 draft operation with no output schema, the description explains the return value (draftId) and the necessary next step (confirm_write), covering the essential workflow. It lacks some peripheral details like error conditions, but the core functional context 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?

The schema already provides good coverage (67%) with descriptions for adGroupId and criterionId and an enum for status. The description adds the draft/confirm context but does not enhance parameter meaning beyond the schema, so it meets 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 clearly states the action (pausing, enabling, or removing) on a keyword criterion in an ad group. It distinguishes this from sibling tools like update_campaign_status and update_ad_group_status by being keyword-specific, and the title emphasizes the draft nature.

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 clearly indicates this creates a draft and instructs to call confirm_write to apply the change, providing clear usage context. However, it does not explicitly contrast with alternatives like update_ad_group_status or state exclusions, so it lacks a full when-not-to-use explanation.

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