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

Goes well beyond the readOnlyHint/idempotentHint annotations: it discloses asynchronous execution, the jobToken persistence requirement, that no polling loop is provided, that attribution windows are not comparable, and that no automatic sums or cross-platform attribution occur. It also reinforces the non-mutating nature with 'Does not change advertising or budgets'. This is exactly the extra context annotations cannot carry.

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

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

Four sentences, front-loaded with the verb and resource, followed by scope, constraints, and the follow-up call. Dense but every clause carries information; the sentence listing every report type is long but is doing necessary disambiguation work.

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, return values need not be explained, and the async lifecycle is fully covered (create here, retrieve via get_report). Minor gaps remain: no mention of the 30-day max range or the region-qualified accountId form, though both are handled in the schema descriptions.

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

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

Schema coverage is 100%, so the schema already documents every parameter, and the description correctly does not repeat it. It adds interpretive guidance on the one ambiguous choice — 'Choose the attribution window explicitly. Never compare different windows as equivalent' — which is semantics the enum alone does not convey.

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

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

Names a specific verb and resource ('Request an asynchronous Amazon performance report') and enumerates exactly which report families are covered (SP campaigns/ad groups/placements/search terms/products, SB campaigns/ads/search terms, SD campaigns/products). The async nature plus the jobToken handoff cleanly separates it from the get_* entity-listing siblings.

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

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

Explicit follow-up path is given ('keep jobToken and call amazon_ads_get_report later'), along with exclusions ('No polling loop', 'no cross-platform attribution', 'Brands legacy campaign reports exclude multi-ad-group campaigns') and the instruction to choose an attribution window explicitly. It lacks an explicit statement of when to prefer this over the many get_campaigns/get_targets siblings, but the performance-vs-configuration split is strongly implied.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety bar is covered. The description adds real behavioral context beyond that: default inclusion of archived entities, the requirement to keep paging until nextToken is absent, and the warning that a single page is not a total. It does not mention failure modes or auth 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?

Three short sentences, front-loaded with what the tool returns and immediately followed by the two operational facts that prevent misuse (pagination, archived default). No filler.

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

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

An output schema exists and the input schema is fully annotated, so return shapes need no explanation. The description covers scope, pagination, and entity type; the only gap is no mention of prerequisites such as resolving accountId via the profiles tool, though the schema hints at 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%, so every parameter is already documented in the schema. The description restates the archived default and the nextToken continuation loop, adding emphasis but no new semantics about filters or account scoping. Baseline 3 is appropriate.

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

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

States a specific verb and resource ('Read one page of Amazon Sponsored Products ad groups') and pins the platform to Sponsored Products, which distinguishes it from the sd_/sb_ ad group siblings. It also names the entity type precisely (configuration records, not metrics), so an agent knows exactly what it retrieves.

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

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

Gives useful usage context — default includes paused/archived, page through with nextToken, and a page is not an account total — but never names an alternative tool or when not to use this one (e.g., metrics vs configuration). Usage is implied rather than 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=true, idempotentHint=true, and destructiveHint=false, so safety is covered. The description adds real value beyond that by clarifying the returned ID must be authentic and used verbatim, and that results are bound to the selected profile – something annotations cannot 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?

Two sentences, front-loaded with what the tool returns, followed by the critical guardrail about the brandEntityId. Every clause earns its place.

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

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

With an output schema present, the description needn't explain return structure; annotations cover the safety profile and the sole parameter is fully documented. The one missing agent-facing detail – never fabricating an ID – is already addressed.

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 accountId fully documented including profile ID and region-qualified form. The description only echoes 'this selected profile,' adding no new parameter detail, 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 ('List brands') plus the qualifier 'eligible for Sponsored Brands,' and scopes results to 'this selected profile.' No sibling is named, but 'brands' is a distinct resource within the sibling set, so confusion is unlikely.

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

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

Gives explicit downstream usage: 'Use the returned brandEntityId in campaign and creative configuration; never invent a brand ID.' This tells the agent what to do with the output, though it doesn't state prerequisites or an explicit when-not-to-use condition.

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 read-only, idempotent, non-destructive behavior, so safety is covered. The description adds genuinely non-obvious traits: the default inclusion of paused and archived entities and the fact that a single response is a page, not an account total. Return shape is left to the output schema.

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

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

Three short sentences, zero filler, with the pagination caveat front-loaded alongside the resource statement. Every sentence carries distinct information (scope, pagination, category exclusion).

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 covering safety, full schema coverage, and an output schema handling return values, the description covers the remaining gaps: pagination is mandatory, defaults include archived states, and this is configuration data. Only the explicit routing to a reporting sibling is missing.

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

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

Schema coverage is 100%, so state defaults, nextToken semantics, maxResults cap, and campaignIds filtering are already fully documented in the schema. The description restates the archived-by-default behavior but adds no new syntactic or format detail beyond it, 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 and resource ('Read one page of Amazon Sponsored Products campaign negative keywords') with scoping detail (includes paused/archived). An agent can distinguish it from account-level get_negative_keywords and from get_campaign_negative_targets, though the sibling differentiation is implicit rather than stated.

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

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

