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

Annotations indicate readOnlyHint=false and destructiveHint=false, and the description adds valuable behavioral context: it explains the nature of AMC SQL (clean-room event tables) and constraints (aggregation thresholds, rejection of user-level data). This goes beyond what annotations provide, giving agents a clearer picture of what the tool does and its limitations.

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

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

The description is extremely concise (two sentences) and front-loaded: the first sentence states the core action, and the second adds a critical constraint. Every word serves a purpose, with no redundancy or filler.

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

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

Given the tool's complexity and the absence of an output schema, the description adequately conveys the purpose and key constraints. However, it lacks information about the return value, error scenarios, or the lifecycle (e.g., that saving does not execute the workflow). The openWorldHint annotation suggests more side effects may exist, which the description does not address.

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 80% (4 of 5 parameters described), so the baseline is 3. The description does not add parameter-specific details beyond the schema; it only provides general context about the sqlQuery parameter. While helpful, it does not significantly enhance understanding of individual parameters.

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

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

The description clearly states the action ('Save an AMC SQL workflow') and identifies the resource ('on an instance'). It distinguishes from sibling tools like amc_execute_workflow (which runs workflows) and amc_list_workflows (which lists them) by focusing on creation. The context about AMC SQL and aggregation thresholds further clarifies the tool's domain.

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

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

The description provides some guidance by noting that aggregation thresholds apply and that user-level queries are rejected, which helps agents understand constraints. However, it does not explicitly state when to choose this tool over alternatives (e.g., amc_execute_workflow for execution). There is no mention of prerequisites or when not to use it.

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?

Description communicates the async nature and non-destructive behavior, aligning with annotations (readOnlyHint=false, destructiveHint=false). Adds the polling pattern and result retrieval workflow, going beyond 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?

Two sentences, no wasted words, front-loaded with verb and resource. Perfectly concise.

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

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

Provides the essential workflow: execute, poll, fetch results. However, missing details on error handling, prerequisites (e.g., saved workflow exists), and the role of instanceId. With no output schema, the description covers the basic flow adequately.

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?

Description mentions 'over a time window' related to time parameters but does not explain key parameters like instanceId and workflowId, despite schema coverage only 57%. Schema descriptions exist for entityId, marketplaceId, timeWindowStart, timeWindowType, but the description adds little parameter-level detail.

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

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

Description clearly states 'Start an execution of a saved AMC workflow over a time window' with a specific verb and resource, and distinguishes from siblings like amc_get_execution (polling) and amc_get_download_urls (fetching results).

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 describes the async pattern: 'Returns an execution id; poll with amc_get_execution, then fetch results with amc_get_download_urls.' This provides clear context on when to use this tool (to start an execution) and the subsequent steps, though lacks explicit alternatives or when-not-to-use 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 indicate readOnlyHint=true and openWorldHint=true. The description adds value by disclosing URL expiration ('expire after a short period') and the signed/CSV nature, which is beyond what annotations provide. No contradictions.

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

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

The description is two sentences: the first states the core function, the second adds a critical behavioral detail. No redundant words; everything earns its place.

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

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

The description covers the main purpose and a key constraint (expiration) but does not describe the return structure (e.g., array of URLs) or error conditions (e.g., what if execution is not succeeded). With no output schema, this information would be helpful for agents.

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

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

Schema coverage is 50%; only entityId and marketplaceId have descriptions. The tool description adds no parameter-specific guidance. For the two undocumented parameters (instanceId, executionId), the agent must rely on naming alone, which is insufficient.

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

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

The description clearly states the tool retrieves signed download URLs for succeeded AMC workflow executions. It specifies the output format (CSV) and a key constraint (URLs expire). This differentiates it from sibling tools like amc_get_execution (status) and download_report (generic reports).

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 the tool is for 'SUCCEEDED' executions, providing clear context on when to use it. However, it does not explicitly state when not to use it or mention alternatives among siblings, leaving some ambiguity.

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?

Description adds the list of possible status values, which is helpful. Annotations already declare readOnlyHint and openWorldHint, so description adds modest additional context without contradicting.

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

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

Single sentence, front-loaded with essential information, no wasted words.

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

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

