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

Annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=true, and the description's only behavioral claim ('read-only') simply restates that. It does not explain what the baseline consists of, whether partial failures are reported, or what access verification means in practice, adding essentially nothing beyond the structured safety profile.

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

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

It is a single front-loaded sentence with no waste. It is efficiently structured, though its brevity contributes to the vagueness noted elsewhere rather than being a flaw of 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?

An output schema and rich annotations exist, so return shape and safety need not be spelled out. However, for a composite tool that gathers identity, access, and account data across a profile and ad account, the description gives no indication of what the check validates or how to interpret results, leaving the definition under-specified.

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% and all three parameters (adamId, profile, adAccountId) are documented in the schema, so the schema carries parameter meaning. The description adds no extra syntax, format, or dependency semantics (e.g., why adamId is optional), making baseline 3 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?

The description gives a verb ('collect') and a resource ('identity, access, and account baseline'), so the reader gets the general idea of a consolidated health check. But 'baseline' is vague and the description never distinguishes this tool from adjacent siblings like auth_check, ad_account_get, or org_get, leaving ambiguity about what is actually aggregated.

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

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

There is no when-to-use guidance, no mention of prerequisites (profile and adAccountId are required), and no routing to alternatives even though auth_check and ad_account_get clearly overlap. The agent must infer the appropriate caller context entirely.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=true, so the safety profile is covered. The description adds useful context by saying the data is 'sanitized' and listing the fields read, but it does not disclose auth requirements, rate limits, or error behavior; with an output schema present, that is acceptable.

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 names the action and resource immediately. Every phrase contributes to scope and there is no repetition or 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 simple two-parameter read tool with complete schema coverage, annotations, and an output schema, the description is nearly sufficient. It tells the agent what account data is retrieved and that it is sanitized, though it lacks explicit routing guidance versus related tools.

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 fully documents both parameters. The description adds no parameter-specific meaning beyond what is in the schema, which is the expected 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 states a specific verb and resource: reading account data. It also enumerates the exact attributes returned (currency, timezone, payment model, features, delegations), which helps distinguish it from list-style siblings such as ad_accounts_list, though the single-account scope is only implicit via the required adAccountId.

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

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

There is no explicit guidance on when to use this tool versus alternatives such as ad_accounts_list or org_get. The description identifies the operation but leaves alternative selection entirely to inference.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=true, so the safety profile is covered. The description adds that results are ACLs available to a profile, but does not add further behavioral context such as pagination, rate limits, or permission requirements.

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

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

A single front-loaded sentence with no filler. The scoping condition (available to a profile) is stated immediately and 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 low-complexity list tool with full schema coverage, rich annotations, and an output schema, the description is largely complete. The main remaining gap is routing guidance against related account-listing and account-getting siblings.

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

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

Schema description coverage is 100%, and the single profile parameter is already documented as a local Apple Ads profile name. The description reinforces that the profile scopes the result to available ACLs, but adds no syntax or format detail beyond the schema.

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

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

The description gives a specific verb (Discover) and a precise resource (Apple Ads account ACLs) scoped to a profile. It is clearly a list/discovery operation, but it does not explicitly differentiate itself from siblings like ad_account_get or advertiser_resources_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?

It implies the tool is used with a profile, but does not state when to use it versus alternatives such as ad_account_get or advertiser_resources_list. There are no exclusions or prerequisite guidance beyond the required profile parameter already in the schema.

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, destructiveHint=false, and openWorldHint=true, so the safety profile is known. The description adds nothing beyond that: it does not say whether the preview validates the payload, what it returns (e.g. errors or diff), or that nothing is persisted.

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

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

A single short sentence with no filler and the key concept (preview) front-loaded. It is efficient, though its brevity comes at the cost of information rather than achieving compression of useful content.

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 takes a nested typed payload and has an output schema, so return values need not be explained, but for a preview operation in a large family of preview/apply pairs the description should clarify what the preview checks and how it relates to applying changes. One sentence is insufficient here.

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

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

Schema description coverage is 100%, including the nested payload with its required fields, so the schema carries parameter meaning. The description adds no additional semantics about profile, adAccountId, or the payload fields, making the baseline 3 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?

"Preview creation of one ad" states a verb and a resource, but it is close to a restatement of the name ad_create_preview and offers no differentiation from the many sibling preview tools (ad_update_preview, ad_delete_preview, ad_group_create_preview). It also leaves what 'preview' actually means (dry-run validation vs. draft creation) undetermined.

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

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

There is no guidance on when to call this rather than ad_update_preview, ad_get, or operations_apply. The obvious workflow implication — preview first, then apply — is never stated, so the agent must infer the tool's role in the write pipeline.

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 paired with destructiveHint=true and idempotentHint=true, so the safety profile is largely pre-disclosed. The description reinforces this with 'irreversible deletion' and adds the paused-campaign constraint, but never explains that the preview itself performs no mutation or that it must be followed by an apply step, leaving the readOnly/destructive pairing to be inferred.

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

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

A single front-loaded sentence with the destructive scope and precondition stated first. No filler, nothing redundant, nothing buried.

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?

An output schema exists, so return values need no explanation, and the schema covers most parameters. However, for a high-stakes deletion preview with four required parameters and an expectedText confirmation argument, the description never mentions the confirmation requirement or the preview-to-apply lifecycle, which 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?

The description's 'one ad' maps directly to the id parameter, and the schema already documents 75% of parameters including profile and adAccountId. It does not explain expectedText as an exact-match confirmation guardrail, which is the most important semantic behavior of this schema, so a small gap remains.

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

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

The description states a specific verb (preview deletion) and a precise resource scope ('one ad'), which lets an agent distinguish it from the many sibling delete-preview tools (ad_group_delete_preview, campaign_delete_preview, keyword_delete_preview, creative_delete_preview). It stops short of naming those siblings explicitly, but the singular-ad scope is 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?