Gives a clear when-to-use boundary ('configuration records, not performance metrics'), which steers the agent away from this tool for reporting queries, and instructs the nextToken continuation loop. It stops short of naming a specific alternative tool for performance data.

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, so the bar is lower, and the description adds real value beyond them: the default includes paused and archived entities, and a single response is a partial page, not a complete total. It does not discuss rate limits or permission/profile requirements, but those are largely covered by schema and annotations.

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

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

Three tight sentences, front-loaded with the scope, then the pagination rule, then the semantic caveat. No filler and no restatement of the title.

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 description covers the two things an agent could get wrong — treating one page as complete and assuming performance metrics. A pointer to the closest alternative tool would make it 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?

With 100% schema description coverage, the baseline is 3. The description restates the archived-inclusive default and the nextToken continuation pattern, both of which the schema already documents in detail, so it contributes little semantic meaning beyond the structured fields.

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

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

The description names a specific verb and resource ('Read ... Amazon Sponsored Products campaign negative targets') and distinguishes the record class from performance data. It does not explicitly contrast with the closest siblings (amazon_ads_get_negative_targets, amazon_ads_get_campaign_negative_keywords), leaving the campaign-level vs ad-group-level distinction to the tool name.

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

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

It gives concrete operational guidance: paginate with nextToken until absent, one page is not an account total, and these are configuration records rather than metrics — which usefully steers the agent toward report tools for performance questions. It lacks an explicit 'use X instead when Y' statement against sibling negative-target tools.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the burden is lighter. The description still adds real value beyond them: the default inclusion of paused and archived entities, and the pagination trap that a single page is not the full account result set.

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

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

Three short sentences, front-loaded with the resource and scope, then pagination semantics, then the metric-vs-configuration caveat. No sentence is 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?

Return values need not be explained since an output schema exists, and the description covers scope, pagination, and defaults. The only residual gap is not naming which sibling to use for performance metrics.

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 are already documented in structured fields, making 3 the baseline. The description reinforces the default state set and the nextToken continuation loop 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?

States a specific verb and resource ('Read one page of Amazon Sponsored Products campaigns') with scope qualifiers, and explicitly disambiguates from the report sibling by declaring these are configuration records, not performance metrics. An agent can distinguish it from amazon_ads_get_sb_campaigns / amazon_ads_get_sd_campaigns by the 'Sponsored Products' qualifier.

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

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

Gives concrete operational guidance: continue with nextToken until absent, and warns that one page is not an account total. It also implicitly routes metric-seeking callers away by noting these are configuration records, though it never names amazon_ads_get_report as the alternative.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description usefully adds that all versions and files are returned, that URLs are never guessed, and that there is no cross-profile fallback – good behavioral context beyond the annotations, though it says nothing about failure behavior when the asset is absent from the 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?

Three short sentences, front-loaded with what the tool does, and every clause carries information: return shape, no guessed URLs, no fallback, and where to get the ID. Nothing is redundant with the title or with what the schema already states.

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?

It covers the action, the scope (one profile, one asset), the source of the required ID, the return payload (every version and its files), and an important boundary (no cross-profile fallback). With an output schema present and full schema parameter documentation, nothing an agent needs in order to call this correctly is missing.

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

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

Schema coverage is 100% and both parameters are fully documented with patterns, so the schema does the heavy lifting. The description adds only mild value by stating the assetId is native and comes from amazon_ads_list_creative_assets, and that the profile is the 'selected' one – useful provenance but not format or constraint 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?

It names a specific resource (one native Amazon image or video asset) and scopes it to a single profile, and the second sentence clarifies that this is a retrieval returning every version and its files. The verb 'Refresh' is slightly ambiguous for a read-only tool and could momentarily suggest re-uploading or regenerating the asset, which the sibling amazon_ads_list_creative_assets does not.

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

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

It clearly routes the agent to amazon_ads_list_creative_assets as the source of the assetId, which is real usage guidance, and warns there is no cross-profile fallback so the profile must be the right one. It doesn't explicitly say when to call this versus just using the list response, but the single-asset lookup intent is clear.

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

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

Annotations already declare readOnly/idempotent/non-destructive and openWorld, so the safety profile is covered. The description adds real value beyond that: pagination completeness semantics and the default inclusion of archived entities, which an agent would otherwise misjudge as a full result set.

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

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

Three short sentences with zero filler, and the most decision-relevant facts (one page, pagination, config-vs-metrics) are front-loaded.

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

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

With a 100%-covered schema and an output schema present, the description only needed to cover pagination, default state inclusion, and the nature of the returned entities — all of which it does. Nothing an agent needs before calling is missing.

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

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

Schema coverage is 100% and every parameter carries its own description, so the schema does the heavy lifting. The description only reinforces the nextToken continuation contract; it adds no syntax or format detail beyond the schema, making the baseline 3 correct.

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), resource (Amazon Sponsored Products keywords), scope (one page), and default behavior (includes paused and archived). The 'Sponsored Products' qualifier distinguishes it from the sibling SB/SD keyword tools such as amazon_ads_get_sb_keywords.

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

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

