Agent Central

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description still adds genuine value beyond annotations: it discloses the data source ('stored reports, not live entity state') and explicitly caps interpretive claims ('observed changes, not proof of causation'), which prevents misuse as a causal or real-time check.

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 trigger condition is front-loaded, followed by scope, defaults, and caveats in four compact sentences. It is well organized with no filler, though the data-source and causation sentences could be tightened slightly.

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. Given 10 parameters and the multi-dimension comparison complexity, the description covers trigger, scope, defaults, and data limitations adequately; freshness/diagnostics behavior lives in the schema descriptions rather than the prose.

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 documented in the schema, including ad_product defaults and focus_metric sorting semantics. The description only restates the default ad product and dimension support, adding little syntax or interpretation beyond the structured fields. 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 states a specific verb and resource ('compare Amazon sponsored advertising performance between two periods') and defines the scope of returned changes (campaign, ad, search-term, targeting, advertised-product dimensions). It does not name any sibling tool explicitly, but the cross-period comparison framing distinguishes it from single-period siblings like get_campaign_performance.

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?

'Use when the user asks to compare ... between two periods' gives a clear triggering condition. However, it offers no exclusions or pointers to alternatives (e.g., when to prefer get_campaign_performance or get_sp_campaign_performance), leaving the agent to infer boundaries.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so safety is partly covered. The description still adds meaningful context beyond them: it states an access prerequisite ('Requires Ads or Inventory access'), signals the data is stored rather than live ('Returns stored ...'), and discloses that freshness and coverage summaries are included 'where available', implying partial data. The 'does not prepare write actions' line is largely redundant with readOnlyHint.

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

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

Three sentences, front-loaded with the usage trigger, then return scope, then access and safety. It is efficient with no filler, though the middle sentence is a fairly dense enumeration of returned domains rather than a structured summary.

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

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

An output schema exists, so return values need not be described, and the schema fully documents the four optional parameters with defaults. The description covers purpose, triggering condition, access requirement, and read-only nature. What is missing is drill-down routing guidance against the large sibling set, which for a broad overview tool would materially help an agent decide when to stop here.

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

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

Schema description coverage is 100% and all four parameters (detail_level, evidence_limit, spotlight_count, date_window_days) carry their own defaults, ranges, and explanations in the schema. The description adds no parameter-level meaning, so the 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?

The description names a specific verb and resource ('overview of their connected Amazon seller account') and enumerates the data domains returned (sales, advertising, inventory, top-selling products, comparisons, freshness, coverage). It is clearly distinguishable from the many single-domain siblings by being a cross-domain aggregate. It stops short of explicitly naming a sibling it is not, which keeps it at 4 rather than 5.

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

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

'Use when the user requests an overview of their connected Amazon seller account' gives a clear triggering context. There is no explicit exclusion or routing advice (e.g. 'for a single domain, use get_sales_summary or get_campaign_performance instead'), which is a real gap given ~90 highly specific sibling tools, but the when-to-use condition itself is unambiguous.

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

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

Annotations already declare readOnlyHint=false for destruction and openWorldHint=false, so the safety profile is covered; the description adds real value by describing the response payload (permissions, tool_scope_by_domain, coverage dates) and the data_map caveat. It says nothing about what limit/offset do behaviorally, how large the response can get, or whether capability data can lag actual enforcement, so it stays short of rich disclosure.

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

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

The description is front-loaded with the trigger sentence, then a dense return-value list, then a single scoping caveat; every sentence carries information. The middle enumeration is long but each item is a distinct return field 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?

There is no output schema, so the description's explicit enumeration of returned fields is genuinely necessary and well done. The gap is the six undocumented input parameters; an agent can call the tool with defaults, but it cannot correctly use the filtering and pagination options without guessing.

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

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

Schema description coverage is 0% across 7 parameters, so the description must carry the load and it largely does not: only 'view' is named, with the data_map value explained. domain, limit, offset, tool_names, entity_type, and metric_family are never mentioned, leaving an agent unable to infer how to filter or page through the tool's output.

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 resource (account/connection metadata) and enumerates exactly what it returns: key display name and safe prefix, marketplace scope, connection status, source coverage dates, historical access limit, and effective tool access. That clearly separates it from the many performance-oriented siblings like get_sales_summary or diagnose_performance, though it never names an alternative explicitly and the action verb is only implicit ('Returns').

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

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

It opens with an explicit 'Use when the user asks about the current connection, marketplace, account access, available date ranges, or enabled tools,' which gives a clear trigger context. It also warns that view=data_map returns source and tool mappings rather than business performance data, an effective when-not signal, but it does not route the agent to a named sibling for actual 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 cover the read-only, non-destructive, closed-world profile, and the description adds real context beyond them: a required permission scope (agent_actions:read), the fact that results span all API keys in the tenant rather than just the caller's, and newest-first ordering. It stops short of describing volume limits or truncation behavior, but the output schema covers pagination.

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

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

Three sentences, front-loaded with what the tool returns and what it is reliable for, followed by the sibling comparison and the auth caveat. No sentence is filler and the most decision-relevant facts come first.

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 10-parameter read tool with full schema coverage and an output schema, the description supplies the missing decision-critical context: permission requirement, tenant-wide result scope, and the reason to prefer it over the Amazon-native alternative. Nothing needed to call it correctly is absent.

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

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

Schema description coverage is 100%, so every parameter including asin, target, tool_used and the date bounds is already documented with format and defaults. The description reinforces date scoping and the write categories the filters operate over, but adds no syntax or semantics the schema does not already provide; 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: returns the tenant-wide audit log of changes agentcentral made, enumerating the write categories (bids, budgets, keywords, negatives, targets, states, listings). It explicitly distinguishes itself from the closest sibling, get_ads_change_history, by noting that Amazon's history excludes API/agentcentral writes.

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 use case (reconstructing what changed around a performance shift) and names the alternative tool while explaining why it is insufficient for this purpose. An agent can decide between this and get_ads_change_history without opening either schema.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds value by disclosing the response shape — overall status plus per-ASIN/SKU warnings and ineligibility reasons — but says nothing about rate limits, batching constraints, or what happens when an ASIN is unknown.

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

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

Two sentences with no waste; scope and defaults are front-loaded and the return description follows. Nothing is repeated and every clause carries 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, the description needn't explain return values, and it nonetheless summarizes them. For a read-only eligibility check with fully documented parameters, the only gap is practical context such as the 50-ASIN cap or batch expectations, which the schema already covers.

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. The description restates the ad_types default (SP, SB, SD) but adds no format, ordering, or ASIN-limit guidance beyond what the schema already provides. 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: 'Check product eligibility for selected ad types', and names the concrete defaults (Sponsored Products, Brands, Display) plus optional DSP. That distinguishes it from get_fba_eligibility and get_listing_restrictions, but it never names a sibling explicitly.

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

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

Usage is implied by 'check eligibility for selected ad types' and the default-scope sentence tells the agent what happens when ad_types is omitted. There is no statement of when NOT to use it, no prerequisites (profile access, campaign context), and no routing to alternative 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 a safe read (readOnlyHint true, destructiveHint false, openWorldHint false), yet the description goes materially further: enumeration gaps mean unknown, not absence; null is not zero; and daily captures cannot reveal actors, causes, intraday edits/reversals, or pre-collection states. These are substantive interpretation constraints an agent would otherwise get wrong, and they do not contradict the annotations.

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

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

Front-loaded with what the tool returns, then view semantics, then caveats. The sentences are dense but each carries distinct information; the compressed phrasing ('Missing or incomplete enumeration is unknown, not absence') is terse enough to read as clipped rather than wasteful.

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

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