It supplies one real precondition ('under a paused campaign'), which implies the when-to-use context, but gives no guidance on what to do after the preview, how it relates to the corresponding apply step (operations_apply / ad_delete execution), or when a caller should skip the preview. Usage is implied 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, idempotentHint and openWorldHint, so the safety profile is fully carried by structured data. The description adds only the hint that results reflect current state; it says nothing about authentication/profile scoping or failure behavior.

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

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

A single short sentence with the verb and scope front-loaded; nothing is wasted, though there is very little substance for the space available.

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?

An output schema exists and annotations cover the safety profile, so the description need not explain return values or side effects. The remaining gap is minor: it never clarifies which identifier to supply when both 'id' and 'adId' are present.

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

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

Schema description coverage is 100%, so the four parameters are already documented, giving the baseline of 3. The description adds no disambiguation between the two identifier parameters (legacy 'id' vs 'adId'), which is the one piece of meaning it could usefully contribute.

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 ('Read one ad by ID'), and 'one' plus 'for current-state verification' implicitly separates it from the bulk/snapshot siblings like ads_query and ad_report. It stops short of naming any sibling explicitly.

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

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

'For current-state verification' implies the intended context (fetch fresh single-record state rather than a report or list), but there is no explicit when-to-use/when-not guidance and no alternative tool is named.

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

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

The description is consistent with the annotations: 'preview' matching readOnlyHint=true and destructiveHint=false, so no contradiction. It adds little beyond the structured hints though — no statement about whether the preview validates against budget caps or account constraints, and no mention of the preview-then-apply handoff, which is the behavior an agent most needs disclosed here.

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

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

A single front-loaded sentence with no filler; the object of the operation and the key value fields come first. It is efficient, though its brevity is what leaves the workflow gaps above.

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?

An output schema exists, so return values need not be described, and the safety profile is covered by annotations. What is missing is exactly the context a preview tool requires: that it is a dry-run whose output must be applied via the operations tooling, and how it relates to the update/bid siblings.

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

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