Given no output schema and moderate complexity (4 params), the description is minimal. It covers the status values but lacks details about response structure or error conditions. Annotations provide safety context but not completeness.

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

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

Schema description coverage is 50% (entityId and marketplaceId documented, instanceId and executionId not). The description does not provide additional parameter meaning for the undocumented ones, so it fails to compensate for the gap.

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?

Clearly states 'Check the status of an AMC workflow execution' with a specific verb and resource, and lists possible statuses. Distinguishes from sibling tools like amc_execute_workflow and amc_list_workflows.

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?

Implied usage (to check status after execution) but no explicit guidance on when to use vs alternatives, no when-not-to-use conditions.

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

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

Beyond annotations (readOnlyHint, openWorldHint), description adds that the tool requires entitlement and explains the 403 error as an Amazon entitlement issue, not a server bug. Provides valuable behavioral context.

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

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

Two sentences with no waste. Front-loaded with primary action, followed by critical prerequisite. Every sentence adds value.

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

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

For a simple list operation with two required parameters and no output schema, the description covers purpose, prerequisites, and error behavior. Annotations fill remaining gaps. Complete and sufficient.

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

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

Schema coverage is 100% with clear descriptions for both parameters. Description does not add meaning beyond schema; it sets context but doesn't enhance parameter understanding.

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

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

Description clearly specifies the action 'List Amazon Marketing Cloud instances for an AMC entity' with a specific verb and resource. It differentiates from sibling tools like amc_create_workflow and amc_list_workflows.

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 prerequisite 'REQUIRES a provisioned AMC instance with this API client allow-listed' and clarifies the 403 error meaning. Does not explicitly mention when not to use, but context from sibling tools implies alternatives.

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

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

Annotations indicate readOnlyHint and openWorldHint. The description adds 'on an instance' but does not elaborate beyond that. It does not contradict annotations, but adds little extra behavioral context for a read-only listing operation.

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 very concise, consisting of a single sentence. It is appropriately sized for the tool's simplicity, but it lacks some detail that could be included without becoming verbose.

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

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

Given the tool has 3 required parameters, no output schema, and annotations that partially cover behavioral traits, the description is incomplete. It does not mention pagination, result format, or any filtering capabilities, leaving the agent without sufficient context 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 67%: two parameters have descriptions, but instanceId does not. The tool description does not add any parameter-specific information beyond the schema, failing to compensate for the missing schema description.

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

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

The description clearly states the action ('List') and the resource ('saved AMC SQL workflows') and the scope ('on an instance'). It distinguishes this tool from siblings like amc_create_workflow and amc_execute_workflow.

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

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

The description provides no guidance on when to use this tool versus alternatives. It only states what it does without any context about when or when not to use it.

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?

Discloses async nature, immediate return, and typical 1-15 min completion (up to 3h). No contradiction with annotations (readOnlyHint=false, destructiveHint=false, openWorldHint=true).

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

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

Single paragraph packed with info; could benefit from bulletization. Front-loads key async behavior and workflow.

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?

Covers purpose, workflow, timing, examples, and common ids. No output schema, but explains return of reportId and polling needed. Missing explicit detail on groupBy/columns beyond examples, but schema covers those.

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

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

Schema coverage is 78%; description adds common reportTypeIds and example columns, plus hint to omit profileId for default. Adds value beyond 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?

Description clearly states the tool requests an async performance report for Sponsored Products, Brands, or Display, returning a reportId. It lists common reportTypeIds, distinguishing it from siblings like get_report_status and download_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?

Provides explicit workflow: request with create_report, poll with get_report_status, fetch with download_report. Mentions typical completion times. However, no comparison to alternative report creation tools like dsp_create_report.

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

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

Annotations already provide readOnlyHint=true. The description adds valuable behavioral context: decompression, integrity checks, server-side totals, and the saveAs mechanism to avoid dumping large datasets into chat. It also instructs to present reconciled totals, which is critical for proper agent usage.

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

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

The description is concise and front-loaded, starting with the core purpose and then detailing behavioral notes. Every sentence serves a purpose, though it could be slightly tightened 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?