Explicitly instructs to page with nextToken until absent and warns that one page is not an account total. The 'configuration records, not performance metrics' sentence implicitly routes performance needs to amazon_ads_get_report, but no exclusion or alternative is named outright.

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, so the safety profile is covered. The description adds real operational context: default inclusion of paused/archived states and the warning that a single page is not a complete account total, which prevents a common aggregation mistake. It does not mention throttling or result-size cost, so it stops short of 5.

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

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

Three tight sentences: scope first, pagination obligation second, data-type disambiguation last. Nothing is repeated verbatim from the schema and every sentence carries decision-relevant 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?

With an output schema present, return values needn't be explained, and pagination plus default state coverage are handled well. The remaining gap is scope disambiguation against the campaign-level negative keyword sibling, which the agent would have to infer.

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

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

Schema coverage is 100%, so the baseline is 3. The description still adds value by tying nextToken and page size together semantically ('one page is not an account total'), clarifying what maxResults actually bounds beyond the schema's 'Maximum entities in this page'.

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

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

Names a specific verb and resource ('Read one page of Amazon Sponsored Products negative keywords'), and the 'Sponsored Products' qualifier separates it from the SB/SD siblings (amazon_ads_get_sb_negative_keywords, amazon_ads_get_sd_negative_targets). It does not, however, clarify its relationship to amazon_ads_get_campaign_negative_keywords, so the level (campaign vs ad group) this returns is left 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?

Gives a concrete pagination procedure ('Continue with nextToken until absent; one page is not an account total'), which is the main usage trap for this tool. The closing exclusion 'configuration records, not performance metrics' steers agents away from using it for performance analysis, but no sibling is named explicitly as the alternative.

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

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

Annotations already establish that this is a read-only, idempotent, non-destructive, open-world read. The description adds useful behavior beyond annotations: paused and archived entities are included by default, results are paginated, and one page is not an account total. It also clarifies these are configuration records rather than performance metrics.

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

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

The description is three tightly focused sentences. It front-loads the resource scope, then covers pagination and data nature, with no redundant or filler 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?

With annotations, a full input schema, and an output schema, the description is nearly complete for correct invocation. The main remaining gap is that it does not explicitly distinguish this broad negative-targets endpoint from the campaign-specific negative-targets sibling.

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

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

Schema description coverage is 100%, so the schema already documents all five parameters, including states, nextToken, maxResults, and campaignIds. The description adds meaningful semantics for nextToken and pagination by saying to continue until the token is absent and that one page is not an account total.

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: 'Read one page of Amazon Sponsored Products negative targets.' This distinguishes it from SD/SB negative-target siblings and from performance-report tools, but it does not explicitly clarify how it differs from the sibling 'amazon_ads_get_campaign_negative_targets'.

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 a clear pagination usage rule: 'Continue with nextToken until absent; one page is not an account total.' It does not name alternatives or state exclusions relative to campaign-level negative-target or keyword tools, so it falls short of full when/when-not guidance.

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

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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds genuine context beyond them: paused and archived entities are returned by default, results are paged rather than account totals, and the payload is configuration data. Missing only things like profile/region auth requirements, which the schema notes cover.

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

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

Three short sentences with zero filler: what it reads, how to paginate, and what the records are not. The pagination warning is front-loaded next to the scope statement so an agent cannot miss it.

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 description covers the two things an agent could get wrong (treating one page as a total, and expecting metrics). It says nothing about how the optional campaignIds/states filters combine with nextToken, but the schema handles those.

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 every parameter (states, accountId, nextToken, maxResults, campaignIds) is documented inline, so the baseline of 3 applies. The description reinforces the nextToken continuation semantics but adds no syntax or format detail the schema does not already carry.

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 page of Amazon Sponsored Products product ads') and names the scope of entity state included. The phrase 'Sponsored Products' disambiguates it from the SB/SD siblings (get_sb_ads, get_sd_product_ads), and 'configuration records, not performance metrics' separates it from get_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?

Explicitly rules out the performance-metrics use case and instructs continuation with nextToken until absent, which tells the agent how to use it correctly. It stops short of naming the alternative tool (amazon_ads_get_report / create_report) by name, so the routing is implied rather than spelled out.

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

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

Annotations already declare readOnly/idempotent/openWorld/non-destructive, and the description adds real behavior context beyond them: it retrieves from the catalog without scraping retail pages, and warns that returned images 'are not complete rendered ads.' This caveat usefully sets expectations about output fidelity.

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

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

Three tight sentences, purpose front-loaded, followed by the scraping caveat and pagination mechanics. Each sentence earns its place; nothing is padded, though the phrasing is slightly terse.

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

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

With an output schema present and annotations covering the safety profile, the description only needs to convey what the tool reads and how it pages. It does both plus an image-fidelity caveat, leaving it complete enough to call correctly.

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

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

With 100% schema description coverage, the schema already documents every parameter including the cursorToken-replaces-pageIndex rule. The description's pagination sentence reinforces but adds little new 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?