Schema description coverage is 100% with all five required parameters documented, so the baseline is 3. The description echoes 'decimal amount and currency', which slightly reinforces the format expectation but adds no constraint (e.g. currency must match the account's currency) beyond what the schema already states.

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: previewing an ad-group default bid update, with the two value-bearing fields (amount, currency) called out. It is distinguishable from campaign_bid_strategy_preview and keyword_bid_preview by resource, but it never clarifies how it differs from the closely-named sibling ad_group_update_preview, which plausibly also touches bids.

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

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

No guidance on when to choose this over ad_group_update_preview, ad_group_cpa_cap_preview, or the other bid-related preview siblings. Critically for a *preview tool, it never says that producing a preview is only step one and that operations_apply (or operations_inspect) must follow to commit the change, so an agent has to infer the whole workflow.

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

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

Annotations already declare readOnly, idempotent, non-destructive, and open-world, so the safety profile is covered. The description adds genuinely new context: Apple deprecated it and it will not silently convert to a new bid strategy, which changes how an agent should interpret the preview result.

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

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

A single compact sentence that front-loads the most important fact (deprecation) and packs the compatibility caveat into the same clause. Nothing is redundant.

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

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

With a full schema, an output schema, and rich annotations, the description only needs to add the deprecation and no-conversion semantics, which it does. Slightly more detail on what the preview returns or when to prefer the modern alternative would complete 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?

Schema coverage is 100% and every parameter (amount, currency, profile, adAccountId, adGroupId) is documented in the schema. The description adds no parameter-level guidance such as currency/amount units or ID format, so baseline 3 applies.

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

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

Names a specific verb (preview) and resource (legacy ad-group CPA cap update), which is more specific than the sibling ad_group_update_preview. It does not explicitly contrast with ad_group_bid_preview or target_cpa_recommendation_apply_preview, so an agent must still infer the boundary, keeping it below a 5.

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

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

The deprecation notice and 'retained for compatibility' hint that new work should avoid this tool, but there is no explicit 'use X instead' routing to the modern CPA/bid strategy preview tools. Usage is implied 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, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds that this is a preview of creation rather than an actual write, which is useful context, but it does not explain validation behavior, permissions, or what the preview returns.

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

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

The description is a single front-loaded sentence with zero waste. It is perhaps under-specified for the complexity of the nested payload, but from a pure conciseness and structure standpoint it is efficient.

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

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

The tool has an output schema, rich annotations, and full schema coverage, which carry much of the documentation burden. However, the description does not explain how this preview should be used relative to the actual creation/apply workflow, leaving a notable gap for an agent deciding when and how to invoke 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?

Schema description coverage is 100%, and the schema itself documents profile, adAccountId, and the nested payload fields. The description adds no parameter-specific meaning beyond the schema, so the baseline score of 3 is appropriate.

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

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

The description states a specific verb+resource combination: 'Preview creation' of 'one ad group'. It clearly distinguishes creation from siblings such as ad_group_update_preview and ad_group_delete_preview by naming the operation, though it does not explicitly call out those alternatives.

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 no explicit guidance on when to use this preview tool versus alternatives such as operations_apply, operations_verify, or other ad-group preview tools. At most, 'Preview creation' implies a pre-creation validation use case, but no conditions, exclusions, or alternatives are 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, destructiveHint=true, idempotentHint=true, and openWorldHint=true. The description adds useful context that the deletion is irreversible and the campaign must be paused, but it does not explain preview mechanics, what the output represents, or how expectedText protects against mistakes.

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 with no wasted words. The core action and scope appear immediately.

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?

An output schema exists and annotations are rich, so the description need not explain return values. However, for a destructive preview tool with a required expectedText guard, the description should clarify that this is a dry-run preview and why expectedText is required.

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

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

Schema coverage is 75%, with descriptions for profile, adAccountId, and expectedText, while the id parameter is undocumented. The description itself adds no parameter-level meaning, so the schema remains the primary source.

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

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

The description gives a specific verb, resource, and scope: previewing deletion of one ad group. It distinguishes itself from campaign_delete_preview and ad_delete_preview by resource, though it does not explicitly name those alternatives.

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 'under a paused campaign' implies a precondition for use, but there is no explicit guidance on when to choose this preview versus ad_group_get, ad_group_update_preview, or another delete preview. Usage is inferable but not clearly routed.

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, so the safety profile is clear. The description adds that the result is for 'current-state verification,' but does not describe error handling, missing-record behavior, or account/profile scoping beyond what the schema states.

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

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

It is a single front-loaded sentence with no wasted words. The tradeoff is that it is very terse, but conciseness itself is strong.

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 simple get tool with annotations and an output schema, the description is minimally sufficient. However, it omits material invocation context around the two ID fields and does not describe expected behavior when the ad group is absent.

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 parameters are already documented. The description says 'by ID' but does not clarify the presence of both `id` (legacy) and `adGroupId` parameters, leaving the agent to rely entirely on the schema for that distinction.

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

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

The description gives a specific verb and resource: 'Read one ad group by ID.' It clearly distinguishes a single-item fetch from siblings like ad_groups_query or ad_group_report, though it does not name those alternatives.

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 'for current-state verification' implies a use case but does not explicitly state when to use this versus ad_groups_query, ad_group_report, or other sibling tools. No exclusions or prerequisites are given.

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 destructiveHint=false, and the description is consistent with that. But the description adds nothing beyond structured fields: it never says what a 'preview' returns, whether it mutates state, or that an apply step is required afterward.

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

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

A single short sentence with no waste, but it is under-specified rather than concise. It is front-loaded with the verb, yet the brevity leaves key semantics unexplained.

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?

An output schema exists, so return values needn't be spelled out, but for a preview tool in a large family of preview/apply siblings the description should at least signal the dry-run nature and the follow-up step. With one of three params undocumented and no workflow context, it is insufficient.

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

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

Schema coverage is 67%: profile and adAccountId are documented in the schema, but 'id' has no description in either place. The description does not clarify that 'id' is the ad group identifier or how it interacts with the ad account scope, so the coverage gap is left unaddressed.

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

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

States a specific verb and resource ('pausing one ad group') qualified by 'preview', so the agent can tell it targets ad groups rather than campaigns, ads, or keywords. However, it does not explain what 'preview' means or distinguish this from the many sibling *_preview tools beyond the resource name.

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

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

There is no guidance on when to use this versus ad_pause_preview, campaign_pause_preview, ad_group_resume_preview, or operations_apply. The preview-then-apply workflow that presumably governs this tool family is never mentioned.

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

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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so the safety profile is covered. Beyond that the description adds only the vague adjective 'bounded', which is never explained (page-size cap? row limits? date bounds?). It says nothing about rate limits, data freshness, or what happens when the window is exceeded.

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

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

A single clause with no filler, so it is certainly concise. But it is compressed past usefulness — 'bounded' and 'rows' are the only content beyond the name, which reads as under-specification rather than disciplined brevity.

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?

An output schema exists, so return values need not be explained, and the schema covers parameters fully. However, for a 9-parameter reporting tool sitting among several sibling report tools, the definition leaves the agent without the routing and report-shape context needed to invoke it confidently.

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

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

Schema description coverage is 100%, so every one of the 9 parameters (fields, filters, groupBy, sorting, timeRange, pagination, profile, adAccountId) is already documented in the schema. The description contributes nothing further about parameter semantics, 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 ('Read') and resource ('ad-group performance rows'), and the word 'bounded' signals a windowed/paginated result. It does not distinguish this from close siblings like ad_report, campaign_report, or keyword_report beyond the resource level implied by the name.

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

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

No when-to-use guidance and no exclusions. With four report tools in the sibling list (ad_report, campaign_report, keyword_report, search_term_report), an agent gets no help deciding which aggregation level or report type to pick, nor any hint about prerequisites such as needing a valid profile and ad account.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, which covers the safety and idempotency profile. The description reinforces that this is a preview rather than an actual resume, but it adds little beyond the annotations and does not explain what the preview output allows the caller to do.

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

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

The description is a single front-loaded sentence with no filler. It is appropriately concise for a simple preview tool, though its brevity is partly why other dimensions lack guidance.

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 simple three-parameter schema, annotations, and an output schema, the description is minimally adequate. However, it does not clarify the preview-to-apply workflow, the role of the id parameter, or when this preview should be chosen over sibling preview tools.

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

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

Schema coverage is 67%: profile and adAccountId are described in the schema, while id has no schema description. The description's phrase 'one ad group' implicitly identifies id as the ad group identifier, but it adds no format or constraint details 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 states a specific action and resource: previewing the resumption of one ad group. It is clear enough to distinguish this as an ad-group-level preview rather than an ad or campaign preview, but it does not explicitly contrast with siblings such as ad_group_pause_preview or ad_resume_preview.

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 no explicit guidance on when to use this preview versus related tools such as ad_group_get, ad_group_update_preview, or operations_apply. The word 'Preview' implies a read-only preflight step, but the description does not state prerequisites, exclusions, or next steps.

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, destructiveHint=false and openWorldHint=true, so the safety profile is fully covered. The description adds nothing beyond that — it doesn't explain what the preview output contains or whether the preview has side effects.

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

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

A single tight sentence with no filler and the key concepts front-loaded. Brevity is appropriate, though it leaves gaps noted elsewhere.

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?

An output schema exists, so return values needn't be explained. However, for a 5-parameter scheduling tool with 40% schema coverage and an openWorld read, the description should at least clarify the time format and the apply-after-preview workflow.

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

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

Schema description coverage is only 40% (only profile and adAccountId are documented). The description says nothing about startTime/endTime, which are nullable strings with no stated format, timezone, or null semantics — a critical gap for a scheduling 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 (Preview) and resource (ad-group start/end schedule update), distinguishing it from the sibling campaign_schedule_preview by scope. It doesn't explicitly name alternatives, but the resource is 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 'preview' naming convention implies this is a dry-run before an apply step, but the description never states when to use it versus ad_group_update_preview or how the previewed change is committed. Usage is only inferable from the tool family pattern.

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 destructiveHint=false, so the safety profile is covered structurally. The description adds that this is a preview of a state change, but says nothing about whether the preview must be applied via a separate step, how long it is valid, or that it hits the live Apple Ads API (openWorldHint).

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

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

A single front-loaded sentence with no filler; the action and target are the first things 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?

An output schema exists, so return values need not be explained, and annotations cover the safety profile. Still, for a 4-required-parameter mutation-preview with half the schema undocumented, the description leaves the preview-to-apply lifecycle and any placement-type constraints (Search Results only) unaddressed.

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

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

Schema coverage is only 50%: adGroupId and enabled are undocumented in the schema. The description compensates by making 'enabling or disabling' the meaning of the enabled flag and by binding the operation to a specific ad group, so the agent can map the required inputs without guessing.

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

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

The description states a specific verb (preview enabling/disabling) and a specific resource (Apple Search Match on a Search Results ad group), which clearly separates it from the many pause/resume/bid preview siblings. It stops short of naming a concrete alternative or follow-up tool, so an agent must infer the surrounding workflow.

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

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

The word 'Preview' implies a dry-run before applying, but the description never says when to prefer this over e.g. ad_group_update_preview or how the preview is committed (operations_apply). Usage is only implied, not 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, idempotentHint, and openWorldHint, so the safety profile is covered. The description adds only 'bounded' and 'endpoint-specific filters', which are vague and largely restate schema concepts; it does not explain pagination behavior, result breadth, or the meaning of endpoint-specific beyond what structured fields already provide.

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

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

The description is a single, front-loaded sentence with no filler. It is appropriately sized, though its brevity contributes to under-specification rather than being a model of economical clarity.

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

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

For a 12-parameter query tool with many overlapping siblings, the description is too thin. Even with an output schema and rich annotations, it does not clarify the tool's scope, endpoint-specific behavior, or how it relates to ad_group_get and ad_group_report.

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

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

Schema description coverage is 100%, so all 12 parameters are already documented in the input schema. The description mentions 'filters' but adds no syntax, constraints, or prioritization beyond the schema, which is the expected baseline when the schema does the heavy lifting.

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

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

The description states a verb and resource ('Query ... ad groups') and adds a qualifier ('bounded', 'endpoint-specific filters'), so the broad function is clear. However, it does not distinguish this tool from closely named siblings such as ad_group_get, ad_group_report, ads_query, or keyword_report, leaving the specific purpose ambiguous.

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 no conditions for when to use this tool versus alternatives. It does not mention prerequisites, when to avoid it, or how it differs from ad_group_get or ad_group_report, so an agent must infer usage from the name and schema alone.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=true, covering the safety profile. The description adds only the phrase 'App Store-only' and does not explain what the preview returns, whether it validates targeting, or any side effects or constraints.

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 with no wasted words. However, for a tool with a complex nested targeting schema, it is too terse to be structurally adequate.

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 four required parameters, nested targeting objects, and an output schema, indicating a fairly complex preview operation. The description does almost nothing to explain the preview semantics, validation behavior, or App Store-only scope, leaving significant gaps beyond structured fields.

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

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

Schema description coverage is only 50%, and the description provides no parameter meaning at all. Required parameters such as adGroupId and the nested targeting structure are left almost entirely to the schema, which itself provides only generic descriptions for include/exclude arrays.

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

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

The description names a preview operation for ad-group targeting, so the basic verb and resource are identifiable. However, 'App Store-only' is not explained and the description does not clarify what targeting aspects are previewed or how this differs from other ad_group_* preview 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?

There is no guidance on when to use this tool, when not to use it, or which sibling tools are alternatives. The agent is left to infer that this is a preflight check rather than an update or query.

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

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

The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the non-mutating nature is covered. The description adds little beyond the name and annotations: it does not explain that the payload is validated without being applied, what preview result is produced, or how it relates to an eventual apply step.

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

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

The single sentence is front-loaded and free of fluff. It is efficient, though its brevity means it is underspecified for a complex nested update payload; that gap is better reflected in contextual completeness.

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?

This is a complex update-preview tool with a large nested payload and many sibling preview tools. The output schema and annotations cover return shape and safety, but the description does not explain partial-vs-full update semantics, validation behavior, or when this generic preview should be used instead of the specialized ones.

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 complex payload fields, targeting structure, and deprecated cpaCap are documented in the schema. The description adds no parameter-level semantics, but the baseline is 3 when the schema already carries this burden.

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

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

The description states a verb and resource ('Preview an ad-group update'), so the general purpose is inferable. However, it does not clarify what a preview means here or distinguish this broad update preview from siblings such as ad_group_targeting_preview, ad_group_bid_preview, or ad_group_cpa_cap_preview.

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

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

There is no guidance on when to use this tool rather than the more specific ad-group preview tools or when a preview is required before an update. The agent must infer usage entirely from the name and sibling context.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false. The description adds almost nothing beyond restating the tool name; it does not explain what the preview returns, whether it mutates state, or what happens after previewing.

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 four-word description is maximally front-loaded and wastes no space, but it is under-specified rather than usefully concise. Brevity here sacrifices necessary context for a tool with three required parameters.

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?

An output schema exists, so return-value explanation is not required, and annotations cover read-only/idempotent semantics. Still missing is guidance on how the preview fits into the broader workflow (e.g., pairing with operations_apply) and what preview results represent.

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

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

Schema coverage is 67%, with 'id' undocumented in the schema. The description provides no parameter meaning, formats, or constraints, so it does not compensate for the coverage gap on the required 'id' 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?

States a specific verb ('Preview pausing') and resource ('one ad'), which distinguishes it from ad_resume_preview, ad_delete_preview, and ad_update_preview. However, it does not explicitly differentiate from vaguely named siblings like ad_get or operations_inspect.

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

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

No guidance on when to use this instead of ad_pause_preview's alternatives, whether it must be followed by operations_apply, or what conditions make preview appropriate. The agent must infer usage from the name alone.

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

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

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so safety behavior is covered structurally. The description adds only the vague notion of 'bounded' rows and provides no additional context about scoping, limits, or reporting behavior beyond what the annotations and schema already convey.

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

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

The description is a single front-loaded sentence with no wasted words. It is concise, though its brevity borders on under-specification for a nine-parameter reporting tool.

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

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

Although the schema and output schema are rich, the description does not explain the tool's place among many sibling report tools or clarify what 'ad performance rows' covers. For a complex, nine-parameter reporting endpoint, this leaves important selection context missing.

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

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

Schema description coverage is 100%, so all nine parameters are documented in the input schema. The description itself adds no parameter-specific meaning, which is acceptable at baseline when the schema does the heavy lifting.

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

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

The description states a specific verb and resource: reading ad performance rows. It is clear at a high level, but it does not distinguish this ad-level report from sibling report tools such as campaign_report, ad_group_report, or keyword_report.

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

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

There is no guidance on when to use this tool versus the many sibling reporting tools. The word 'bounded' hints at pagination but does not explain prerequisites, appropriate reporting contexts, or exclusions.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is covered. The description contributes the key framing that this is a preview rather than an actual state change, but it does not say whether the preview must be followed by an apply call to take effect or what a rejected preview looks like.

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

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

A single front-loaded sentence with no filler and no redundancy. Its brevity edges toward under-specification rather than elegance, but structurally 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?

An output schema exists, so return values need not be explained, and annotations cover safety. What remains missing is the operational context an agent needs: how this preview relates to operations_apply and whether a preview expires or must be immediately consumed.

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 mid-range (67%) and the undescribed field is 'id', whose meaning ('the ad to resume') and accepted format are never clarified in the description. The description adds no meaning beyond the property names, leaving the parameter gap unaddressed.

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

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

States a specific verb ('Preview resuming') and resource ('one ad'), which cleanly separates it from ad_pause_preview and the campaign/campaign-group resume variants. What 'preview' concretely produces versus a real resume is left implicit, but the action itself is 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?

No guidance on when to prefer this over a direct resume path, no mention of a prerequisite like ad_get to obtain the id, and no explanation of the preview-to-apply workflow despite operations_apply existing as a sibling. The agent must infer the entire usage context.

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

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

Annotations already declare readOnly, idempotent, and openWorld, so the safety profile is fully covered by structured data. The description adds only the vague notion that results are "bounded" and filtering is endpoint-dependent, saying nothing about scope resolution order for the id/adId/campaignId/adGroupId shortcuts or how pagination bounds results.

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

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

A single front-loaded sentence with zero filler. It is efficient, though the brevity is partly a symptom of under-specification rather than disciplined compression.

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 13-parameter query tool with shortcut scoping fields, nested filter/sort/timeRange objects, and pagination, one sentence is far too thin, even with an output schema and rich inline parameter docs. The agent is left to infer precedence between id/adId and the campaign/adGroup scope shortcuts, and what "bounded" actually enforces.

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 every parameter is already documented inline and the baseline is 3. The description's "endpoint-specific filters" is consistent with the filters property but provides no additional syntax, precedence, or combination guidance.

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?

"Query bounded ads" gives a verb (query) and a resource (ads), so the purpose is identifiable, but "bounded" is unexplained and the phrasing does not distinguish this from close siblings like ad_report, ad_get, or ad_groups_query. An agent can guess it is a filtered/segmented ad list, but only by inference.

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

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

There is no statement of when to use this versus ad_report, ad_get, or ad_group_report, and no exclusions or prerequisites. "endpoint-specific filters" implies variability but never tells the agent how to choose the right entry point.

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

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

The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, and the description mostly restates the 'preview' idea. It adds no details about what previewing means here, such as whether it validates the payload, returns a diff, or has any side effects.

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 short, front-loaded, and free of waste. Its brevity is structurally clean, although the missing detail is penalized in other dimensions.

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 four required parameters, a nested payload, and real sibling alternatives, the description does almost nothing to explain the preview workflow. The output schema and annotations reduce some burden, but an agent still lacks essential context on the tool's role.

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 itself documents profile, adAccountId, id, and the nested payload fields. The description adds no parameter meaning beyond that baseline, which is acceptable only because the schema is complete.

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

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

The description states a specific verb and resource: previewing an ad update. It is clear what the tool acts on, but it does not distinguish this preview from nearby siblings such as ad_pause_preview, ad_resume_preview, or ad_group_update_preview.

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

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

It gives no guidance on when to use this preview instead of ad_get, an apply operation, or other ad-related preview tools. The word 'preview' implies a pre-apply check, but no alternatives or conditions are named.

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

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint, so the safety and idempotency profile is covered. The description adds only the scoping note that results are bounded by a profile; it says nothing about whether the listing hits a live Apple Ads endpoint, whether an empty result is normal, or what the delegations represent.

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

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

A single front-loaded sentence with no filler or repetition. It is efficiently sized, though it is terse to the point of leaving the domain term 'content-provider delegations' unexplained.

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 an output schema present and both parameters fully documented in the schema, the description needn't explain return values, so the essentials are covered. However, for a tool whose subject matter (content-provider delegations) is obscure, one clause on what it returns or when it is empty would make the definition fully self-sufficient.

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% for both parameters, so the baseline of 3 applies. The description reinforces that 'profile' scopes the result set but adds no semantics for adAccountId or for how the two required parameters interact.

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

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

The description names a specific verb (List) and a specific resource (App Store content-provider delegations) scoped to a profile, which is enough to distinguish it from query-style siblings like product_pages_query or apps_search. It stops short of naming a sibling it should be preferred over.

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

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

There is no statement of when to call this tool, what prerequisite state it assumes, or which sibling to use instead for related advertiser/resource lookups. The only guidance is the implicit 'list available to a profile', leaving the agent to infer applicability.

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, so safety is covered. The description adds the meaningful constraint that full-asset mode works for exactly one languageCode, but it never explains what 'compact metadata' vs 'full assets' actually contain or how the report-style parameters behave for this endpoint.

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

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

A single sentence, zero filler, with the primary mode stated first and the alternate mode immediately after. Nothing to trim.

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?

Rich structured data (100% schema coverage, output schema, read-only annotations) means the description needn't explain returns or safety. But for a 12-parameter tool it leaves the agent guessing about sibling choice and about how the generic report-style parameters apply to a locale lookup.

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; the description earns a nudge above baseline by making explicit the conditional relationship between languageCode and includeAssets that is only scattered across individual field descriptions. It still does not clarify why report parameters like timeRange, groupBy, filters or sorting exist on a locale endpoint.

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 ('Query compact locale metadata, or full assets') and distinguishes its two operating modes. However, it does not differentiate itself from similarly-purposed siblings such as product_page_locales and supported_app_languages, leaving the agent to infer which locale source to use.

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 two modes are implied: default returns compact metadata, while supplying a languageCode with includeAssets returns full assets. There is no explicit 'use this when...' guidance and no mention of the alternative locale-related tools, so routing relies on 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 state readOnlyHint, idempotentHint, and openWorldHint, so the safety profile is covered structurally. The description adds nothing beyond that: it doesn't say what 'collect' entails (live calls? aggregation?), whether it is expensive or rate-limited, or what it produces. The jargon 'independently classified' is not explained.

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

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

It is a single short sentence with no padding, which is good, but the brevity comes at the cost of clarity — the one sentence is front-loaded with an undefined term rather than a concrete purpose. Short without being informative.

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

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

For a tool with four required parameters and an output schema, the description is too thin: it doesn't state the use case, how the collected sections relate to eligibility/suggestion output, or why an agent should pick this over apps_eligibility. The output schema covers return shape, but the selection rationale is missing.

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

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

Schema description coverage is 100%, so all five parameters (terms, adamId, profile, adAccountId, countriesOrRegions) are documented in the schema. The description adds no meaning about how these parameters scope the result, so the baseline 3 applies.

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

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

The verb 'Collect' plus the phrase 'eligibility and suggestion sections for an app' gestures at what the tool returns, but 'independently classified sections' is unexplained jargon. Nothing distinguishes it from close siblings like apps_eligibility, keyword_suggestions, or category_suggestions, so an agent cannot confidently pick it over those.

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 contains no when-to-use guidance, no prerequisites (profile, adAccountId), and no mention of alternatives. An agent must infer its role relative to apps_eligibility and the various *_suggestions tools entirely on its own.

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

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

The annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so the safety profile is covered elsewhere. The description is consistent with those annotations ("Read") but adds no behavioral context of its own, such as error behavior for an invalid rejectionReasonId or what openWorld access implies.

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

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

A single, front-loaded sentence with zero waste, appropriate for a simple read tool. It is arguably too terse to be maximally helpful, but nothing in it is redundant.

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

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

An output schema exists, annotations are rich, and parameters are fully documented, so the description only needs to carry routing and context. It falls short on sibling differentiation against app_rejection_reasons_query, which is the one gap an agent would actually need filled.

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

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

Schema description coverage is 100%, so all three parameters (profile, adAccountId, rejectionReasonId) are documented in the schema itself. The description adds no parameter-level meaning beyond that, which is the baseline expectation when the schema does the heavy lifting.

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

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

States a specific verb ("Read") and resource ("App Store app rejection reason") with singular scope ("one"). It is clear on its own, but it does not distinguish itself from the sibling app_rejection_reasons_query tool, which likely lists the same resource.

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

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

There is no guidance on when to use this single-item lookup versus app_rejection_reasons_query, and no mention of prerequisites such as needing a valid ad account or profile. The agent must infer the choice from the tool name alone.

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

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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so the safety profile is covered. The description adds only 'bounded,' which loosely signals a limited result window. With annotations carrying the behavioral burden, a 3 is appropriate.

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

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

A single front-loaded sentence with no waste. It is efficient but nearly silent on key selection criteria and scope details.

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 nine parameters, a nested filters/sorting/timeRange schema, and a full output schema, the description is thin but not incomplete enough to be misleading – the schema and output schema compensate. It would benefit from naming the required profile/adAccountId context and the bounded-window behavior.

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

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

Schema description coverage is 100%, so all nine parameters are documented in the schema. The description adds no parameter-level meaning beyond echoing 'bounded' pagination. Baseline 3 is correct when the schema does the heavy lifting.

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 ('Query') and resource ('App Store app rejection reasons'), plus a scope hint ('bounded'). It does not explicitly distinguish itself from the sibling app_rejection_reason_get, so the single-record vs. list distinction must be inferred from the word 'Query'.

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

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

No guidance on when to use this versus app_rejection_reason_get, or what prerequisites (profile, adAccountId) are needed. The agent must infer usage from the name alone.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true and openWorldHint=true, so the safety profile is covered. The description adds nothing beyond that — it doesn't say whether the call hits Apple's API live (openWorld), whether results are scoped to the ad account or the app, or what the check actually evaluates.

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 single sentence is front-loaded and free of waste, but at that length it is under-specified rather than efficient — there is no second sentence carrying the distinctions the agent needs.

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

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

With nine parameters including time ranges, filters and pagination, and no app identifier, the description should explain what is being checked and which parameters are actually relevant. The output schema covers return values, but the input-side ambiguity is unaddressed.

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

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

Schema description coverage is 100%, so every one of the nine parameters is documented in the schema and the description is not required to compensate. However, it offers no explanation for why a reporting-style surface (fields, filters, timeRange, pagination) accompanies an eligibility check, leaving the agent to guess which params matter.

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

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

The description gives a clear verb ('Check') and a domain resource ('App Store advertising eligibility'), but leaves 'eligibility' undefined and never says whose eligibility — no app identifier appears in the parameter list, so an agent cannot tell whether this answers per-app or per-account questions or how it differs from siblings like apps_get and apps_search.

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

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

There is no statement of when to use this instead of apps_get, apps_search, or app_opportunities, and no prerequisites or exclusions are given. The agent must infer from the name alone that this is a pre-flight check.

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, openWorldHint, and idempotentHint, so the safety profile is covered. The description adds essentially nothing beyond that—no note on permissions, profile/ad-account context, or behavior when the app is unknown—so it contributes little behavioral context.

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

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

A single front-loaded sentence with no waste. It is efficient, though the extreme brevity leaves little room for added detail, keeping it just under a 5.

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

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

With an output schema present and all three parameters documented, the description need not explain return values. For a simple read tool it is adequate, but it omits any hint about profile/ad-account context that an agent must supply on every call.

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

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

Schema description coverage is 100%, so adamId, profile, and adAccountId are fully documented in the schema. The description only echoes the adamId lookup, 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+resource ('Read an App Store app') with a clear lookup key ('by Adam ID'), which meaningfully separates it from apps_search and apps_eligibility. It doesn't explicitly name a sibling, so it falls short of a 5.

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

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

The phrase 'by Adam ID' implies direct identifier lookup rather than search, which is implicit usage guidance. There is no explicit when-to-use, when-not-to-use, or named alternative such as apps_search.

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

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

Annotations already declare readOnly, idempotent, and openWorld, so safety is covered. The description adds one genuinely non-obvious behavior — a single bounded exact-name retry when a non-ASCII owned-app query returns empty — but omits broader behavior such as pagination, default limit, or result ordering.

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

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

One compact sentence with the verb front-loaded and no filler. The only quibble is proportion: most of the sentence is spent on a narrow fallback while the primary operation is compressed to two 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 an 8-parameter search tool with 3 required parameters, the description never states what is being searched, whether results are owned apps or store listings, or how the filters interact. The output schema and annotations cover returns and safety, but the search semantics — the agent's main uncertainty — are left unaddressed.

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

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

Schema description coverage is 100% across all 8 parameters, so the schema does the heavy lifting and a 3 baseline applies. The description contributes nothing about how query, cpids, storefronts, and returnOwnedApps combine.

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?

"Search apps" gives a verb and resource, but it doesn't say what corpus is searched (App Store catalog vs. the organization's owned apps) or how it differs from siblings like apps_get and app_store_geo_search. The remainder of the sentence describes an edge-case fallback rather than clarifying the core purpose.

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

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

