signals

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

No annotations provided; description adds cost and billing behavior ('no data = no charge'). Does not describe error handling or response format, but covers key behavioral aspect.

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, front-loaded with 'Bundle', no wasted words. Efficient and clear.

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?

No output schema, description lists included signals but not response structure. Adequate for a bundled call given sibling tools exist.

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?

Single parameter with 100% schema coverage; description adds no extra semantics beyond 'for one brand-day' context. Baseline score 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 it's a bundle of all current signals for one brand-day, listing specific components (promotions, price stats, AI-readiness). Distinct from sibling tools that provide individual signals.

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?

Mentions cost (15 credits) and no-charge policy, implying use when all signals are needed. No explicit exclusions or alternatives, but context is clear.

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

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

With no annotations provided, the description carries the full burden. It discloses that results are 'freshness-stamped' and no charge if no data, but does not describe rate limits, what happens on errors, or pagination behavior for samples. Adequate but not comprehensive.

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 totaling ~25 words, with key information front-loaded: what is returned, optional filter, freshness, and cost. No unnecessary words.

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

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

Given the tool has 3 parameters and no output schema, the description effectively communicates the core output and cost model. However, it could be improved by briefly describing the structure of the returned price statistics (e.g., 'returns an object with stats and an array of samples').

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 parameters are documented. The description adds value by noting the 'query' parameter is an optional product-name filter and mentions 'Freshness-stamped', linking to data timeliness. It also implies 'limit' controls sample size.

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 provides price statistics (min/max/avg/median) and recent product samples for a brand, optionally filtered by product-name query. This is a specific verb+resource combination. However, it does not explicitly differentiate from sibling tools like get_brand_snapshot or get_history, which could also involve brand 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?

The description mentions cost ('1 credit; no data = no charge') and optional filtering, but does not provide guidance on when to use this tool versus siblings like get_promotions or get_readiness_score. Usage context is implied but not 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?

Despite no annotations, the description discloses that the tool is free and non-billable, which is critical behavioral info. It mentions per-signal freshness, hinting at output structure. While not exhaustive (e.g., no auth details), it adds meaningful behavioral context beyond the schema.

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

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

Two concise sentences. The first states the purpose, and the second provides usage guidelines. No unnecessary 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?

For a simple single-parameter tool with no output schema, the description covers purpose, usage timing, and hints at output (freshness). However, it lacks detail on the output format or what 'coverage' concretely means, which could be improved.

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 a single 'domain' parameter described as 'eCommerce domain, e.g. gymshark.com'. The description adds context about the output (signals and freshness) but does not enhance the parameter definition itself. 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 clearly states the tool checks competitive signal coverage for an eCommerce domain with per-signal freshness, specifying the verb ('Check') and resource ('coverage'). It distinguishes from sibling tools by focusing on coverage checking, which is a unique prerequisite action.

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 calling this tool before any billable tool to avoid paying for uncovered domains, providing clear when-to-use guidance and a usage pattern that optimizes cost. This helps an agent decide to use it as a preliminary check.

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

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

No annotations are provided, so the description must convey behavioral traits. It discloses credit scaling by depth and the no-charge policy for missing data, which are useful. However, it omits other key behaviors such as idempotency, rate limits, error handling, or whether the operation is read-only (assumed but not stated).

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 at two sentences, front-loading the core purpose. It avoids extraneous details. However, the title includes credit cost information that is repeated in the description, which could be streamlined. Overall, it is 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?

With no output schema, the description partially compensates by indicating the output shape: monthly time-series of price changes or stock-status flips. It also covers cost implications. However, it lacks details on output format (e.g., data points structure), pagination, or limitations like maximum time range beyond 24 months. For a tool with three parameters, this is adequate but not fully complete.

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

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

Schema description coverage is 100%, so the schema already documents all three parameters (domain, months, signal). The description adds minimal extra meaning beyond mentioning the parameters in context (e.g., signal types as 'price' and 'stock_status'). It does not provide examples or clarify default behavior (e.g., default months=3) 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?

The description clearly states the tool provides a monthly time-series of price changes (drops, rises, avg delta) or stock-status flips for a brand. It uses specific verbs and resources, making the purpose evident. However, it does not explicitly distinguish from sibling tools like get_brand_snapshot or get_competitor_price, which may also involve time-series 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?

The description mentions credit cost tiers for different depth ranges and a 'no data = no charge' policy, providing some guidance on when to use the tool. However, it lacks explicit when-not-to-use guidance or references to alternative tools for different needs (e.g., real-time data). The usage context is implied 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?

No annotations are provided, so the description carries the full burden. It notes 'Freshness-stamped' and 'no data = no charge', but lacks disclosures on authentication needs, error handling, or what happens with invalid domains.

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, front-loaded with the core purpose and key return fields. 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 a single parameter and no output schema, the description adequately explains what is returned and notes freshness and cost. Could be slightly more detailed about response format (e.g., array) but overall 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?

The input schema has 100% coverage with a single parameter 'domain' described as 'eCommerce domain'. The description adds minimal extra meaning beyond the schema, only hinting at 'brand' context.

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

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

The description clearly specifies the verb 'get' and resource 'promotions', enumerates the returned fields (code, discount type/value, min order, validity window), and differentiates from siblings like 'get_brand_snapshot' which cover broader brand info.

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

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

No explicit guidance on when to use this tool over alternatives. The description implies it is for active promotions, but does not mention exclusions or provide context for choosing 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?

With no annotations provided, the description only mentions the one-credit cost and no-charge policy when no data exists. It omits behavioral details like error handling, rate limits, or idempotency, which is insufficient for a tool with zero annotation coverage.

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

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

The description is two concise sentences that front-load the core purpose and add only essential credit-related information without any fluff or 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?

For a simple one-parameter tool with no output schema, the description covers what it does and the cost model, but lacks specification of the output format (e.g., structure of score, tier, highlights) which would improve 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?

The only parameter 'domain' is described in the schema as 'Domain to score'. The tool description adds no further semantic detail (e.g., format, examples), so it meets the baseline for 100% schema 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 it computes an AI-readiness score using six specific pillars, and distinguishes itself from sibling tools by mentioning 'Uniquely RivalSweeper data' and the focused purpose.

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

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

The description implies usage when a general AI-readiness assessment for a domain is needed, but lacks explicit when-to-use or when-not-to-use guidance compared to sibling tools like get_brand_snapshot or get_competitor_price.

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

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

With no annotations provided, the description carries the full burden. It discloses that the tool is free but requires prepaid balance, and that data takes 24-72h. It does not detail potential side effects (e.g., recurring cost implications) but covers key behavioral aspects for a request tool.

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

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

Two sentences, no waste. The purpose is front-loaded, with key constraints (free, prepaid, timing) in the second sentence. Every word 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?

Given the tool's simplicity (one required param, no output schema, no annotations), the description provides essential context: what it does, cost, account requirement, and timing. It lacks mention of confirmation or error behavior but is adequate for the scope.

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

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

The schema covers the single parameter ('domain') with 100% description coverage. The tool description does not add any meaning beyond the schema's 'Domain to start monitoring'. Baseline score of 3 is appropriate.

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

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

The description clearly states the action: 'Ask RivalSweeper to add a domain to monitoring.' It uses a specific verb ('add') and resource ('domain to monitoring'), which directly distinguishes it from sibling tools that are all 'get_*' retrieval tools.

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

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

The description says it is free but requires an account with positive prepaid balance and that first data arrives in 24-72h. It provides usage context and constraints, but does not explicitly mention when not to use or name alternative tools. The distinction from read-only siblings is implicit.

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