Specific verb (Read) plus an enumerated resource set (titles, native image URLs, stock, price, eligibility from the catalog), which clearly scopes this to catalog metadata rather than ad entities. It does not explicitly contrast with siblings like amazon_ads_get_product_ads, but the 'from the catalog' framing implicitly separates the two.

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 'Page through pageIndex or Amazon's cursorToken' line gives pagination usage but there is no explicit when-to-use/when-not or named alternative tool. The 'use this or search, not both' guidance lives in the schema, not the description, so selection guidance here is only implied.

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

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

Annotations already declare readOnly, idempotent, non-destructive and openWorld, so the safety profile is covered. The description adds genuinely new context by warning that API access does not establish eligibility for Sponsored Brands, Display or DSP — a non-obvious scope caveat an agent could otherwise over-assume.

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

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

Two short sentences with zero waste: the return payload is front-loaded and the eligibility caveat follows. Nothing is repeated from the schema or annotations.

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

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

An output schema exists, so the description does not need to document return values, and it still names the key fields. The only small gap is error behavior for an unknown or region-mismatched profile ID, which is partially but not fully covered by the schema pattern.

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?

There is a single parameter and schema description coverage is 100%, with the schema itself explaining the ID format, the AMAZON_ADS_PROFILE_IDS source and the region-qualified form. The description adds no further meaning about accountId, so this sits at the baseline for fully documented schemas.

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 ("the selected Amazon Ads profile") and even enumerates the fields returned (marketplace, account type, currency, timezone). It implicitly contrasts with amazon_ads_list_profiles by taking a single selected profile, but never names that sibling, so differentiation is inferred rather than stated.

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

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

Usage is only implied: an agent can infer this is the call to make once it has a profile ID from amazon_ads_list_profiles. There is no explicit when-to-use, no prerequisite statement (e.g., that accountId must come from the configured profile list), and no named alternative.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the description adds real value by disclosing bounded download size, offset-based pagination with partial-result markers, and seven-day expiry semantics. It stops short of describing what a single check returns when the report is still incomplete, which is the main behavioral question for a poll tool.

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

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

Four short sentences, each earning its place: check semantics first, token constraint second, pagination/bound behavior third, expiry fallback last. No filler or repetition of schema detail.

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

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

With an output schema present and annotations covering safety, the remaining gaps an agent needs are expiry, bounded download, and offset pagination — all covered. Nothing required to invoke the tool correctly is missing.

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

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

Schema description coverage is 100% and every parameter (limit, offset, jobToken, accountId) is documented in the schema, including nextOffset guidance and region-qualified accountId form. The description's jobToken note largely restates the schema, so baseline 3 is appropriate.

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

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

States a specific verb and resource ('Check an Amazon report ... read its native rows') and positions itself relative to the sibling amazon_ads_create_report, which produces the jobToken. An agent can tell it is a fetch/poll tool rather than a report-creation tool without opening either schema.

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

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

Explicit that only jobTokens from amazon_ads_create_report for the same profile are valid, and that expired reports must be re-requested, which is a clear exclusion path. It does not spell out the polling cadence or that a not-yet-complete report should be re-checked rather than recreated, so context is clear but not exhaustive.

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 is read-only, idempotent, non-destructive, and open-world, so the description does not need to restate safety. It adds useful behavioral context beyond annotations: Brands eligibility is required, retail scraping is not used, and asset references need a follow-up resolution call.

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

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

The description is three tight sentences: purpose first, dependency resolution second, eligibility/scope third. Every sentence adds useful information with no repeated or filler 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?

With an output schema, full input-schema coverage, and rich annotations, the description supplies the remaining essentials: what creative data is returned, which dependency tools resolve references, and the Brands eligibility constraint. Nothing material for correct invocation is missing.

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

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

Schema description coverage is 100%, so the parameter semantics are primarily carried by the schema. The description only implies the ad-scoping meaning through 'for one ad' and does not add detail about accountId, pagination, or limits.

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: read Sponsored Brands creative versions for one ad, and enumerates the returned fields. It distinguishes this from SD creative tools by naming Sponsored Brands and from asset-listing tools by scoping to one ad and redirecting asset/ASIN resolution to dedicated siblings.

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

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

It gives clear usage context by naming the required Brands eligibility and explicitly routing asset ID resolution to amazon_ads_get_creative_asset and ASIN resolution to amazon_ads_get_product_metadata. It stops short of explicitly contrasting with amazon_ads_get_sd_creatives or amazon_ads_list_creative_assets, so it is not full when/when-not guidance.

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

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

Annotations already declare read-only, idempotent, non-destructive behavior, so the description's job is to add context — and it does: Brands eligibility gating, all-states default, and nextToken pagination. It does not describe page-size behavior or what the payload contains, but the output schema covers 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?

Four terse, front-loaded sentences with no filler; the scope and eligibility constraint lead. 'Configuration is not performance' is dense to the point of being slightly cryptic, costing a point.

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, a full output schema, and 100% parameter coverage, the remaining burden is orientation — prerequisite, pagination, default scope, and data-type framing are all present. Only a hint about entity/field content or typical page size 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 every parameter is already documented in the schema, including the states default and nextToken semantics. The description restates the all-states default and pagination guidance but adds no syntax or format detail beyond the schema — baseline 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?