There is no statement of when to use this tool versus apps_get, apps_eligibility, or app_store_geo_search, nor any prerequisite guidance. The fallback clause describes internal behavior, not a selection rule 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?

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is covered. The description adds nothing behavioral—no pagination limits (pageSize max 200), no explanation of what 'soft-blocked' means for the eligible flag, and 'eligible' in the description mildly conflicts with the fact that filtering is opt-in via the eligible parameter.

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

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

A single front-loaded sentence with no padding. It is short to the point of omitting context an agent would want, 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 8 params at full schema coverage, an output schema, and annotations present, the structured data carries most of the load. The description is still thin on usage context and on the semantics of the eligible/countryCode filters, which is the remaining gap.

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

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

Schema description coverage is 100%, so all eight parameters are already documented, giving baseline 3. The description restates three of the entity types but adds no syntax, defaults, or interaction details (e.g., how countryCode interacts with query) beyond the schema.

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

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

States a specific verb ('Search') and resource ('App Store countries, administrative areas, and localities'), which maps directly to the entity parameter values. No sibling tool covers geo search, so differentiation is implicit rather than stated, and the word 'eligible' slightly muddies scope since eligibility is actually opt-in via a parameter.

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

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

No guidance on when to use this vs. related lookups (campaign_countries_preview, apps_eligibility, category_suggestions), no mention of the two required parameters being prerequisites (profile, adAccountId), and no note on the minimum query length rule beyond the schema.

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, so the safety profile is covered by structured data. The description adds that the call returns identity, which is useful context beyond the annotations. It says nothing about failure behavior (what an invalid/expired credential produces) or that it touches an external OAuth endpoint, which is the main missing behavioral detail.

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

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