Given no output schema, the description covers the return format (totals and row sample) and explains the validation checks. It also addresses large result set handling. Missing some error handling details, but overall sufficient for an agent to use correctly.

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

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

Schema coverage is 75%, with most parameters having descriptions. The description adds context that saveAs avoids dumping into chat and maxRowsInline controls inline rows, but it does not explicitly describe profileId or the default behavior. Overall, it adds marginal value beyond the schema.

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

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

The description clearly states the tool downloads a completed report, decompresses it, runs data-integrity checks, and returns reconciled totals with a row sample. It explicitly distinguishes itself from siblings like create_report and get_report_status by focusing on completed reports and validation.

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

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

The description explicitly states the report must be COMPLETED, which guides when to use this tool. It does not directly name alternatives, but the context of 'completed' implies it should be used after get_report_status indicates completion, making usage clear.

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

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

Annotations already mark readOnlyHint=false and destructiveHint=false. The description adds value by disclosing that the tool is async and requires polling, and that DSP API access is needed. No contradictions.

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

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

The description is two sentences, front-loads the action, and includes essential context without fluff. Every sentence is informative.

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

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

Given the tool has 9 parameters and no output schema, the description covers the return value (reportId) and next step (polling). It lacks error handling details but is sufficient for an async report request.

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

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

The input schema has 78% coverage with good descriptions per parameter. The description adds no additional parameter context, meeting the baseline of 3 for high coverage.

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

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

The description clearly states the action 'Request an async Amazon DSP report' and specifies data types (impressions, viewability, conversions). It distinguishes from sibling tools by mentioning the async nature and the polling mechanism with dsp_get_report. The tool name is not a tautology.

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

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

The description implies usage context: requires DSP API access, returns a reportId for polling. It does not explicitly contrast with sibling tools like create_report, but the async guidance is clear. Slight lack of exclusion criteria keeps it from a 5.

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

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

Annotations readOnlyHint and openWorldHint already indicate a safe read operation. The description adds that the response includes a signed download URL, which is useful. However, it does not disclose polling behavior, rate limits, or other side effects beyond what annotations convey.

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

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

The description is two sentences, front-loaded with the core purpose, and contains no extraneous information. Every sentence adds value.

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

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

The description covers the main action and the key output (signed URL). However, it does not describe the full response structure (e.g., status codes, timestamps) or usage pattern (e.g., polling). Given no output schema, additional detail would help.

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

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

The description does not mention any of the three parameters. With only 33% schema coverage (only profileId documented), the description fails to compensate for the undocumented accountId and reportId parameters. Agents lack context to understand what values to provide.

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

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

The description clearly states the tool checks the status of a DSP report and mentions the signed download URL upon completion. The title 'Check DSP report status' and verb 'Check' align well. It distinguishes from sibling tools like create_report and download_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?

The description implies you would use this after creating a report to check if it's ready, but it does not explicitly compare to alternatives like get_report_status or detail prerequisites. Usage guidance is present but not fully explicit.

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

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

Annotations already indicate readOnlyHint=true and openWorldHint=true. Description adds valuable behavioral context by clarifying the DSP access requirement and the nature of the 403 error (entitlement issue). No contradictions.

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

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

Two concise sentences with no fluff. The first sentence states the core purpose, the second adds critical precondition. Well-structured for quick 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?

Covers purpose and access requirements, but lacks details on response format, pagination behavior, or sorting/filtering. Given the absence of an output schema, more context on what the list returns would be helpful.

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

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

Only 33% of parameters have schema descriptions. The description adds no further meaning for startIndex and count beyond what the schema provides. It ties profileId to the DSP advertiser profile concept, but overall parameter semantics are weak.

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

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

Description clearly states the action (list), resource (DSP orders/campaigns), and context (DSP advertiser profile). It distinguishes from sibling campaign listing tools by specifying 'DSP', which is a distinct advertising platform.

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 prerequisite (DSP entity access) and the error behavior when not met (HTTP 403). Provides clear context for when to use, though does not explicitly mention alternatives among siblings.

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

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