States a specific verb+resource with scope ('Read one page of Sponsored Brands ad groups'), immediately separating it from the Sponsored Display and generic ad-group siblings. The 'one page' framing also signals a paginated list rather than a full dump.

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?

'Requires Brands eligibility in this profile' is an explicit precondition, and 'Configuration is not performance' steers agents away from expecting metrics (i.e., toward the report tools). No sibling tool is named as an alternative, which keeps it from a 5.

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

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

Annotations already declare read-only, idempotent, non-destructive behavior, so the description is not obligated to restate safety. It adds non-obvious context the annotations lack: the Brands-eligibility gate, the all-states-by-default scope (archived included), and the paging contract.

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

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

Four short sentences with no filler; the core action and scope lead, then eligibility, then paging, then the reporting disambiguation. Every sentence carries distinct 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?

With an output schema present, return values need not be described, and the description covers scope, eligibility, defaults, and pagination. The one residual gap is not pointing to the reporting sibling explicitly, but nothing needed to invoke the tool correctly is missing.

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

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

Schema description coverage is 100%, so every parameter including adIds, campaignIds, states, nextToken and maxResults is already documented in the schema. The description's "includes all states by default" and "follow nextToken" merely restate schema defaults; baseline 3 applies.

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

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

States a specific verb and resource ("Read one page of Sponsored Brands ads"), which cleanly separates it from sibling entity readers like amazon_ads_get_sb_campaigns and amazon_ads_get_sb_ad_groups. "Configuration is not performance" further rules out confusing it with amazon_ads_get_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?

Gives a real prerequisite ("Requires Brands eligibility in this profile") and pagination instruction ("follow nextToken"), plus an implicit redirect to reporting tools via "Configuration is not performance." It does not name the specific alternative to use for performance data, so routing is only implied rather than explicit.

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

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

Annotations already declare readOnly/idempotent/non-destructive/openWorld, so the bar is lower, yet the description adds real behavioral content: an eligibility prerequisite, single-page pagination with a nextToken follow-up contract, and the non-obvious fact that archived campaigns are included by default. It also clarifies the returned data is configuration-only, not performance data. No mention of rate limits or error behavior keeps it short of a 5.

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

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

Four short sentences, zero filler, with the most decision-relevant information (what it reads, eligibility, state defaults) front-loaded. Each sentence carries a distinct fact: scope, prerequisite, pagination/states, and data-type caveat.

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, return-value explanation is unnecessary, and the description covers scope, prerequisite, pagination, and default filtering. The only gap is that it does not explicitly tell the agent which sibling to use for Sponsored Products or Sponsored Display campaigns, leaving that inference to the naming convention.

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 explains accountId, states, nextToken, maxResults, and campaignIds in detail. The description only reinforces the default-includes-all-states behavior and the nextToken follow-up, adding little semantic detail beyond what the parameters already document. Baseline 3 is appropriate.

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

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

States a specific verb and resource ("Read one page of Sponsored Brands campaigns") and scopes it to a single page, which separates it from the paginated-agnostic campaign readers. The "Sponsored Brands" qualifier distinguishes it by resource family from the Sponsored Display and unqualified campaign siblings, though it never names those alternatives directly.

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

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

"Requires Brands eligibility in this profile" gives a concrete precondition an agent can check before calling, and "Configuration is not performance" steers the agent away from using this for metrics (the report tools are the implied alternative). It stops short of explicitly naming the report sibling or stating when not to call it, so it is clear context rather than a full routing rule.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds the meaningful behavioral fact that results are paginated and partial, plus archived inclusion. It says nothing about permission/profile requirements or result ordering, so it adds context but not rich 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?

Two short sentences with zero waste. The resource and scope come first, followed immediately by the pagination caveat.

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

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

For a read-only paginated list tool with full schema coverage and an output schema covering return values, the description supplies the essential facts: what is listed, archived inclusion, and that pagination must be continued. The only gap is differentiation from sibling keyword/target listing 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 all six parameters are already documented, including limit, startIndex, states, and the ID filters. The description only alludes to the cursor/offset (startIndex) concept and adds no syntax or constraint detail beyond the schema. Baseline 3 applies.

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

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

States a specific verb and resource ('List one page of Sponsored Brands keywords') and adds the useful scope detail that archived entities are included. It does not explicitly distinguish itself from the generic amazon_ads_get_keywords or amazon_ads_get_sb_negative_keywords siblings, so the SB-vs-generic boundary is left implicit.

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

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

The description gives pagination guidance ('follow the returned cursor or offset; one page is not the whole inventory'), which is real usage advice. It offers no when-to-use or when-not-to-use versus the many sibling list tools (e.g., amazon_ads_get_keywords, amazon_ads_get_sb_targets), leaving that choice 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 readOnly=true, idempotent=true, destructive=false, so safety is covered. The description adds a genuinely useful caveat that results are paginated and incomplete per call, but does not cover return shape or anything about archived-entity semantics beyond what the schema default 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?