One sentence, action-first, zero filler. Nothing could be removed without losing information.

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

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

An output schema exists and the sole parameter is fully documented, so the description only needs to state intent and return shape, which it does. The remaining gap is error/negative-path behavior, which an agent calling an auth check would plausibly want.

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% for the single `profile` parameter, so the schema documents it fully and the baseline is 3. The description mentions no parameter at all, so it neither adds meaning nor compensates for anything — it simply relies on 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?

Specific verb+resource: validate OAuth credentials and return the caller identity. An agent immediately knows this is a credential/identity check rather than a data query, and no sibling covers that ground. It loses a point because it never reconciles 'caller identity' with the required `profile` argument (a local profile name), which is the more important semantic detail.

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

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

No when-to-use, when-not-to-use, or alternative is stated. An agent must infer that this is a pre-flight sanity check to run before other calls; nothing in the text says whether it is required first, optional, or a diagnostic only.

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

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

The readOnlyHint, idempotentHint, and openWorldHint annotations already establish safety and network behavior. The description adds that the tool gathers baselines across four report levels, which is useful context, but it does not explain whether all four are returned together, whether anything persists, or any rate-limit/auth nuance. With annotations covering the safety profile, this is adequate but not rich.

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 with no filler. It is appropriately sized and immediately states the resource scope.

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 nine-parameter tool with an output schema and safety annotations, the description gives only the broad collection scope. It leaves the meaning of 'baseline', the aggregation behavior, and the choice against sibling report tools implicit, so it is only partially complete for tool selection.

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%, and the schema documents all nine parameters including profile, adAccountId, timeRange, filters, and pagination. The description adds no parameter-level detail, so it neither helps nor hurts beyond the schema; the baseline is 3.

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

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