For a 13-parameter, read-only history tool with an output schema and full annotation coverage, the description covers the interpretive risks (unknown vs absence, null vs zero, actor/cause limits) that the schema cannot. Remaining gaps are minor: the 90-day range cap and pagination discipline live in the schema, so their absence here is acceptable.

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 coverage the baseline is 3, but the description adds genuinely new semantics: net_changes compares 'the exact start/end dates, including unchanged entities', which the schema only partially conveys via 'not every edit'. It does not add anything for limit/offset/entity_ids beyond what the schema 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?

The description uses a specific verb and enumerates the exact resources returned: daily SP/SB keyword or product-target bid, source currency, and state observations, plus scope detail ('including paused/zero-delivery entities'). It is clearly distinguishable from performance tools by naming the observed fields, though it never names the near-siblings (get_ads_change_history, get_action_history) it could be confused with.

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

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

It differentiates the two views precisely ('history returns captures; net_changes compares the exact start/end dates, including unchanged entities'), which guides parameter choice. It gives no guidance on when an agent should pick this tool rather than get_ads_change_history or get_keyword_performance, so tool-level selection is left inferred.

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

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

Annotations only cover read-only safety; the description adds substantial unstated behavior: recent ~3 days may be incomplete, and a precise definition of refresh_window_open including the caveat that false is not a guarantee of finality and that missing evidence yields null. These are exactly the misinterpretation traps an agent would otherwise fall into.

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

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

Front-loaded with purpose, grain, and exclusions before the freshness nuance, which is the right order. The closing block spends four sentences explaining a single output field (refresh_window_open/settling_from_date), which is justified by its non-obvious semantics but is denser than the rest of the description.

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

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

An output schema exists so return values need not be described, yet the description still covers the freshness semantics an agent must have to interpret results correctly. For an 11-parameter reporting tool with sibling overlap, nothing needed for correct invocation or interpretation 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 limit/offset/sort/filters are already fully documented; the description adds no parameter-level meaning beyond mentioning the date-range grain. Baseline 3 applies when the schema does the heavy lifting.

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

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

States a specific verb and resource ('drill Sponsored Products performance from campaign to ad group') and names the exact metrics returned plus the row grain. This separates it cleanly from get_campaign_performance (coarser grain) and the keyword/search-term 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 routing: 'Do not use for bidded keyword/target or customer search-term analysis; use get_keyword_performance or get_search_terms.' The positive case ('Use to drill ... from campaign to ad group') is clear. It does not explicitly name get_campaign_performance as the coarser alternative, which is the most likely confusion given the shared metric set.

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

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

Annotations already cover safety (readOnlyHint=true, destructiveHint=false, openWorldHint=false), and the description goes well beyond them by disclosing the data-source gap (API-made changes and all agentcentral changes are absent), the 90-day window, the missing actor attribution, and the omission of Sponsored Display. Those are precisely the behavioral limits that would otherwise cause an agent to misread an empty result as 'no changes occurred'.

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 purpose and scope come first, then the critical exclusion, then the two alternative tools in a single sentence. Every clause carries load-bearing information and there is no filler or 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?

The tool has 15 optional parameters, a full output schema, and read-only annotations, so return shape, pagination, and safety are already covered elsewhere. The description supplies the only thing structured fields cannot: that results are sourced from Amazon's console, are typically empty, omit actor identity, and exclude Sponsored Display.

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 one of the 15 parameters carries its own documentation, including enum values and defaults, so the schema does the heavy lifting and a baseline 3 applies. The description adds only an implicit reconciliation of the date bound ('last 90 days') against start_date/end_date defaults, without discussing filtering or sort behavior beyond what the schema states.

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

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