Annotations already show readOnlyHint=true and openWorldHint=true. Description adds context about returned fields (profileId, marketplace, etc.) and the relevance of credentials and region, no contradiction.

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 efficient sentences with front-loaded purpose. Every sentence is useful, no wasted words.

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

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

For a parameterless, no-output-schema tool, the description fully explains its role, return fields, and why it should be called first.

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?

No parameters, so schema coverage is 100% and description need not elaborate. The description adds value by explaining what the tool returns.

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

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

The description uses a specific verb (List) and resource (advertiser profiles/accounts) and distinguishes from any sibling tools. No other tool lists profiles.

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 'Call this first' and explains that profileId scopes other tools, providing clear when-to-use 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 indicate readOnlyHint=true and openWorldHint=true; description adds valuable context about async status flow (PENDING→PROCESSING→COMPLETED/FAILURE with reason) and links to download_report for COMPLETED.

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 fluff, front-loaded with purpose. Every sentence adds useful information.

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

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

For a simple status-check tool with readHint, description covers the lifecycle and sibling dependency (download_report). Lacks detail on return fields, but acceptable given no output schema and tool simplicity.

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

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

Schema coverage is 100%, so the schema already documents parameters. Description adds value by noting profileId can be omitted to use a default and that reportId comes from create_report, improving usability.

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 it checks status of an async report from create_report, lists status progression, and mentions download_report for COMPLETED. Clearly distinguishes from sibling tools create_report and download_report.

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

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

Explicitly tells when to use download_report, implying it should be used after create_report. Provides good context but doesn't explicitly state when not to use it.

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?

Description states it 'refreshes the LwA access token', which is a write operation, contradicting the readOnlyHint=true annotation. Per scoring rules, contradiction leads to score 1.

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 efficient sentences front-loaded with purpose. Every word earns its place.

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

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

Given no parameters, no output schema, and annotations present, the description fully covers the tool's behavior and use case. The contradiction is noted but completeness is not diminished.

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?

No parameters (0 params), so baseline 4. Description adds no parameter info, which is acceptable since none exist.

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

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

The description clearly states the tool verifies credentials and connectivity, refreshes token, and lists profiles/region/latency/config. It distinguishes from siblings which are workflow/report-related.

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 tells when to use: 'Use to diagnose auth/setup issues.' This provides clear context with no ambiguity.

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 provide readOnlyHint (true) and openWorldHint (true), indicating a safe, non-exhaustive read operation. The description adds the optional filter for campaign ids but does not elaborate on pagination behavior or result structure. With annotations present, the description provides adequate but minimal additional behavioral context.

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

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

The description is a single, concise sentence that includes the core purpose, API version, and key capability, with no redundant or irrelevant information.

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

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

For a list operation with no required parameters and an output schema absent, the description is minimal but sufficient. It leverages the schema for parameter details and annotations for behavioral traits. The lack of output description is acceptable given the tool's simplicity and the presence of pagination parameters in the schema.

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

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

Schema description coverage is 80%, with four of five parameters documented. The only undocumented parameter (campaignIds) is clarified in the description ('optionally filtered by campaign ids'), adding meaning beyond the schema. The remaining parameters are already well-described 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 clearly states the verb 'List', the resource 'Sponsored Brands ad groups', specifies API version '(v4)', and notes the optional filter 'by campaign ids'. This effectively distinguishes it from siblings like sb_list_campaigns (lists campaigns) and sd_list_ad_groups (ad group list for Sponsored Display).

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 title and description specify 'Sponsored Brands', providing clear context for when to use this tool versus siblings for other advertising product types. While it does not explicitly list alternatives or exclusions, the naming convention and tool hierarchy make the intended use obvious.

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 openWorldHint=true. The description adds behavioral context by mentioning pagination via nextToken and the specific data returned (budgets, states, dates). No contradictions with 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 two sentences, front-loaded with the primary purpose, and concise. Every word contributes value without redundancy.

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

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

Given no output schema, the description outlines key return fields and pagination. While it omits campaign IDs or names, it is sufficient for a listing tool with well-named parameters and high schema coverage. Minor gaps prevent a perfect score.

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 80%, so baseline is 3. The description adds little beyond the schema: 'Paginate with nextToken' is already documented. CampaignIds parameter lacks description in both schema and description, but overall no additional value added.

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

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