The description uses a specific verb ('Collect') and names the four report domains whose baselines are gathered. It is distinguishable from single-report siblings like campaign_report because it lists all four levels, though it does not define what a 'baseline' 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?

There is no explicit when-to-use guidance, no exclusions, and no mention of sibling report tools or optimization_baseline. An agent can infer it is for baseline collection, but the description does not say when this tool is preferable to campaign_report, ad_group_report, keyword_report, or search_term_report.

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, destructiveHint=false, so the safety profile is covered. The description adds one piece of behavioral context — the eligibility gate on MAX_CONVERSIONS — but does not state whether the call validates the strategy, what it returns, or how eligibility failure surfaces; output schema covers return values only.

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

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

A single sentence with no filler and the eligibility qualifier front-loaded. It is efficient but borders on under-specified rather than maximally concise.

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 annotations, an output schema, and nested enum-constrained params, most structure is covered elsewhere, so the description only needs to add preview semantics and eligibility rules. It half-does that: the MAX_CONVERSIONS constraint is stated, but what a 'preview' actually computes and returns to the caller is left unexplained.

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

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

Schema coverage is 50%, and the description does contribute meaning beyond the schema by tying MAX_CONVERSIONS to App Store Search Results eligibility, which the schema's enums do not express. However it says nothing about the required campaignId/adAccountId scoping or the conditional bid/bidStrategyGoal pairing enforced by dependentRequired.

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 fragment names a specific verb ('Preview') and resource ('...strategy') and enumerates the two supported strategy types, but never says it applies to a campaign-level bid strategy; only the tool name supplies that scope. It also leaves 'preview' undefined, so an agent cannot distinguish it cleanly from ad_group_bid_preview, keyword_bid_preview, or campaign_update_preview.

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

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