Two tight sentences with the resource statement front-loaded and the pagination warning second; no filler. Slight redundancy with the schema's default of enabled+archived for the 'including archived entities' clause keeps it from 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 a full output schema and 100% parameter coverage, the description covers what it must: what list this is and that results are paged. The remaining gap is disambiguation from the large set of sibling negative-keyword/target tools, which it leaves implicit.

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 six parameters are fully documented in the schema (limit, states, accountId, adGroupIds, startIndex, campaignIds). The description adds nothing parameter-specific beyond the pagination hint, so baseline 3 is appropriate.

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

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

Specific verb (List) and resource (Sponsored Brands negative keywords) with scope ('one page', 'including archived entities'). The 'Sponsored Brands' qualifier implicitly distinguishes it from sibling get_negative_keywords and get_sd_negative_targets, though it never names them explicitly.

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

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

The description gives pagination guidance ('follow the returned cursor or offset; one page is not the whole inventory') which is useful operational context, but it gives no when-to-use/when-not guidance nor names any alternative among the many sibling list tools. Usage is only implied by the tool being a filtered lister.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so safety is covered. The description adds only the archived-inclusion note and pagination caveat; it says nothing about rate limits, result ordering, or what the page envelope looks like. 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?

Two short clauses, both front-loaded with the essential fact (what is listed) followed by the pagination warning. No filler, nothing repeated from the schema.

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

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

An output schema exists, so return-value explanation is unnecessary, and the pagination caveat plus archived note cover the key behavioral facts. The remaining gap is explicit routing among the many sibling listing tools, which the description leaves implicit.

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 six parameters already carry documentation and this is the baseline case. The mention of 'cursor or offset' loosely maps to nextToken, but the description adds no format or constraint 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 and resource ('List one page of Sponsored Brands negative targets'), and the 'Sponsored Brands' qualifier distinguishes it from amazon_ads_get_sd_negative_targets and amazon_ads_get_negative_targets. It does not explicitly name those siblings, so it falls short of the top mark.

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 tells the agent how to page ('Follow the returned cursor or offset; one page is not the whole inventory'), which is useful operational guidance. But it never states when to choose this over the SD negative targets or SB negative keywords tools, so the alternative-selection guidance is only implied by the entity name.

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

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

Annotations already declare readOnly, idempotent, non-destructive, and open-world. The description adds genuinely useful behavior not in annotations: archived entities are returned and a single response is only one page, so callers must continue paginating. It stops short of describing return shape, though an output schema exists.

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

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

Two short sentences, front-loaded with the resource and followed immediately by the pagination caveat. No filler.

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

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

Given a fully described 6-parameter schema and an output schema, the description covers the essentials plus the pagination pitfall. Missing only explicit routing guidance relative to the many sibling list 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 documents limit, states, accountId, nextToken, and the ID filters. The description only restates the continuation concept, adding little detail beyond the field descriptions. Baseline 3 is appropriate.

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

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

States a specific verb and resource ("List one page of Sponsored Brands targets") and adds an important scope note that archived entities are included. The 'sb' qualifier distinguishes it from amazon_ads_get_sd_targets and amazon_ads_get_targets, though no sibling is explicitly named.

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

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

Usage is implied by the resource, and the description does give operational guidance ("Follow the returned cursor or offset"). It never states when to prefer this over amazon_ads_get_targets or the SD equivalents, which is the main ambiguity an agent faces.

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?

This description provides rich behavioral context not found in annotations or schema, specifically how pagination works ('startIndex, not a cursor') and a critical data nuance ('these records are not performance metrics').

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 highly concise, delivering four distinct but interrelated pieces of critical operational information in an efficient, front-loaded manner.

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?

It is highly complete for a list-reading operation. By detailing the pagination method and the nature of the returned data (non-performance metrics), it preemptively answers common agent questions.

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?

Since the input schema provides 100% coverage of the parameters, the baseline score of 3 is appropriate. The description does not add specific semantic meaning to any individual parameters.

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

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

The description clearly states the action ('Read') and the specific resource ('Sponsored Display ad groups'), which helps distinguish this tool from other general 'get ad groups' siblings.

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 provides a clear usage constraint by stating the required condition: 'Requires Display eligibility.' This helps the agent determine if the tool is applicable before execution.

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

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

Annotations already declare readOnly/idempotent/openWorld, but the description goes well beyond them: it discloses a non-obvious quirk (full pages are conservatively marked partial) that would otherwise confuse a downstream agent, and it explicitly warns that creative-native media references are not performance metrics, preventing misuse. These are exactly the behavioral details structured fields cannot carry.

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

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

Four short sentences, front-loaded with the resource and eligibility gate before pagination and caveat details; nothing is padded. The creatives caveat is slightly tangential to a campaigns endpoint, keeping it just short of ideal tightness.

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, return shape need not be described. The description covers the eligibility precondition, the pagination model, and the partial-page caveat, which is everything an agent needs to call this correctly and interpret results.

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

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