The description clearly states the tool lists Sponsored Brands campaigns with specific fields (budgets, states, dates) and version (v4). It distinguishes from sibling tools by name and by pointing to create_report for performance metrics, leaving no ambiguity about its function.

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

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

The description provides explicit guidance to use create_report for performance metrics, indicating when not to use this tool. While it doesn't directly contrast with sibling list tools, the context of 'Sponsored Brands' and the tool name effectively narrows its scope.

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 and openWorldHint. The description adds marginal context about the data contents (bid optimization settings, states) but does not disclose behavioral traits like pagination, rate limits, or response structure, which would be useful. No contradiction with 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 a single, efficient sentence with no wasted words. It is front-loaded with the key action and resource.

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

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

The description, combined with annotations and schema, covers the core functionality. However, it omits explicit mention of pagination behavior (though schema includes startIndex and count). For a list tool with openWorldHint, this is 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?

With 100% schema description coverage, the baseline is 3. The description does not add any parameter-specific meaning beyond what the schema already provides; it only mentions the data returned.

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

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

The description clearly states the verb 'List' and the resource 'Sponsored Display ad groups', and it specifies what is included ('bid optimization settings and states'), effectively distinguishing it from sibling tools that list campaigns or ad groups for other ad types.

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 does not provide explicit guidance on when to use this tool versus alternatives like sd_list_campaigns or sb_list_ad_groups. Usage is implied by the tool name and resource type, but no exclusion criteria or contextual hints are given.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, covering safety and result bounds. The description adds that pagination uses startIndex/count (not nextToken), which is a useful behavioral detail. No contradictions with 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?

Extremely concise: two sentences with clear front-loading of purpose and pagination method. No wasted words.

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

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

For a list tool without output schema, it mentions returned fields (budgets, tactics, states) and pagination method. Could mention iteration pattern or default pagination values, but overall adequate given annotations (openWorldHint).

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 clear parameter descriptions (profileId, stateFilter with lower-case note, startIndex, count). The description does not add significant meaning beyond the schema; baseline score of 3 is appropriate.

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

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

Clearly states 'List Sponsored Display campaigns with budgets, tactics and states', specifying the resource (SD campaigns) and included fields. However, it does not explicitly differentiate from sibling list tools (e.g., sp_list_campaigns), which would improve clarity.

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?

Provides no guidance on when to use this tool versus alternatives like sb_list_campaigns or sp_list_campaigns. The only usage hint is the pagination method, which is more of a behavioral detail than a selection criterion.

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

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

The description indicates a read-only 'List' operation, aligning with the 'readOnlyHint' annotation. It adds context about pagination via nextToken. No contradictions, and the description complements the annotations by confirming 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?

Two sentences: one for purpose and version, one for optional filtering and pagination. Every sentence is essential, no unnecessary words. Highly efficient.

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

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

Given no output schema, the description is adequate but not comprehensive: it omits mention of state filtering and profileId handling. It covers the core functionality but could be more 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 coverage is 100%, so baseline is 3. The description adds value by summarizing optional filtering and pagination, but the schema descriptions already provide detailed param info, so the added meaning 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 clearly states 'List Sponsored Products ad groups (v3)', providing a specific verb ('List'), resource ('Sponsored Products ad groups'), and version. It distinguishes from siblings like 'sb_list_ad_groups' and 'sd_list_ad_groups' by the product type.

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

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

The description mentions that the tool can be optionally filtered to specific campaigns and pagination with nextToken, but does not provide explicit guidance on when to use it over sibling tools (e.g., sp_list_campaigns, sb_list_ad_groups). No when-not-to-use or alternative tool mentions.

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?

Description adds value beyond annotations: clarifies pagination mechanism (nextToken) and the nature of returned data (configuration, not spend/sales). No contradiction with readOnlyHint=true and openWorldHint=true.

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: first covers purpose and pagination, second provides critical usage guideline. No wasted words, front-loaded with key 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?

Given 5 parameters, no output schema, and good annotations, description covers purpose, pagination, and important distinction from metrics tools. Lacks example or return format but still adequate.

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 description adds little beyond schema. Mentions pagination token but doesn't elaborate on parameter meanings. 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?