There is no when-to-use statement and no named alternative. The only constraint offered is an implicit eligibility condition ('eligible App Store Search Results' for MAX_CONVERSIONS), which is a precondition rather than guidance on choosing this tool over siblings.

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

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

Annotations already declare this as read-only, idempotent, non-destructive, and open-world. The description adds that the tool previews country-targeting replacement, but it does not explain what the preview evaluates, what constraints apply, or what the agent should do with the result.

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 with no wasted text. However, its terseness leaves the action and effect of "replacing" somewhat ambiguous.

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?

An output schema exists and annotations provide the safety profile, reducing what the description must cover. Still, with four required parameters and only partial schema descriptions, the description lacks enough usage and parameter context to be 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 50%, and the description does not compensate by explaining the undescribed parameters. It only indirectly references the countries parameter through "country targeting" and gives no added detail for campaignId or countries format.

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, "Preview," and identifies the resource as campaign country targeting. It is clear enough to distinguish this tool from general campaign previews, but it does not explicitly differentiate itself from related campaign preview tools such as campaign_update_preview.

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

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

There is no explicit guidance on when to use this tool versus alternatives, nor any stated prerequisites or exclusions. The agent must infer that it should be used before changing campaign country targeting.

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, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description contributes one genuinely new behavioral fact — that a receipt is issued with a ten-minute lifetime — but leaves critical mechanics unexplained: whether the receipt must be redeemed, what it contains, and what happens after expiry.

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

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