Schema coverage is 100%, so accountId, count, and startIndex are already fully documented in the schema, including the 'use nextStartIndex' hint. The description's note that pagination uses startIndex rather than a cursor adds only a small amount of framing beyond that, 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 description names a specific verb and resource ('Read one page of Sponsored Display campaigns'), which immediately separates it from the Sponsored Brands variants (get_sb_campaigns) and the generic get_campaigns sibling. An agent can pick the right tool from the ad-product qualifier alone.

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

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

It gives one real prerequisite ('Requires Display eligibility'), which helps the agent decide whether the call will succeed. But there is no explicit when-to-use/when-not guidance and no reference to alternative tools such as amazon_ads_get_report for performance data, leaving selection partly implied by the resource name.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description adds genuinely non-obvious behavior: pagination is offset-based rather than cursor-based, full pages are conservatively flagged partial (so the agent must not treat 'partial' as truncation), and the returned records carry native media references rather than metrics.

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

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

Four short sentences, front-loaded with purpose, then prerequisites, then paging behavior, then a scope caveat about the payload. Nothing is redundant with the schema.

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

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

With an output schema present and rich annotations, the description only needs to cover eligibility, paging, and payload scope — and it does all three, including the misleading-'partial'-flag quirk an agent would otherwise misread.

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 parameter baseline is 3, but the description still adds value by stating that paging is via startIndex rather than a cursor, disambiguating how count/startIndex combine. It does not add anything beyond the schema for accountId or adGroupIds.

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'), resource ('Sponsored Display creatives'), and scope ('one page'), which cleanly separates it from the many other Amazon Ads readers in the sibling set. Within the SD family, creatives vs ad groups/campaigns/targets 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?

Gives a real precondition — 'Requires Display eligibility' — which tells the agent when the call will apply. It does not, however, route the agent away from near-neighbors such as amazon_ads_get_sd_product_ads or amazon_ads_get_sb_ad_creatives, leaving the creative-vs-ad distinction to be inferred from the name.

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

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

Annotations already establish read-only, idempotent, non-destructive behavior, so the description's added value is in the operational details: eligibility gating, offset-based rather than cursor pagination, and the non-obvious trait that full pages are conservatively flagged as partial. It also warns that these records carry no performance metrics, which prevents a common misinterpretation. Return shape and failure modes are left to the output schema.

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

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

Four tight sentences with the operation and eligibility constraint front-loaded, followed by pagination and scope caveats. The 'creatives include native media references' sentence is the weakest link for a negative-targets resource but still contributes disambiguation rather than 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?

An output schema exists, so return values need no prose. Given that, the description covers the remaining agent-relevant gaps: eligibility precondition, pagination mechanics and its partial-page quirk, and the fact that these are targeting records rather than metrics. Nothing essential for correct invocation is missing.

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

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

Schema description coverage is 100%, so the schema already defines count, accountId, and startIndex, making 3 the baseline. The description earns a bump by clarifying that pagination is startIndex-based and not cursor-based and by explaining the partial-page marking behavior, which is semantics the schema alone does not convey.

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

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

The opening sentence pairs a specific verb ('Read one page of') with a precisely qualified resource ('Sponsored Display negative targets'), which separates it from amazon_ads_get_sd_targets (positive) and amazon_ads_get_sb_negative_targets (Sponsored Brands). It stops short of explicitly naming those siblings, so differentiation is achieved through the resource qualifier rather than direct routing language.

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?

'Requires Display eligibility' is a genuine precondition that tells the agent when the call can succeed. However, there is no explicit statement of when to prefer this over positive-target or SB negative-target siblings, and no exclusions or error guidance; usage is only implied by the resource name.

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

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

Annotations already cover readOnly/idempotent/non-destructive, and the description adds real behavioral context beyond them: offset pagination instead of a cursor, and the non-obvious fact that full pages may be conservatively flagged partial. It also warns the returned creatives carry media references rather than metrics.

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

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

Four short sentences, each carrying a distinct fact (scope, eligibility, pagination model, record type) with the core scope front-loaded. No filler or restatement of the name.

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

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

With an output schema and full annotation coverage, the description covers what an agent needs to call it correctly and interpret the page flags. A note on looping through pages or page-completeness expectations would make it 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%, so the baseline is 3; the description earns above it by calling out that paging uses startIndex rather than a cursor, a constraint the schema does not state. It does not add new meaning to count or accountId beyond what the schema already documents.

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

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

States a specific verb and resource ('Read one page of Sponsored Display product ads') with page-scoped semantics, which separates it from report and creative siblings. It does not name a sibling by name, but the 'SD product ads' qualifier is specific enough to route an agent.

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

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

Gives a concrete prerequisite ('Requires Display eligibility') and implicitly excludes the metrics/reporting use case with 'these records are not performance metrics', which steers toward the report tool. It stops short of naming an explicit alternative for performance data.

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, so the safety profile is covered. The description adds real behavioral value beyond that: offset-based paging, the counterintuitive rule that full pages are 'conservatively marked partial', and a caveat that returned creative records are not performance metrics.

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

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