States a specific verb and resource ('Returns Amazon's console change-history events for Sponsored Products and Sponsored Brands') and bounds the scope to the Seller Central History tab over the last 90 days. It also names the exact cases where it is the wrong tool, so an agent can distinguish it from get_action_history and get_campaign_snapshots without opening any schema.

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

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

Explicit routing: use get_action_history for agentcentral-made changes, and get_campaign_snapshots with view=changes for any Sponsored Products campaign-setting change regardless of source. It also flags that the tool is 'typically empty for agent-managed accounts', which is exactly the when-not-to-use signal an agent needs before spending a call.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the description is not obligated to cover safety. It adds genuine context beyond them: the Brand Registry authorization requirement, the word 'authoritative' signalling that relations output is a source of truth rather than a derived estimate, and that coverage rows are 'factual assigned or missing' rather than predictive. Pagination and freshness behavior are pushed to schema fields.

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

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

The three core sentences are front-loaded with the general purpose before the view breakdown, and each maps to one enum value, so a reader can scan quickly. Some content duplicates the view enum description verbatim, which is mild redundancy, but overall the text is dense and earns its length.

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 9 parameters, full schema coverage, an output schema, and populated annotations, the description only needs to establish purpose, view semantics, and access requirements, all of which it does. The one residual gap is that it does not hint at the diagnostics/freshness options, though those are documented in the schema and arguably out of scope for a routing description.

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

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

Schema description coverage is 100%, so the parameters are fully documented in structured form and a baseline of 3 applies. The description shadows the schema by restating the three view values and the content_reference_key dependency rather than adding syntax or edge-case behavior beyond it. The nuanced options (brand_match, coverage_state, include_raw_rows) are left entirely to their schema descriptions.

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 names a specific verb ('Inspect') and resource domain ('A+ Content and Brand Story coverage'), and the three sentences that follow decompose each view into the distinct output it produces. No sibling tool in the list addresses A+ content, and the description makes its scope self-evident 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?

The description specifies which view to pick and what each returns: 'documents' for metadata, 'relations' for assignments to one key, 'coverage' for comparison against a brand's active ASINs. It also states a hard prerequisite ('Requires Brand Registry') and implies the dependency chain that documents must be queried before relations/coverage. It stops short of explicit when-not guidance, but there is no competing sibling that would need to be disambiguated.

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

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

Annotations already establish readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so safety and scope are covered structurally. The description adds useful behavioral context that annotations cannot: product fields are populated only for report_type=PRODUCTS while PERFORMANCE rows may leave them null, which materially affects interpretation of results.

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

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

The first sentence front-loads the datasource, report dimensions, and metrics; the second explains a key field-population nuance; the third provides exclusions and alternatives. Dense but efficient, with no filler.

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

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

Given 17 mostly optional parameters, an output schema, and annotations covering safety, the description supplies the missing decision context: attribution-only scope, report_type-dependent field population, and sibling alternatives. Nothing essential for correct invocation appears omitted.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds non-obvious cross-parameter semantics: product_asin, product_name, brand_name, and marketplace are only populated for report_type=PRODUCTS. That relationship is not fully conveyed by the schema descriptions alone and helps the agent pick report_type correctly.

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

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

States a specific verb/resource scope: Amazon Attribution tagged off-Amazon traffic, with the dimensions and metrics it covers (publisher, campaign/ad group/creative, product, purchases, sales, brand halo, NTB). It is clearly distinguishable from sibling performance tools because it names the attribution datasource rather than on-Amazon ad performance.

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

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

Explicitly names when not to use it (on-Amazon ads, search terms, total seller sales) and routes the agent to campaign/search/sales tools instead. This is exactly the when/when-not/alternative structure that prevents mis-selection among the many sibling performance 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 cover read-only and open-world safety, so the bar is lower, and the description adds real value: it discloses that the live endpoint returns taxonomy in category, that type is often AUDIENCE, and that Amazon may omit name, provider, status, and description. That warning about sparse fields prepares an agent for partial results in a way the annotations cannot.

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

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

Two sentences with no filler, but they are dense and the second sentence packs several loosely related facts (taxonomy field, likely type value, omitted fields) without clear ordering. It is efficient but not maximally scannable.

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 fully described parameters, the definition is nearly sufficient, and the sparse-field warning fills the main gap. However, it says nothing about pagination behavior via next_token or how max_results interacts with the response size, which matters for an 8-parameter listing tool.

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

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

Schema description coverage is 100%, so every parameter including query, category_path_contains, segment_types, and include_diagnostics is already documented in detail. The description only gestures at "optional text and category-path search" without adding syntax or formatting detail beyond the schema, so the baseline 3 applies.

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

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

"Discover available Amazon Ads audience IDs for a profile" gives a concrete verb plus resource, and naming the targetableEntities/list source tells an agent exactly what data backs the result. It does not explicitly contrast itself with nearby targeting tools such as get_sp_targeting_options, but the resource is specific enough to identify.

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 mention of "optional text and category-path search" implies how to narrow results, but there is no explicit when-to-use/when-not-to-use guidance and no statement about alternatives among the many sibling get_* tools. Usage must largely be inferred from 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 establish a safe read-only, closed-world profile, and the description adds substantial context on top: live view reads one bounded Amazon SKU-ordered page, never writes or refreshes stored data, and leaves missing detail as null. The remaining gap is that it doesn't state what the snapshot view does when data is stale or empty beyond the schema's snapshot_date note.

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 scope statement and alternative routing are front-loaded in the first two sentences, with mode-specific caveats following. It is dense but nearly every sentence carries operational information; minor density in the live-page paragraph costs it nothing significant.

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 10-parameter tool this is complete: the two views and their divergent pagination/filtering rules are explained, output schema covers return shape, and annotations cover safety. An agent has everything needed to pick the correct view and avoid an invalid parameter combination.

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

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

Schema coverage is 100%, so baseline would be 3, but the description earns credit by explaining cross-parameter behavior the schema cannot: live pages require next_token rather than offset, sku filtering, or snapshot_date. It also characterizes what the live page returns (available, reserved, outbound-to-FBA quantities).

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 resource and a specific data shape: a raw AWD inventory snapshot with on-hand and inbound quantities per SKU. It explicitly separates itself from sibling tools, stating AWD snapshots do not expose FNSKU and directing the agent to get_fba_inventory or get_listing_registry for FBA/ASIN-level identity.

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 explicit use and do-not-use conditions with named alternatives, and further clarifies that this data is already included in get_days_of_cover, which prevents redundant calls. The live-view paragraph adds a second layer of guidance by ruling out offset, SKU filtering, and snapshot_date in that mode.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=false and destructiveHint=false, so the safety profile is covered. The description adds real behavioral context beyond that: results default to the latest snapshot, which matters when the agent reasons about data recency. It doesn't discuss pagination or result capping, but those live in the schema and 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 clauses, front-loaded with what is returned, then why it matters, then the default. No filler and no restating of the name or 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?

With annotations, a fully described 8-parameter schema and an output schema, the description only needs to cover purpose, use case and defaults — which it does. The one gap is not explicitly contrasting itself with get_awd_shipments for an agent choosing between shipment-level and SKU-level views.

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 limit, offset, sort_order and include_diagnostics is already documented in the schema. The description only echoes the snapshot default, adding no syntax or filtering semantics beyond what the schema provides — 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 and resource ('Get per-SKU line items from AWD shipments') and pins down the returned fields (SKU, quantity per shipment), which distinguishes it from the shipment-level get_awd_shipments and the aggregate get_awd_inventory.

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 use case — prorating AWD/AGL freight charges down to specific ASINs — which tells the agent when this grain of data is the right one. It stops short of explicitly naming sibling tools to prefer or exclude, so it's clear context rather than 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=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered. Beyond that the description adds no behavioral context of its own — nothing about pagination behavior, the 366-day range cap, or result-size capping, all of which live only in the parameter 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?

Two sentences with zero filler: the capability statement comes first, the sibling routing second. Nothing repeats the schema or the 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 return values need not be explained, and the schema fully documents all nine parameters. The description supplies purpose plus sibling routing, which is nearly sufficient; only the lack of any behavioral note on pagination or date-range scoping keeps it short of complete.

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

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

Schema description coverage is 100%, so every one of the nine parameters is already documented in the schema, including limit/offset ranges, sort enums, and date patterns. The description mentions no parameter semantics at all, so the baseline 3 for full schema coverage applies.

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

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

States a specific verb and resource ("Get AWD shipment-level data") and enumerates the returned fields (shipment IDs, statuses, timestamps). It also explicitly distinguishes itself from the closest sibling, get_awd_shipment_items, so an agent can tell the two apart without opening either schema.

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

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

Gives an explicit routing rule: for per-SKU quantities inside a shipment, use get_awd_shipment_items instead. That covers the main fork. It does not address the other adjacent siblings (get_inbound_shipments for FBA inbound, get_awd_inventory for stock levels), leaving the AWD-vs-FBA boundary to inference 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 declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered; the description adds value by disclosing the return shape (recommended bid plus low/high range per keyword) and the important asymmetry that Sponsored Brands only yields a campaign-level suggested CPC rather than per-keyword bids. It stops short of mentioning rate limits, freshness behavior, or batch caps, which are the remaining behavioral gaps.

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

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

Three sentences, front-loaded with purpose, then prerequisites, then the cross-product routing rule. The longer third sentence is dense but every clause carries actionable routing information (product, endpoint, and parameters), so nothing is padding.

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 need not enumerate return fields and it doesn't over-explain them. For an 8-parameter read-only tool with full schema coverage this is nearly complete; only operational details such as the 100-keyword/50-ASIN caps and freshness expectations are absent from the prose.

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 bidding_strategy's 'ignored when campaign_id and ad_group_id are provided' note and the include_raw_rows/include_diagnostics flags) is already documented in structured form. The description reinforces the asins-vs-IDs exclusivity and the new-vs-existing ad group distinction, but adds no syntax, format, 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?

The first sentence is a specific verb+resource+scope: "Get Amazon's suggested Sponsored Products keyword bids." It explicitly bounds the tool to Sponsored Products and later names the sibling that handles Sponsored Brands, so an agent can distinguish it from get_sponsored_ads_targeting_options and get_sp_targeting_options without opening any schema.

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

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

It states the two mutually exclusive calling modes (ASINs for a new ad group, or campaign_id + ad_group_id for an existing one) and names the exact alternative for the out-of-scope case, including the parameter values needed there (ad_product=SB, option_type=bid_recommendations, landing_pages). That is explicit when-to-use and when-not-to-use guidance with a named fallback.

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 readOnly, non-destructive, closed-world behavior. The description adds the metric scope and peer comparison, but omits operational behavior like date defaults, pagination, freshness, and raw/diagnostic row modes; those are left to the schema. Credit is limited because annotations cover the safety profile.

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

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

One front-loaded sentence with a tight metric list and no filler. It is appropriately sized for a retrieval tool whose parameter details live in 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?

For a 12-parameter read-only analytics tool with a full schema and output schema, the description gives adequate purpose and metric scope. It does not cover usage routing or operational defaults, but those gaps are mostly mitigated by rich schema and annotations.

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 all 12 parameters are documented in the schema, so the baseline is 3. The description reinforces brand/category filtering and metric outputs, but adds no parameter syntax, defaults, or enum guidance 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 ('Get') and resource ('Amazon Ads Brand Metrics health'), scopes it by brand and category, and names six metrics. It does not explicitly contrast with sibling tools such as get_brand_search_terms or get_share_of_voice, so it is clear but not fully sibling-differentiated.

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

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

It implies the tool is for retrieving brand health metrics by brand/category, but gives no explicit when-to-use, when-not-to-use, or alternative-tool guidance. An agent can infer the broad context but must decide between this and other brand/analytics tools without help.

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

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

Annotations already cover the safety profile (readOnly, non-destructive, closed-world), so the description earns credit for adding non-obvious behavior: it reads stored reports, requires a bounded window of at most 42 days, and exact-match lookups reject wildcard/substring scans. Minor inconsistency: it calls the date window 'required' while start_date/end_date are optional and default to the latest complete week.

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

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

Three dense sentences, front-loaded with the trigger, then view semantics, then operational constraints — no wasted clauses. The phrase 'required date window' is slightly misleading given optional date params with defaults.

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 14 parameters, an output schema, and full annotations, the description covers the pieces an agent most needs: which view to pick, what each returns, exact-match requirements, and the date-span cap. Return shape and pagination are handled by the output schema and the offset parameter description, so nothing critical 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, including view-scoped ones ('asin_terms only', 'term_products only') and the 42-day range limit. The description restates those same couplings rather than adding new meaning, so the baseline of 3 is appropriate.

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

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

The description names a specific resource (Amazon Brand Analytics Search Terms reports) and enumerates the three serving views with what each returns (top_terms = ranks, term_products = clicked products for one term, asin_terms = terms for one ASIN). That is a clear verb+resource statement. It falls short of 5 because it never distinguishes itself from the adjacent sibling get_search_terms (and get_search_query_performance), which an agent could easily confuse with this 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?

Opens with an explicit trigger: 'Use when the user requests Amazon Brand Analytics Search Terms reports,' and adds per-view applicability plus the constraint that lookup views need exact term/ASIN with no wildcards. It gives no explicit exclusions or 'use X instead' routing, so an agent has to infer that get_search_terms is a different dataset.

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 readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is known. The description adds genuinely useful behavior beyond that: the data is near-real-time, the used/remaining figures are derived estimates rather than billed spend, and the ad_product default silently resolves to SP when omitted. It stops short of describing snapshot freshness or pagination behavior, which the schema handles.

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

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

Three sentences, front-loaded with what the tool returns before the caveat and the default. The middle sentence about the ad_product default is mildly redundant with the schema's declared default of SP, but the framing as 'remains SP' signals backward-compatibility intent rather than pure repetition.

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

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

With an output schema present, the description needn't explain return shapes, and it correctly focuses on scope, the estimate caveat, and the default product. For a 15-parameter tool it does not cover pagination, latest_only behavior, or the at_risk threshold, but those are fully documented in the schema, leaving no meaningful gap for correct invocation.

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

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

Schema coverage is 100% across 15 parameters, so the schema already documents defaults, ranges, enums and the LIKE-match semantics for campaign_name. The description's only added parameter meaning is the emphasis that an omitted ad_product defaults to SP and that used/remaining amounts are derived — worth noting, but mostly restating the schema default. Baseline 3 is appropriate when the schema carries this much weight.

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: budget usage and pacing snapshots for SP/SB/SD campaigns, with the concrete outputs (Amazon's near-real-time usage percentage plus derived estimated used and remaining budget). It also distinguishes itself from performance/spend tools by warning that these estimates are not finalized cost, so an agent can tell it apart from get_campaign_performance and get_budget_recommendations without opening a schema.

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

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

It gives a clear when-to-use (budget usage and pacing snapshots) and an explicit when-not ('Do not treat estimated used budget as finalized advertising cost'), redirecting to retained campaign performance for finalized spend. The redirect names a data source rather than the exact sibling tool, so the routing is slightly less crisp than an explicit tool-name pointer.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds some value by disclosing that values are estimates (missed impressions, clicks, sales) rather than actuals, but says nothing about freshness, rate limits, or that the 100-campaign cap limits batching beyond what the schema states.

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

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

A single front-loaded sentence with no filler or repetition. It is appropriately brief, though brevity comes at the cost of any routing or behavioral 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, a fully described 4-parameter schema, and annotations covering the read-only/open-world profile, the description does not need to restate returns or safety. The remaining gap is guidance on when to select this versus adjacent recommendation and pacing 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%, including detailed profile_id fallback behavior and the include_raw_rows/include_diagnostics semantics, so the schema does the heavy lifting. The description adds no parameter-level meaning beyond what is already documented, which is the expected baseline of 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 ('Returns') and resource ('Amazon Ads budget recommendation API fields') scoped to campaigns, and enumerates the payload (suggested budgets, estimated missed impressions/clicks/sales). It implicitly separates itself from get_bid_recommendations by naming budget rather than bid, but never calls out that sibling explicitly.

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

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

There is no when-to-use guidance at all: nothing tells the agent to prefer this over get_budget_pacing, get_bid_recommendations, or get_campaign_performance. The only inference available is that it concerns budget recommendations for campaigns, which the agent must derive from the name and payload list.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. Beyond that, the description discloses data provenance and freshness (live SP-API vs. stored daily snapshots), the nullability contract for your_price with your_price_basis as the explanation, and the scope caveat that used offers appear only in used_buy_box_* fields. These are exactly the operational details an agent cannot infer from annotations.

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

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

The mode-selection sentence is front-loaded and the remainder is dense, field-specific context rather than filler. Three concepts (mode choice, field semantics, sibling pairing) are packed efficiently, though the sentence covering your_price/your_price_basis is information-dense enough to slow a quick read.

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

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

For a 7-parameter, dual-mode tool with an output schema and a clear set of annotations, nothing an agent needs to call it correctly is missing: mode triggers, scope boundaries, and complementary tools are all stated. Explaining return-field semantics is beyond what's required given the output schema, so the definition over-delivers rather than falls short.

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

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

Schema description coverage is 100%, so the baseline is 3; the description earns above that by explaining the semantic switch between modes — start_date triggers historical snapshot mode, and without it the call is live. It also clarifies that your_price is reported only when the seller holds the Buy Box, which frames how to read the results. It does not restate the ASIN cap or pagination limits, but those are fully documented in 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 names a specific verb and resource ("Check current Buy Box status for ASINs") and explicitly distinguishes two operating modes: live SP-API lookups versus stored win-rate history from daily pricing snapshots. It also removes ambiguity about which Buy Box is meant (Amazon's New Buy Box) and how used offers are scoped, so an agent can separate this from generic offer or pricing tools without opening the schema.

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

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

It gives clear triggering conditions for each mode: supply ASINs for a live check, or a date window to get history. It also directs the agent to pair the call with get_listing_restrictions, get_fba_eligibility, and get_suppressed_listings for a full buyability picture. The only gap is that it doesn't explicitly exclude neighboring tools such as get_listing_offers or get_competitive_pricing, which cover adjacent offer/pricing 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 readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered externally; the description adds substantial value beyond that with attribution-window behavior, a stated default of 14d, the fact that the response echoes the window, and a ~3-day incompleteness caveat. However, the long passage on refresh_window_open/settling_from_date is dense and partly restates freshness semantics an agent must infer from output fields, so it informs more than it clarifies.

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?

Purpose, metrics, grain, and the exclusion list are front-loaded in the first half, which is well ordered. The back half drifts into a lengthy, technical explanation of refresh-window semantics with hedges ('false is not a guarantee of finality') that could be tightened without losing meaning.

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

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

For an 11-parameter tool with an output schema, the description covers scope, exclusions, attribution behavior, latency caveats, and freshness-field interpretation. Return formats are left to the output schema, which is correct, and no parameter needed for a correct call is left unexplained.

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

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

Schema description coverage is 100%, so the baseline is 3, but the description genuinely adds meaning: attribution_window is explained as governing sales, orders, units, ACOS, ROAS, and CVR specifically, with a stated default and an instruction to omit it for SB/SD. That is interpretive context 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?

States a specific verb and resource ('Sponsored Products campaign-level ad performance over a date range') and enumerates the metrics returned (spend, sales, ACOS, ROAS, CTR, CPC, CVR). It also fixes the grain ('one row per campaign'), which lets an agent distinguish it from ad group, keyword, and search-term siblings without opening any schema.

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

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

Contains an explicit exclusion list: 'Do not use for ad group, keyword, search-term, ASIN, or total organic+paid sales questions,' each mapping to a clear sibling tool. Usage context (date range, attribution window selection) is stated rather than 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 readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds genuinely useful behavior beyond that: the minimum two-day data requirement, the inability to surface intermediate changes between captures, and the fact that this is not a live write readback — all of which set expectations an agent could otherwise get wrong.

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 core purpose, followed by view semantics, a limitation, and an exclusion. No repetition of the title or name, and every sentence carries information an agent needs.

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

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

For a 14-parameter, two-mode read tool with a full schema and an output schema, the description covers purpose, mode differences, data-freshness constraints, and sibling routing. Return-value detail is correctly delegated to the output schema, so nothing essential 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 each parameter is already documented, including the view enum, date defaults, and view-only filters. The description reinforces the semantics of view='history' versus view='changes' but does not add new parameter-level detail such as interaction between change_types and view or how date ranges behave in the changes view, 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?

The description names a specific resource (Sponsored Products campaign settings snapshots) and a specific source (the campaign_snapshots sync), then spells out exactly what each of the two views returns: daily state/budget/bidding/portfolio/placement rows vs. observed deltas between snapshots. It is clearly distinguishable from siblings like get_campaign_performance, which it explicitly excludes.

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

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

It states when each view applies, when the tool will not work ('requires at least two days of snapshots'), and names the specific alternative for metrics ('use get_campaign_performance for metrics'). That is explicit when-to-use, when-not, and alternative routing.

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

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

Annotations already declare readOnlyHint, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description still adds meaningful context beyond them: results come from snapshots rather than live validation, rows are ordered by a deterministic cleanup score, and the tool does not edit listings. It does not discuss staleness windows or empty-result behavior, which the schema exposes via include_diagnostics.

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

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

Two sentences with the usage trigger front-loaded, followed by a compact enumeration of returned signals and two crisp caveats. Nothing is redundant or padded.

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

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

With an output schema present and all eight parameters documented, the description only needs to establish scope, data source, and side-effect profile, which it does. The snapshot freshness caveat is partially delegated to the include_diagnostics parameter description rather than stated here, a minor gap.

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

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

Schema coverage is 100%, so filters such as sku, asin, cleanup_focus, and include_healthy are already fully documented. The description's only added semantic is that output is sorted by cleanup score, which is return-value behavior rather than parameter meaning. Baseline 3 is appropriate when the schema carries the parameter burden.

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

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

The description states a concrete verb and resource ('Returns stored Amazon errors and warnings, missing core content, offer or fulfillment gaps, and content-depth signals by listing') and names the ordering ('deterministic cleanup score'). It does not explicitly distinguish itself from close siblings like get_listing_quality or get_suppressed_listings, so an agent must infer the delta from the 'gaps/cleanup' framing.

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 trigger ('Use when the user asks about listing quality gaps across their catalog') and implicitly steers away from live-validation tools by noting snapshots. It stops short of naming a specific alternative for live checks or for single-listing lookups, so the routing is clear but not fully disambiguated.

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, non-destructive, open-world behavior, so the description is free to add value elsewhere, and it does by disclosing the data provenance distinction (live SP-API call versus daily snapshot history) and that history is bounded by a date window. It does not mention rate limits, latency, or the fact that live mode may return nothing for ASINs not yet observed, but the core behavioral split is clear.

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, both substantive, with the default behavior front-loaded before the alternative mode. There is no filler or 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?

With an output schema present, return values need not be explained, and the fully described 7-parameter schema means parameter detail is covered. What remains thin is scope relative to a large sibling set of offer and listing tools, and what exactly a "competitive price point" contains (buy box, lowest competitor offers), which would help an agent choose correctly.

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

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

Schema description coverage is 100%, so the schema already documents asins, limit, offset, start_date, end_date, include_raw_rows, and include_diagnostics in detail. The description reinforces only the date-window semantics, which the schema already states; it adds no new meaning about the ASIN cap, pagination, or diagnostics flags.

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

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

The description uses a specific verb and resource ("get competitive price points for ASINs") and immediately distinguishes two operational modes: live SP-API data versus stored history from daily snapshots. It does not differentiate this tool from closely related siblings such as get_listing_offers or get_offer_listings, which an agent may confuse with competitive pricing.

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

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

Usage is implied rather than stated: it tells the agent that omitting dates yields live data and supplying a date window yields history, which is a clear selection rule within the tool. There is no guidance on when to prefer this tool over sibling pricing/offer tools, nor on when live versus history mode is appropriate.

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

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

Annotations already declare readOnlyHint, destructiveHint=false and openWorldHint, so the safety profile is covered. The description adds that results come from Amazon's catalog search and that a target ASIN gets highlighted, but says nothing about latency, throttling, or what happens when the ASIN falls outside the requested page range.

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 action and followed by the return shape and the optional ASIN behavior. No filler, though the third sentence could have been folded into the second.

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 detail is not required. Still, for a live external-search tool the description omits scope limits: that ranking is bounded by max_pages (default 3, max 5) and therefore may not find the target ASIN at all — a material gap an agent should know before calling.

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

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

Schema coverage is 100%, so baseline is 3; the description adds meaning by explaining the effect of target_asin (highlighting its position in results) rather than just naming it. max_pages, include_raw_rows and include_diagnostics are left entirely to the schema, which is acceptable given full coverage.

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

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

States a specific verb and resource ('Check the current search rank position for a keyword') and adds a temporal qualifier ('in real time') that meaningfully separates it from stored-rank lookups. It does not name the obvious sibling get_keyword_ranks, so the agent must infer the split from the live/stored wording.

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?

'In real time' implies this is used for ad-hoc spot checks rather than bulk/historical rank reporting, which is the relevant distinction against get_keyword_ranks. However, no alternative tool is named and no when-not-to-use condition (cost, latency, repeated polling) is given.

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

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

Both annotations and the description agree the tool is read-only: readOnlyHint and destructiveHint are set, and the operation only reads. Beyond that, the description adds real behavioral detail the annotations do not cover. It describes the fallback data source and its trigger (incomplete Business Report backfill at 7/30/60/90-day lookbacks, using Amazon FBA Inventory Health shipped-unit velocity with the gap surfaced), the finalization-lag exclusion from the velocity average, and the rule that AWD on-hand appears as its own field but is excluded from the numerator. Together these let the agent interpret partial or shifted results correctly.

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

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

The definition is front-loaded with the core formula and scope before the data-source caveats and the exclusions at the end, so an agent reading top-down gets what it needs first. It is dense, though. The long parenthetical about finalization lag and the multi-clause fallback sentence could be split into shorter statements without losing meaning.

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

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

The tool is fairly complex, with a derived metric, multiple source systems, fallback logic, and 10 parameters, and the description covers the parts that would otherwise mislead: how cover is computed, when velocity comes from a fallback source, how AWD is treated, and how results are ordered. An output schema is present, so return-value documentation is not required here.

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

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

Schema coverage is 100%, so 3 would already be the baseline. The description still adds meaning: it explains which sales_lookback_days values (7/30/60/90) trigger the fallback source, states the default result order is lowest cover first (which maps to sort_order asc), and shows that cover is scoped per ASIN/SKU, so min/max_days_of_cover filter that derived metric. Fields such as include_raw_rows and include_diagnostics are left to their schema text.

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

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

The description names a specific verb and resource (per-ASIN/per-FBA-SKU replenishment coverage, days of stock remaining) and spells out the exact numerator and denominator: FBA fulfillable plus FBA inbound divided by recent FBA sales velocity. That level of specificity clearly separates it from sibling inventory tools such as get_fba_inventory and get_inventory_health.

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 explicit when-to-use guidance, tied to replenishment coverage, and explicit when-not-to-use guidance with three named alternatives (get_fba_inventory, get_inventory_health, get_inventory_risk_triage) for raw stock counts, aged inventory fees, and broad triage. The agent does not have to infer which sibling to pick.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered and the description needn't restate it. The description adds real context beyond annotations by noting the access-scoping ("records accessible to an Ads profile"), which implies results vary by permissions and may be empty. It does not discuss pagination or empty-result behavior, though the schema parameters partly cover those.

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

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

Two sentences, zero filler, with the purpose front-loaded and the workflow routing second. Every clause earns its place and an agent can act on it immediately.

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

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

An output schema exists, so return-value shape needn't be explained, and annotations cover the safety profile; the description supplies the missing piece — why an agent would call this. The only small gap is the absence of any note on empty results or access restrictions, but the schema already flags access-dependent behavior for advertiser_id.

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

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

Schema description coverage is 100% and the parameter descriptions are unusually rich (profile_id defaults, advertiser_id access caveat, include_raw_rows limits). The description adds no parameter-level meaning of its own, so the baseline of 3 applies — the schema, not the prose, carries parameter semantics.

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 ("Return Amazon-source DSP advertiser records") and scopes it to records "accessible to an Ads profile," which distinguishes it from the many other entity/performance tools in the sibling list. It even names the downstream consumer, get_dsp_entities_live, so an agent can place it precisely in the DSP workflow.

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

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

Gives an explicit positive use case: discover DSP advertiser IDs for the Amazon-Ads-AccountId header consumed by get_dsp_entities_live. That is a strong routing signal, but there is no negative guidance — nothing says when to skip this tool or how it relates to adjacent siblings such as get_sponsored_ads_entities_live or get_dsp_performance.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true and destructiveHint=false, so the safety bar is low. The description still adds real value by stating that only 'factual source fields' are returned and that no DSP writes are exposed, clarifying the tool is a passthrough to Amazon's documented v1 read endpoints rather than a derived-metrics or mutation surface. Return shape and pagination are left to the output schema and next_token parameter.

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

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

Two sentences, no filler, with scope stated first and the hard prerequisite plus read-only guarantee second. Every clause carries information the agent cannot get from the name alone.

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

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

For a 13-parameter, open-world live-API tool with full schema coverage and an output schema, the description covers purpose, the mandatory advertiser ID, and the read-only/no-write posture. Remaining details (pagination via next_token, entity-type filter applicability, raw-row vs compact row modes) are fully documented in the schema, so only a pointer to the adjacent DSP tools is genuinely 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 carries the per-parameter burden, including the entity-type-specific filter constraints. The description reinforces the meaning of the required amazon_ads_account_id (DSP advertiser ID header, not marketplace or tenant ID) but adds nothing about states, ids, or pagination beyond what the schema states. 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?

The description uses a specific verb and resource set: 'List Amazon-source DSP campaigns, ad groups, or targets.' That maps directly onto the entity_type enum and clearly separates this tool from the sponsored-products/sponsored-ads entity siblings. It stops short of naming the adjacent DSP siblings (get_dsp_performance, get_dsp_advertisers_live), so the distinction is inferable rather than explicit.

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

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

It states a hard prerequisite (an explicit Amazon-Ads-AccountId DSP advertiser ID, discoverable via get_dsp_advertisers_live in the schema) and makes clear the tool is a read-only lister of source records, which gives the agent a usable usage context. It does not explicitly say when to prefer this over get_dsp_performance or when not to call it, so the guidance is context-rich but exclusive-free.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered by structured data. The description adds the reporting version and aggregation grain, but says nothing about data latency, whether zero-spend rows appear, or how the default 30-day window behaves. Useful scope context, no real behavioral disclosure beyond 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?

Two sentences, front-loaded with the positive scope and followed immediately by the exclusions. Every clause carries information; there is no filler or repetition 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?

With 13 optional parameters, full schema coverage, an output schema, and safety annotations, the definition covers what an agent most needs: what data domain this returns and which adjacent domains it does not. The only shortfall is that freshness/latency expectations and the meaning of an empty result are left entirely to the schema's diagnostics flags.

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 13 parameters (date window, LIKE filters, pagination, sorting, diagnostics flags) are already documented in the schema. The description names metric families that partially map to the sort_by enum, but adds no filtering syntax or defaults beyond what the schema states. 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 ('Amazon DSP Reporting v3 performance') plus the three reporting grains (order, line item, creative) and the metric families returned (spend, sales, ROAS, viewability, video completion). This is clearly distinguishable from the many sponsored-ads siblings in the tool list.

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

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

Explicitly excludes Sponsored Products/Brands/Display, search terms, and seller account sales, and redirects the agent to 'the matching ads or sales tool'. The exclusion set is strong, but the alternative is named only as a class ('matching ads or sales tool') rather than a concrete sibling, leaving the agent to guess among get_sponsored_ads_report, get_campaign_performance, get_sales_and_traffic, etc.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, destructiveHint=false, so safety is covered. The description adds useful behavior beyond that: results come from live SP-API and include Amazon's own ineligibility reason codes, plus its role as a partial signal rather than a complete buyability verdict.

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 first, return value second, cross-tool positioning last. No redundant restatement of the title or schema, and nothing could be cut without losing information.

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

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

An output schema exists so return values need not be re-explained, and annotations cover the safety profile; the description supplies the remaining context (live source, partial signal, complementary tools). Minor gap: it does not hint that the `program` choice changes which eligibility is assessed.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds nothing about the `program` enum (INBOUND vs COMMINGLING) or the diagnostics/preview flags, leaving all parameter meaning to the schema.

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

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

Specific verb+resource ('Check if an ASIN is eligible for FBA') with source disclosed (live SP-API) and an explicit statement of what it returns (eligibility status and ineligibility reason codes). It is clearly distinguished from siblings like get_fba_inventory or get_listing_restrictions.

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 frames the tool as one of the 'buyability signals' and names three complementary tools for a full 'can buyers buy this right now' check, giving clear context for use. It stops short of stating when NOT to use it or how it differs from get_ad_eligibility, but the intended usage is unambiguous.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered; the description adds genuinely new behavior: links stream from Amazon, expire after 15 minutes, and document bytes are never returned inline. The prerequisite timing on the confirmation ID is also behavioral context the annotations cannot convey. It stops short of describing response shape or failure modes, so 4 rather than 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 sentences, front-loaded with the core deliverable (short-lived links) before the document list and prerequisites, with no filler. The prerequisite sentence is slightly awkward due to an apparent truncation ('the shipment's FBA... confirmation ID'), which very mildly harms readability but not comprehension.

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 need not explain return values, and it correctly focuses on link expiry, non-inline bytes, and prerequisite IDs. For a 12-parameter tool with five enums, the enum-selection logic (page_type, item_label_type, carton_label_type) is left entirely to the schema, which is acceptable given full coverage but leaves the definition one step from complete.

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

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

Schema description coverage is 100%, so every parameter is already documented in the structured schema, establishing a baseline of 3. The description reinforces the shipment_id/inbound_plan_id requirement but adds no syntax, format, or conditional logic beyond what the schema already states. Meaning added over the schema is marginal.

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 the concrete resource (FBA inbound shipping documents) and the specific artifact returned (short-lived authenticated download links), then enumerates the five supported document types: item labels, carton labels, pallet labels, BOL, and delivery challan. An agent can distinguish this from sibling tools like get_fba_inbound_plan or get_inbound_shipments without opening the schema.

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

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

It states the operative prerequisite clearly: carton/pallet labels and BOLs require the shipment's FBA confirmation ID, which only exists after placement confirmation. That is real when-to-use guidance tied to a timing condition. It does not name a sibling alternative or an explicit when-not-to-use case, so it falls short of a 5.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so safety is covered. The description adds behavior the annotations do not: the three possible status values and the distinction between blocking ERROR problems and non-blocking WARNING problems, which matters for deciding whether to retry. It does not say whether operation records expire or how long to wait between polls.

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, both front-loaded: the resource and its return values first, then the usage rule. No filler, no restating the title, and the key call-to-action (don't re-submit) lands last where it is read before invocation.

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

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

An output schema exists, so the description does not need to detail the response shape, and it still surfaces the most decision-relevant values (statuses, blocking vs non-blocking problems). With only one required parameter and full schema coverage, little is missing; polling/expiry guidance would make it complete.

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

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

Schema description coverage is 100%, so operation_id, include_raw_rows and include_diagnostics are already documented in the schema. The description only reinforces the origin of operation_id (returned by inbound write tools), which the schema also states. Baseline 3 is appropriate when the schema carries the parameter burden.

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

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

Names a specific verb+resource: fetching the status of an asynchronous FBA inbound operation, and enumerates the possible outcomes (SUCCESS, FAILED, IN_PROGRESS). It is clearly distinguishable from siblings like get_fba_inbound_plan or get_fba_inbound_documents because it reports on an operation identified by operation_id rather than returning plan or document data.

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

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

Explicitly states the triggering condition: use it to resume a write that returned 'processing' rather than re-submitting. That is a clear when-to-use plus an implicit when-not (don't re-submit the write). It stops short of naming sibling tools or specifying poll cadence, so it is strong 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 as read-only, non-destructive, and open-world, so the safety profile is covered. The description adds valuable behavior beyond that: it explicitly says no option is selected, notes that transportation options span all pages, and acknowledges appointment slots only exist where Amazon supports them. It does not discuss permissions, rate limits, or failure behavior when options have not yet been generated.

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

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

The description is front-loaded with the core action and the critical 'without selecting one' constraint. The first sentence is dense with parallel option-family details, but each clause carries useful distinguishing information; there is no filler.

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

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

For a complex, seven-parameter FBA tool with a full output schema and annotations, the description covers the essential context: what is returned, what is not done (no selection), the prerequisite generation step, and limitations on appointment slots. Nothing an agent needs in order to choose and call this tool correctly appears to be missing.

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

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

Schema description coverage is 100%, so the schema already documents all seven parameters, including conditional requirements such as shipment_id for delivery_window and appointment. The description adds some semantic color to the option_type enum by describing what each option family contains, but it does not add parameter-level usage guidance 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 opens with a specific verb and resource: 'Read Amazon-generated FBA inbound options,' and distinguishes the operation from selecting an option. It then enumerates the exact option families returned—packing, placement, transportation, delivery window, and appointment—which lets an agent differentiate this from plan-detail or shipment-list 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 establishes the key usage sequence: options must first be generated with prepare_fba_inbound_options, and this tool reads them without selecting one. That is a clear prerequisite and usage context, but it does not explicitly name a selection tool or state when to prefer this over adjacent FBA plan/shipment 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 cover the safety profile (readOnly, non-destructive, open-world), and the description adds real context beyond them: liveness of the data, the dual-identifier return on shipment detail, and the fact that freshness fields depend on include_diagnostics. It stops short of describing pagination/response-size behavior beyond what the schema's include_raw_rows note implies, so not a full 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?

Front-loaded with purpose and version, then progressively narrower detail (views, identifiers, reuse case, alternatives); no filler sentences. Minor deduction for the truncated identifier string ("the FBA... shipment_confirmation_id"), which reads as an artifact and slightly muddies an otherwise tight 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 an 8-parameter, view-switched read tool with an output schema and full annotation coverage, nothing essential is missing: the agent knows what each view yields, which identifier is needed downstream, when to prefer sibling tools, and that output shape is documented elsewhere.

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

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

Schema coverage is 100%, so baseline is 3, but the description meaningfully extends two modes: the single-plan summary "carries the full ship-from address in create_fba_inbound_plan input shape" and view=boxes "carries per-case dimensions, weights, and units" — telling the agent which view to pick for which data, which the enum alone does not.

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

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

Names a specific verb and resource ("Live FBA inbound plan state from the Amazon Fulfillment Inbound API (v2024-03-20)") and then enumerates exactly what the call returns: plan list, or one plan's summary, items, boxes, pallets, or shipments. This is distinguishable at a glance from neighbors like get_fba_inbound_documents or get_inbound_shipments.

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 routes the agent away from this tool when the goal is progress tracking: "For materialized receiving progress use get_inbound_shipments and get_shipment_receiving_status." It also gives a positive when-to-use case — reusing a recent plan as the source of defaults for a repeat shipment — including the caveat that Seller Central saved templates are not API-readable.

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

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

Annotations already establish readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuinely non-obvious behavior: future supply fields are Amazon-provided In-Stock Head Start values that stay null when the source omits them, and the tool defaults to the latest snapshot. It does not discuss pagination behavior or result-shape caveats, which the schema hints at instead.

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, then the null-behavior caveat, then the default and the explicit non-capability. Every sentence carries information, though the middle sentence is densely packed with bucket names and could have been split for readability.

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

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

An output schema exists, so return values need not be explained, and the description still covers the tricky parts an agent would otherwise misread: null future-supply semantics and the latest-snapshot default. Nothing needed to call this zero-required-parameter read 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 limit, offset, snapshot_date and the two diagnostic/raw-row flags is already documented in the schema; baseline is 3. The only added meaning is the 'defaults to latest snapshot' confirmation for snapshot_date, which is largely restated in 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?

Opens with a specific verb and resource ('stored Fulfillment by Amazon (FBA) inventory quantities per ASIN/SKU') and enumerates the exact quantity buckets returned (fulfillable, reserved with its sub-breakdowns, inbound, future supply, researching, unfulfillable). It explicitly contrasts with get_days_of_cover and get_sales_velocity, so the agent can separate it from nearby siblings 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?

The 'Use for stored ... inventory quantities' framing plus 'Returns stock quantities, not sales velocity or days-of-cover calculations' actively rules out two sibling tools and tells the agent which question this answers. It stops short of routing among the other inventory siblings (get_inventory_health, get_awd_inventory, get_inventory_by_fulfillment_center) and gives no prerequisite or exclusion guidance beyond that.

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

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

With readOnlyHint=true already supplied, the description adds useful behavioral context: 'Reads never create reports,' source labels distinguish allocations from posted settlement charges, and empty months report Amazon's request outcome. It does not discuss permissions, rate limits, or freshness mechanics, but those are partly covered by the 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?

The description is front-loaded and efficient, with each sentence conveying a distinct purpose, scope, output-mode, or behavioral fact. There is no filler or repetition.

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

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

Given the tool's complexity, 15 optional parameters, and the presence of an output schema, the description covers the key conceptual choices and scope limits well. Minor details such as pagination, date-range behavior, and diagnostics are left to the schema, which is appropriate.

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 input schema already documents all 15 parameters in detail. The description adds conceptual meaning about view/grain choices and source-label distinctions, but it does not provide parameter-level syntax or constraints beyond what the schema already supplies.

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

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

The description uses a specific verb, 'Returns,' and names the exact resource: monthly FBA storage estimates, Seller Economics product allocations, or long-term storage charges. It also distinguishes the tool from adjacent scope by stating 'FBA only, not AWD' and clarifies the output shape via source rows or summed grains.

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 clear usage context: choose among monthly storage, product allocation, or long-term charge views, and choose source rows or product/month sums. It also explicitly excludes AWD. It stops short of naming a specific sibling tool to use instead for AWD or general fee estimates, but the context is strong.

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

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

Annotations only declare a safe read, but the description discloses far more: profitability excludes ad spend, FBA storage fees, inbound freight, COGS and Adjustment/ServiceFee events; MCF fees are excluded from total_fees and surfaced separately; money is scoped to marketplace currency unless include_all_currencies is set; data_gap flags are described. These are exactly the caveats an agent needs to interpret results correctly and none are derivable from the annotations.

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

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

A single dense block with no front-loaded purpose statement and no paragraph breaks for a 15-parameter tool. Content is repeated across the description and schema (currency scoping and include_all_currencies, the order_id lookup window, the fee_breakdown grain behaviors). The information is valuable but badly ordered, so an agent must read the whole wall to find the entry 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?

For a tool with two views, three grains, 15 optional parameters and an output schema, the description covers the semantics an agent needs: date-basis separation, exclusion scope, reconciliation fields, currency mixing, and refund gap flags. It errs toward over-coverage by re-explaining return fields the output schema already defines.

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

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

Schema coverage is 100%, so the baseline is 3, but the description genuinely adds semantics: event_type/component_type filter before aggregation and pagination, omitting asin/order_id retains account-level rows, and pivots drop non-matching components plus rows lacking an ASIN or order. Those are behavioral consequences of parameter choices, not restatements of 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 actual purpose only surfaces mid-paragraph in 'Return Finances v0 financial-event rows and deterministic ASIN economics', after a long opening about filter mechanics for fee_breakdown. The verb+resource is specific once found, and the closing sentence distinguishes it from get_payment_transactions and get_settlement_economics. But a reader scanning the first sentence gets parameter trivia instead of what the tool returns.

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

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

Strong routing content: it names get_payment_transactions for pre-settlement Transaction View and get_settlement_economics for finalized settlements, and states 'Filters are not valid for profitability'. It also gives conditional selection between views and grains. It lacks an explicit when-not-to-use statement beyond those two hand-offs and never tells the agent when to prefer get_profitability_review or get_product_performance.

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

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

Beyond the readOnlyHint/non-destructive annotations, the description discloses real behavioral quirks: created_at is a best-effort inference from shipment_name with created_at_source flagging it, ambiguous or future dates return null rather than a wrong value, no received/closed timestamp exists here, and rows are tenant-wide regardless of marketplace key. This is exactly the kind of caveat an agent cannot get from structured fields.

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

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

Front-loaded with what the tool returns, then inference caveats, then sibling routing, then scoping. It is dense and slightly long, but nearly every sentence carries a caveat the agent would otherwise get wrong; little is padding.

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, fully-described-schema tool with an output schema, this covers the remaining gaps: data provenance, null behavior, absence of receipt timestamps, and marketplace scoping. An agent can call it correctly and interpret results without further guessing.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds genuine meaning: it clarifies that snapshot_date is the reliable refresh date while created_at is inferred, which directly informs sort_by choice. Date-range filtering semantics are left to the schema.

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

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

States a specific verb+resource (get FBA inbound shipment data) and enumerates exactly what is returned: shipment IDs, statuses, destination fulfillment centers, and refresh dates. It is clearly distinguishable from neighbors like get_awd_shipments or get_fba_inbound_plan, which concern other inventory flows.

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 routes the agent away from this tool when the question is about receipts or shipped-vs-received quantities, naming get_inventory_movements with event_type=Receipts and get_shipment_receiving_status as the alternatives. That is when-to-use and when-not-to-use stated 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 this as a non-destructive read, so the description's job is to add behavior — and it does: default snapshot date, the source view and aggregation (GET_LEDGER_SUMMARY_VIEW_DATA, aggregateByLocation:FC), and a non-obvious caveat that ledger data is account/tenant-wide with no native marketplace dimension. That last point materially changes how an agent should interpret and present results.

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

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

The core definition is front-loaded, followed by return contents, usage trigger, then source/caveats — a sensible ordering. The final tenant-wide/marketplace sentence is long and dense, but it carries genuinely load-bearing information 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?

For an 11-parameter, zero-required inventory query with an output schema, the description covers what the tool is, when to use it, what the rows contain, default time behavior, and the cross-marketplace limitation. An agent has everything needed to call it correctly and interpret the output.

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

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

Schema coverage is 100% with documented defaults and enums, so the schema already carries parameter meaning. The description adds some context for snapshot_date defaulting and the FC code format, but says nothing about the filter combinations (sku, asin, disposition, fulfillment_center) or how sort_by affects pagination. Baseline 3 is appropriate when the schema does the heavy lifting.

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

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

The description states a specific verb and resource (per-fulfillment-center on-hand inventory), enumerates the row grain (ASIN, SKU, FC, disposition) plus the flow components returned, and explicitly contrasts this with account-level inventory snapshots. An agent can distinguish it from get_fba_inventory or get_awd_inventory without opening the schema.

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

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

It gives a clear when-to-use trigger ('per-warehouse or geographic distribution of inventory') and a when-not signal ('account-level inventory snapshots do not provide this warehouse breakdown'). It stops short of naming the specific sibling tools that cover the account-level case, so the routing decision still requires a small inference.

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

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

Annotations already establish that this is a safe, read-only, non-open-world operation. The description adds useful behavioral context about returned health fields and the default exclusion of reimbursement placeholder SKUs, though it does not discuss pagination or response volume beyond what the schema covers.

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 sentences, front-loads the return fields, and then states the key filtering behavior and alternatives. There is no redundant or filler wording.

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

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

For an 11-parameter read-only inventory tool with a full output schema and annotations, the description gives enough context to select and invoke it correctly. It covers the returned signals, default synthetic-SKU filtering, and the main sibling alternatives without needing to repeat schema details.

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 11 parameters are already documented in the input schema. The description adds meaning mainly around include_synthetic_skus and default filtering, but does not explain most other parameters beyond what the schema provides.

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

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

The description uses a specific verb and resource ('Returns FBA inventory health snapshot fields') and enumerates the domains covered: age buckets, weeks of cover, storage fee risk, sell-through, and order/ship-in quantities. It clearly distinguishes the tool from get_fba_inventory and get_inventory_risk_triage.

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

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

It explicitly routes the agent to alternatives: get_fba_inventory for raw FBA stock counts and get_inventory_risk_triage for cross-signal risk rankings. It also clarifies the default filtering behavior and how to include synthetic reimbursement placeholder SKUs.

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