A single front-loaded sentence with zero filler, and the action is stated first. It is terse to the point of leaving the workflow implicit, but nothing in it is wasted or buried.

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 deeply nested create-payload tool with conditionals, unstated invariants (adAccountId must match), and a multi-step preview/apply flow, one sentence is not sufficient. The output schema covers the return value, but the description never explains the receipt's purpose or the follow-up call, which is the highest-value missing 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 100%, and the input schema carries rich per-field guidance (APPSTORE-only supply source, APPSTORE_APP promoted type, bid strategy conditionals). The description adds no parameter meaning of its own, so the baseline 3 applies for a schema that does the heavy lifting.

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 ('Preview creation') and resource ('one campaign'), which clearly separates it from campaign_update_preview or campaign_delete_preview. It does not, however, explicitly name a sibling or state the scope constraints (dry-run only, nothing persisted).

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

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

No explicit when-to-use, when-not-to-use, or alternative is given. The 'ten-minute receipt' hint faintly implies a preview-then-apply workflow (operations_apply / operations_verify), but the agent must infer that entirely, and nothing warns that this call does not actually create the campaign.

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 destructiveHint=false, so the safety profile is clear. The description adds 'typed money' to indicate the amount parameter is a structured object, but provides no further behavioral context such as what 'preview' entails (e.g., validation vs. diff) or any prerequisites.

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

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

A single efficient sentence that front-loads the action and resource without any 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?

Given the presence of an output schema and rich annotations, the description covers the core purpose and the typed money aspect. However, for a preview tool with many siblings, it lacks clarity on what preview means operationally and how it relates to other budget-related preview tools, leaving a gap in contextual understanding.

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 50% schema description coverage, the description adds meaning only for the amount parameter by calling out 'typed money'. It does not compensate for the undocumented campaignId parameter or elaborate on profile/adAccountId beyond their schema snippets.

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

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

The description states a specific verb (Preview) and resource (campaign daily-budget update), and 'with typed money' signals the structured amount parameter. It does not explicitly distinguish itself from similar preview tools like campaign_update_preview, so it falls short of a 5.

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

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

No explicit when-to-use or when-not-to-use guidance is given. It does not clarify how this preview differs from campaign_update_preview or daily_budget_recommendation_apply_preview, leaving the agent to infer its role.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=true and idempotentHint=true, so the safety profile is covered. The description adds real value beyond that by specifying the blast radius ('cascade inventory') and a precondition ('paused campaign'), which an agent cannot derive from the hints alone.

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

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

A single dense sentence with zero filler; the irreversibility and cascade scope are front-loaded. It is efficient, though it stops short of the point where an agent knows the 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?

An output schema exists, so return values need not be described. However, for a destructive preview in a preview/apply pipeline, the description omits what the preview produces for later use, what happens on expectedText mismatch, and how to proceed to actual deletion — meaningful gaps for this class of tool.

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

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

Schema description coverage is 75%, so the schema mostly documents profile, adAccountId and expectedText. The description adds nothing about parameters — notably it never explains that expectedText is a guard against deleting the wrong resource, which is the key semantic for safe invocation. 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 (preview) and resource (deletion of a campaign) with scope: 'one paused campaign and its cascade inventory'. The resource name distinguishes it from the delete-preview siblings (ad_delete_preview, ad_group_delete_preview, keyword_delete_preview), though it never names those alternatives explicitly.

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

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

Usage is only implied by the word 'preview' — an agent can infer this is the dry-run step before a real campaign deletion. There is no statement of when to choose this over campaign_pause_preview, nor any mention of the follow-up apply step (operations_apply / operations_verify) that the sibling list strongly suggests.

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