Description clearly states verb 'List', resource 'Sponsored Products campaigns', and specifies included fields (budgets, states, targeting type, dates). Distinguishes from sibling tools like create_report by stating it returns configuration, not metrics.

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

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

Explicitly advises when not to use (for performance metrics, use create_report) and provides context about pagination with nextToken. Could mention alternatives for different ad types (sb_, sd_), but context from sibling names provides this implicitly.

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 openWorldHint=true. The description adds minimal extra behavioral insight (e.g., what attributes are returned). It does not disclose any additional traits like rate limits or data freshness, but the annotations sufficiently cover the read-only nature.

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

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

The description is two sentences, front-loaded with the primary action and key details. Every word contributes meaning without redundancy or fluff.

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

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

Given the tool has no output schema, the description provides reasonable context by listing returned attributes (match types, bids, states) and pagination. It could mention expected response structure more explicitly, but overall it is adequate for a simple listing tool with 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?

Input schema coverage is 100%, so the description adds limited new meaning beyond the schema. It mentions filtering and pagination but does not elaborate on parameter relationships or specific formats, maintaining a baseline score.

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

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

The description clearly states the tool lists Sponsored Products keywords, specifies version (v3), and mentions key attributes (match types, bids, states). It effectively distinguishes from sibling tools like sp_list_ad_groups or sp_list_campaigns by focusing on keywords.

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

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

The description provides clear context on filtering (by campaignIds or adGroupIds) and pagination (with nextToken), helping the agent understand how to use the tool. However, it does not explicitly state when to use this tool versus alternatives or provide exclusionary 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 indicate readOnlyHint=true and openWorldHint=true. The description adds that it lists 'which ASINs/SKUs are advertised in which ad groups, with states,' which provides relationship context. However, it does not disclose pagination behavior, default parameter values, or ordering, so it adds limited value 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?

The description is a single, information-dense sentence that captures the core functionality without fluff. It is front-loaded with the key verb and resource, making it efficient for scanning.

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 there is no output schema, the description should compensate by explaining what the response contains (e.g., fields of each product ad). It does not. While annotations cover safety and scope, the description omits output structure and critical details like result ordering or token usage, leaving the agent underinformed.

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?

All 6 parameters have descriptions in the input schema (100% coverage), so the schema already explains each parameter fully. The description adds no additional parameter information beyond the schema, earning the baseline score 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?

The description clearly states 'List Sponsored Products product ads (v3): which ASINs/SKUs are advertised in which ad groups, with states.' This provides a specific verb ('List'), resource ('product ads'), and scope ('Sponsored Products'), and distinguishes from sibling tools like sp_list_ad_groups or sp_list_campaigns.

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

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

The description lacks any guidance on when to use this tool versus alternatives (e.g., sp_list_ad_groups, sp_list_campaigns). No exclusions or context for selection are provided, leaving the agent to infer usage solely from the name and sibling 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 and openWorldHint=true, so the description's minimal behavioral information (listing types and fields) adds only marginal value. It does not disclose pagination behavior, rate limits, or other traits beyond what annotations cover, resulting in a baseline score.

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

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

The description is a single, front-loaded sentence with no wasted words. It efficiently conveys the resource, version, types, and included data fields.

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 (6 parameters, no output schema) and the presence of annotations, the description covers the essential purpose and output fields (bids and states). It could be enhanced by mentioning pagination or typical response structure, but it is largely complete for a straightforward list 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%, with all parameters having clear descriptions. The tool description adds no additional parameter information, so it meets the baseline expectation without adding extra value.

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

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

The description clearly specifies the verb 'List', the resource 'Sponsored Products targeting clauses', and includes the types (product, category, auto-targeting) and included fields (bids and states). It also notes the API version (v3), distinguishing it from sibling tools like sp_list_keywords or sp_list_campaigns.

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

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

The description does not provide any guidance on when to use this tool versus alternatives. It lacks explicit context for when to choose this over siblings like sp_list_keywords or sp_list_campaigns, and does not mention any prerequisites or exclusions.

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