Three short sentences, front-loaded with the core verb+resource and the eligibility gate before the paging and content caveats. No filler, though the final clause about native media references is somewhat loosely connected to the tool's primary purpose.

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

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

An output schema exists, so return values need no explanation; the description instead covers the things structure cannot: eligibility, pagination mechanics, the partial-page flag, and the nature of the records. An agent has enough to call it correctly and interpret the response.

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 are already documented, including nextStartIndex chaining. The description's paging note largely restates the schema's startIndex guidance, so the required baseline of 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?

Opens with a specific verb+resource ('Read one page of Sponsored Display targets'), which cleanly separates it from siblings like amazon_ads_get_sd_campaigns and amazon_ads_get_sd_product_ads. It does not explicitly distinguish itself from amazon_ads_get_sd_negative_targets, leaving that inference to the agent.

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

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

States a hard prerequisite ('Requires Display eligibility') and explains the pagination model ('startIndex, not a cursor'), both of which tell the agent when and how to call it. It stops short of naming alternatives or exclusions, so it is clear context without full routing guidance.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds genuinely non-obvious behavior: archived entities are included by default and a single response is not the account total. Permissions/auth requirements are left to the schema.

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

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

Three short sentences, zero filler, with the core scope front-loaded and the pagination caveat immediately after. Each sentence carries distinct, useful 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, so return values needn't be explained. The description covers scope, default state inclusion, and pagination well; the only minor gap is no explicit pointer to the metrics tool or mention of rate/volume expectations for a large account.

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 are well documented in the schema itself, setting the baseline at 3. The description reinforces pagination semantics but adds no syntax or format detail beyond what the schema already provides for states, nextToken, or campaignIds.

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 page of Amazon Sponsored Products targets') and names the scope precisely, distinguishing it from the sibling sd_targets/sb_targets tools by platform. The default state inclusion is baked into the purpose statement, so an agent knows exactly what set it gets.

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

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

Gives clear pagination guidance ('Continue with nextToken until absent; one page is not an account total') and implicitly redirects metric-seeking agents by noting these are 'configuration records, not performance metrics.' It stops short of explicitly naming amazon_ads_get_report or amazon_ads_create_report as the alternative for performance data.

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 the description adds real behavior beyond them: single-page pagination with token continuation and a caveat that uploaded assets are not proof of campaign use or delivery. Reduces the risk of an agent treating library presence as delivery evidence; only return-shape detail is left to the output schema.

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

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

Four short sentences, front-loaded with purpose, then pagination, then the caveat and alternative. Dense and mostly waste-free, though the compressed telegraphic phrasing ('native download or playback URLs, sizes and moderation metadata') reads as a list fragment rather than a sentence.

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

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

For a read-only, paginated list tool with a full input schema, output schema, and annotations, the description covers the essentials: scope, pagination protocol, and the misleading-inference caveat. Minor gaps remain, such as whether unfiltered search spans all asset types or whether moderation status can be filtered.

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 (text, limit, accountId, assetType, nextToken) is already documented with constraints and enum values. The description only reinforces that nextToken must reuse 'the same filters'; it adds no search-syntax or matching semantics 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 and resource ('Search the Amazon creative asset library') and enumerates what is returned: images, logos, videos, download/playback URLs, sizes, moderation metadata. It also routes an adjacent case away ('Sponsored Products images come from amazon_ads_get_product_metadata instead'), so the agent can separate it from siblings without opening schemas.

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

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

Gives clear operating instructions: one page, continue with nextToken using the same filters, and an explicit alternative for Sponsored Products images. It does not, however, contrast itself with the sibling amazon_ads_get_creative_asset (single-asset fetch) or explain when searching by text vs assetType is preferred.

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 the description adds genuinely new behavioral facts: the allowlist filtering guarantee, that out-of-allowlist profiles are neither returned nor counted, and that configured-but-absent IDs surface in missingProfileIds. That last detail is important because it tells the agent how to distinguish 'not permitted' from 'not found'.

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

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

Three tight sentences with the scope and filtering rule front-loaded, then the returned fields, then the missingProfileIds edge case. No filler and no restatement of the tool name.

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

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

An output schema exists, so return shape need not be fully spelled out, yet the description still names the key returned attributes and the missingProfileIds field. Combined with annotations covering the safety profile, an agent has everything needed to call it correctly.

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

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

The tool takes zero parameters, so the baseline is 4. The description still adds meaning by naming the two ambient configuration inputs (AMAZON_ADS_PROFILE_IDS and AMAZON_ADS_REGION) that determine the result set, which the empty object schema cannot convey.

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

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

States a specific verb (list) and resource (advertising profiles) plus the scoping axes (AMAZON_ADS_PROFILE_IDS allowlist, AMAZON_ADS_REGION). It is clearly the collection-level counterpart to the singular amazon_ads_get_profile sibling, so an agent can route between them without opening the schema.

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

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

Gives clear context for the tool's role: it returns only allowlisted profiles in the configured region, and profiles outside the allowlist are never returned or counted. It stops short of explicitly naming amazon_ads_get_profile as the alternative for fetching a single profile, so there is a small inference gap.

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