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

With no annotations carrying the burden, the description clearly discloses the key behavioral trait: it returns a numeric cohesion score between 0 and 1 based on merchant order data. It also communicates the statistical-signal framing and the decision-oriented purpose. It could go further by noting any caveats, edge cases, or failure behavior, but for a read-only scoring tool the core behavior is well explained.

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

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

The description is efficiently structured: first sentence states the core action and output, second sentence gives the primary use case, third sentence adds query paraphrases. Every sentence earns its place and there is no redundant or vague 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?

The tool is simple (one parameter, no output schema), and the description covers all an agent needs: what the tool does, what input it expects, what the output represents, when to use it, and example user-phrasing signals. It is sufficiently complete for both selection and 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?

The schema already fully describes product_ids as 'The products in the proposed basket (2-6)' with min/max constraints at 100% coverage. The description adds slight framing ('Given 2+ products', 'proposed basket/bundle') but does not meaningfully extend the semantics beyond what the schema already 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 names a specific verb ('Run market-basket analysis'), resource ('proposed basket / bundle'), and outcome ('cohesion score 0..1'). It also distinguishes itself from sibling generation tools by framing itself as a vetting step 'BEFORE recommending' a bundle, making it clear this is an evaluation tool rather than a recommendation or forecasting tool.

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 usage context: use to vet a proposed bundle before recommending it and to avoid plausible-but-unsupported bundles. It also lists natural-language triggers ('is this a good bundle?', 'do these products go together?'). It stops short of naming sibling alternatives or stating when not to use the tool, so it earns a 4 rather than 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?

No annotations are provided, so the description carries the behavioral disclosure burden. It discloses idempotency ('Idempotent by action_id, safe to retry') and unsupported-platform behavior ('returns a clear not-available message'). It does not detail permissions or irreversibility of the concrete actions, but the examples and confirmation guard give adequate awareness of mutation.

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 carry purpose, examples, idempotency, usage timing, and platform availability. The core purpose is front-loaded and every sentence earns its place with no redundant 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 two-parameter execution tool with 100% schema coverage, the description covers what the tool does, when to call it, retry safety, and failure behavior on unsupported platforms. No output schema exists, but the description gives enough context for an agent to select, invoke, and interpret the likely result.

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 already describes both parameters fully, so the baseline is 3. The description adds semantic value by explaining that action_id is the idempotency key and that it comes from get_weekly_plan, and by tying confirm to the prerequisite that the merchant has confirmed the action. This goes slightly beyond the raw 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: 'Execute a specific action from the merchant's weekly plan', and gives concrete examples such as publish bundle, run mining job, and archive rule. It is clearly distinct from get_weekly_plan because it performs an action rather than listing the plan.

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 when to use it: 'AFTER the merchant has confirmed which action from get_weekly_plan they want to run', and gives a clear when-not-to-use instruction: 'do not call preemptively'. It also explains the platform context and what happens on unsupported platforms, which helps the agent decide whether to call it at all.

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, the description carries the full burden of behavioral disclosure. It reveals conditional return content (support, lift, and order sample count only when the rule is still live), graceful handling of disappeared pairs, and the BigCommerce-only platform limitation. It does not explicitly state read-only/idempotent behavior, but the return-oriented wording makes the tool's non-mutating intent 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?

The description is appropriately sized at three sentences and front-loads the core purpose before covering usage context, sibling distinction, and edge-case behavior. Every sentence contributes non-redundant value, including the platform limitation.

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 required parameter and no output schema, the description gives an agent everything needed to call the tool correctly: what to pass, what will be returned, when to use it, which sibling it differs from, and how a missing pair is handled. No critical operational detail 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%, and the alert_id parameter is already documented as coming from get_drift_alerts. The description reinforces this source and uses alert_id contextually, but it adds no new format, type, or validation details beyond what the input schema already 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 states a specific verb and resource: 'Explain ONE drift alert' and enumerates what it returns. It also explicitly differentiates itself from get_drift_alerts by noting that the sibling lists the feed while this tool drills into a single alert_id.

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 triggering scenarios with exact merchant phrasings like 'why did this pair drift?' and says to use it after seeing an alert in get_drift_alerts. It also names the alternative get_drift_alerts and explains the difference, which helps an agent select the correct sibling.

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 behavioral disclosure burden. It clearly discloses the return content (statistics plus plain-language narrative) and scopes the tool to BigCommerce today. It does not explicitly state read-only behavior, but 'explain' and the return description imply no mutation.

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 purpose and output, then gives usage triggers and sibling differentiations. Every sentence earns its place; the comparison sentences are compact and high-value rather than redundant.

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

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

Although there is no output schema, the description enumerates the return fields and narrative style, so an agent knows what to expect. It covers the single parameter, the intended usage context, platform scope, and relationships to sibling tools, making the description complete for this low-complexity 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 the schema already documents opportunity_id and its source. The description reinforces that the id comes from get_opportunities and refers to a single opportunity, but it adds little meaning beyond the schema.

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

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

The description states a specific verb ('Explain'), a specific resource ('ONE mined opportunity'), and the concrete outputs (support, confidence, lift, order sample count, narrative). It explicitly differentiates itself from get_opportunities and get_rationale, so an agent can distinguish it from siblings without inspecting schemas.

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

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

The description gives explicit trigger phrases ('why is this a good cross-sell?', 'explain this opportunity', 'why should I bundle these?') and the context of use ('after seeing it in get_opportunities'). It also names the alternatives it is not, making the when-to-use decision 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?

With no annotations provided, the description carries the behavioral burden. It clearly discloses the return shape: a ranked list with similarity score and a reason category. It also states platform coverage. It does not mention potential side effects, but a recommendation tool is clearly read-oriented.

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?

Every sentence earns its place: core purpose, contrast with cross-sell, example triggers, output format, and platform scope. It is front-loaded with the key definition and contains 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?

The description fully covers the essential return information despite no output schema, and the input schema fully documents both parameters. The platform list and explicit use examples make this complete for an agent deciding whether to call it.

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

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

Schema description coverage is 100%, so the parameters are already well documented in the schema. The description adds only general context ('top substitute items', 'for a given product') without materially enriching the schema's parameter semantics. 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: 'recommend the top substitute items that could REPLACE it'. It actively distinguishes itself from complement/cross-sell tools by stating 'not complement it' and 'inverse of cross-sell', making its purpose unambiguous even among many siblings.

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

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

It provides explicit usage triggers such as 'what's a substitute for X?', 'out of stock', 'replacement', and 'equivalent product', plus the procurement-swap scenario. It also excludes the complement use case, giving concrete when-to-use versus 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?

With no annotations provided, the description carries the burden, and it does well: it discloses the algorithm (additive Holt-Winters), the data source (stored historical sales), and the advisory nature ('recommend'), implying no order execution. It could be more explicit about side effects or output shape, but the key behavior 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?

The description is compact and front-loaded: purpose first, method second, usage triggers third. The four example queries are somewhat repetitive but still useful for agent routing, so it earns a 4 rather than a 5.

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

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

For a simple two-parameter tool with no output schema, the description gives enough context to select and call it correctly: it names the inputs, the method, the data source, and the intended output (forecast plus recommended buy quantity). Exact return structure is unspecified, but not critical for 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?

Input schema coverage is 100%, with strong descriptions for both bundle_id and horizon_weeks, including default, range, and week-vs-day conversion. The description adds only generic 'configurable horizon' context, so it does not need to compensate further.

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: forecast weekly sales and recommend a buy quantity for a specific bundle. It also gives concrete user-query examples, making the tool's scope unmistakable and distinguishing it from alert/opportunity 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?

The description explicitly provides 'Use this when...' triggers and targets inventory/purchasing/merchant-ops agents. It does not name alternatives or give explicit when-not-to-use guidance, so it stops 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?

No annotations are provided, so the description carries the full burden. It does disclose the analytical behavior (multi-item basket analysis for cart completion, whole-cart pairing) and implies a non-mutating read operation, but it does not explicitly state that nothing is modified, how results are scored, or what happens with invalid product IDs. This is acceptable but leaves some behavioral details implicit.

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 purpose, then gives concrete usage signals, then differentiates from a sibling tool. No sentence is wasted, and the structure makes it easy for an agent to process quickly.

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 only two parameters and no output schema, the description covers the essential invocation context: what input is expected, when to use it, and how it differs from the closest sibling. It does not describe the return structure, but the absence of an output schema makes that a minor gap rather than a critical one.

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 already documents both parameters with 100% coverage, including defaults, ranges, and accepted formats. The description adds useful context that the cart must contain MULTIPLE products and that pairing is whole-cart, but it does not significantly deepen the parameter semantics beyond the schema.

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

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

The description uses a specific verb ('recommend') and resource ('products that frequently bundle with the cart'), and clearly frames this as multi-item basket analysis for cart completion. It explicitly distinguishes itself from get_recommendations by emphasizing MULTIPLE products and whole-cart pairing, so an agent can tell them apart.

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 explicit trigger phrases ('what else do I need?', 'what completes this set?', etc.) and states when it should be used: when a user describes a multi-item cart. It also provides a when-not/alternative point by explaining the difference from get_recommendations.

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, the description carries the behavioral burden and does well: it clarifies the comparison baseline (prior mining job), the change types (weakened, strengthened, disappeared, emerged), and the platform-dependent behavior (BigCommerce today; clear not-available message elsewhere). It does not mention ordering or pagination, but those are minor for a read/list 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?

The description is three sentences with no filler, front-loading the core action and scope before use cases and platform caveat. Every sentence contributes distinct, useful information.

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

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

For a simple two-parameter list operation with full schema coverage, the description covers trigger conditions, output concept, and platform limitations. It does not specify the exact shape of an alert beyond rule/confidence-change, but that is sufficient 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%, with both limit and severity already documented with defaults, ranges, and enum values. The description adds no additional parameter-specific meaning, so the baseline 3 is appropriate.

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

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

The description states a specific verb and resource ('list active drift alerts') and defines what a drift alert is: recommendation rules whose confidence has materially changed versus the prior mining job. It also differentiates this from related siblings like get_forecast_alerts and explain_drift by focusing on material confidence changes.

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 explicit trigger phrases and use cases: 'what's changed?', 'is my model still accurate?', 'are any rules drifting?', and SKU swap/seasonal shift investigation. It does not name sibling alternatives or state when not to use this tool, but the when-to-use guidance is otherwise very 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?

No annotations are provided, so the description carries the full behavioral burden. It discloses platform-dependent behavior ('BigCommerce today; on other platforms... returns a clear not-available message') and how the tool should be chained with forecast_bundle — both genuinely useful and not derivable from the schema. It does not disclose data freshness or whether alerts are computed on-the-fly versus batch-generated, which would matter for restock decisions.

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

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

Four sentences with purpose front-loaded and the alert kinds packed into the first sentence. The query examples and platform note each earn their place. Minor redundancy: the four alert kinds restate enum values already present 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?

Given no output schema and no annotations, the description covers triggers, alert kinds, pairing strategy, and platform behavior — a strong burden for an agent to call it correctly. The notable gap is an explicit contrast with sibling alert tools (get_drift_alerts, get_opportunities) and any hint at the return shape, though the absence of an output schema makes the latter less critical.

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%; every parameter (kind, limit, severity) is fully documented with enums, defaults, and min/max bounds. The description's list of alert kinds roughly mirrors the kind enum, adding little semantic value beyond the schema. The baseline 3 applies since 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 uses a specific verb-resource pair ('list forecast-based alerts') and enumerates the exact content ('bundles with stockout risk, demand drop, demand spike, or an unreliable forecast curve'). This clearly distinguishes it from alert-adjacent siblings like get_drift_alerts or get_opportunities by anchoring it to forecast-based inventory alerts.

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?

Four concrete merchant queries are provided as trigger phrases ('what's at risk of stockout?', 'which bundles are losing demand?', etc.), which is strong positive usage guidance. It also names the companion tool ('Pair with forecast_bundle to drill into a specific bundle') and notes platform availability. It stops short of a 5 because it never explicitly states when NOT to use it versus siblings like get_drift_alerts or get_opportunities.

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 platform-dependent behavior (BigCommerce today, clear not-available message elsewhere) and implies a read-only listing operation. It could add response-shape details, but the disclosed behavior goes beyond the bare minimum.

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 compact sentences, front-loaded with the primary purpose and followed by usage examples, a pairing note, and platform behavior. Every sentence earns its place 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 only two optional parameters and no output schema, the description is sufficient for correct invocation: it defines what is returned (ranked opportunities with scores), the default status context, and the cross-platform fallback. A mention of the response fields would make it fully complete.

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

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

Schema coverage is 100%, with both parameters already documented clearly, including defaults and enum options. The description does not add parameter-specific meaning beyond the schema, so the baseline 3 is appropriate.

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

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

The description clearly states a specific verb (list), resource (merchant's ranked bundle/cross-sell opportunities), and scoring fields (support/confidence/lift/revenue-weighted score). It does not explicitly contrast itself with sibling tools like get_recommendations or find_substitutes, so it stops short of a 5.

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

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

The description gives concrete example user queries ('what are my top opportunities?', 'show me the best bundles I haven't published yet') and appropriately pairs with triage_opportunity for acting on a result. It provides clear context for when to use the tool, though it does not state when not to use it or name 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?

With no annotations present, the description carries the behavioral disclosure burden. It clearly discloses the output type, length, tone, and example content ('short merchandiser-grade explanation'), which goes beyond the schema. It does not discuss failure modes or edge cases, but for a simple fetch-style tool this is largely sufficient.

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

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

The description is three tightly written sentences with no filler. It front-loads the core purpose, then gives the return format and the invocation guidance. Every sentence 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 the tool's simplicity, no output schema, and two fully documented parameters, the description covers the essential context: what the explanation looks like, where it fits in a recommendation flow, and when to call it. Slightly more detail about output formatting or error behavior could push it higher, but 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?

The schema already provides 100% coverage for both parameters, including their roles as antecedent and consequent. The description adds the product A/product B framing, which is helpful but largely restates what the schema already communicates, so it does not significantly raise the value above the schema baseline.

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

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

The description names a specific verb ('Fetch'), a specific resource ('the one-sentence rationale for why product B is recommended alongside product A'), and clearly distinguishes this from related sibling tools like get_recommendations and get_bundle_for_cart by focusing on the explanation step rather than the recommendation construction step.

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 states when to use this tool ('after get_recommendations / get_bundle_for_cart') and gives concrete trigger phrasings ('why are these recommended together?' or 'explain this pairing'), leaving no ambiguity about the intended invocation context.

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

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

No annotations are present, so the description carries the behavioral transparency burden. It transparently explains the recommendation source ('mined order-history association rules') but does not explicitly state whether the call is read-only, what response shape to expect, or any platform-specific behavior beyond broad compatibility.

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 purpose is front-loaded, followed by concrete query examples and a platform-support note. The trigger list is slightly long but earns its place by helping agents recognize equivalent user requests.

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 two-parameter tool with no output schema, the description is reasonably complete: it names the algorithm, scope, trigger phrases, and supported platforms. It does not describe the response format, but the simple recommendation semantics make that 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 description coverage is 100%, and the input schema already documents both product_id and limit with defaults and accepted formats. The description adds little beyond the schema, mostly reinforcing that product_id identifies the product for cross-sell recommendations.

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: it recommends complementary, frequently-bought-together products for a given product, based on association rules. It also explicitly positions itself as the single-product cross-sell tool, which distinguishes it from sibling bundle and substitution 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 provides clear trigger examples such as 'what goes with X?' and 'recommend products to cross-sell with X', making usage conditions easy to match. It does not explicitly name alternatives to avoid or say when not to use this tool, so it stops short of full exclusion 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?

No annotations are provided, so the description carries the full burden. It discloses the return shape (ranked list of typed actions), gives examples of action types, and clearly states the not-available behavior on non-BigCommerce platforms. For a read-only fetch, this is solid transparency, though it could add details about freshness or ordering criteria.

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 comprised of two dense, purposeful sentences: the first covers what the tool does and what the output looks like; the second covers usage triggers and platform behavior. There is no redundancy, and every clause earns its place.

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

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

With no parameters and no output schema, the description sufficiently covers what the agent needs to select and invoke the tool: purpose, sample output shape, trigger phrases, and platform availability. It could mention success behavior in more detail (e.g., empty plan handling), but the provided examples and not-available note already cover the main edge case.

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

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

The tool has zero parameters and the schema coverage is 100%, so the baseline is 4. The description adds no parameter information, but none is required because there are no inputs to document.

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 a specific verb ('Fetch') and resource ('current weekly action plan for the merchant') with a helpful elaboration of the returned content (ranked list of typed actions). It does not explicitly differentiate from siblings like get_recommendations or get_opportunities, but the 'weekly plan' concept is distinct enough that an agent should be able to pick it out.

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 concrete trigger phrases ('what should I work on this week?', 'what's on my plate?') and notes the platform limitation (BigCommerce today; not-available message elsewhere). It provides clear when-to-use context but does not name alternative tools or explicitly say when not to use it, so it stops just 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?

No annotations are provided, so the description carries the behavioral disclosure burden. It mentions the Plus or Enterprise tier requirement and the ranked-output behavior, but does not explicitly state whether the operation is read-only, how empty or malformed orders are handled, or how top_k and min_utility interact.

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 tightly written sentences with no filler. The core operation is front-loaded, followed by the output contract, then the appropriate usage context.

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 analytics tool with a detailed input schema, the description covers the core contract: input payload, profit metric, ranking, and tier requirement. However, there is no output schema and the description does not specify the result shape or edge-case behavior, leaving some ambiguity for an agent deciding how to handle the response.

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

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

The input schema already covers 100% of parameters with descriptions, so the baseline is 3. The description adds useful context that utility is the sum of per-line profit and that top-K controls output size, but it does not add meaning for min_utility beyond what the schema already 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?

Opens with a specific verb and resource: 'Run high-utility itemset (HUI) mining' on a caller-supplied payload. It also states the output, top-K itemsets ranked by aggregate utility, and explicitly differentiates from frequency-based analysis with 'not just frequency', which helps distinguish it from sibling analytics 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?

Gives an explicit use condition: evaluate which item combinations drive the most profit for a specific time window or product subset. It provides a negative cue ('not just frequency'), but it does not name sibling alternatives or state when those would be preferred.

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

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

With no annotations available, the description carries the behavioral disclosure burden and does so well: it reveals that only SKUs ordered >=2 times are considered, that confidence derives from cadence regularity, and that results are bucketed into four categories. It also discloses backend availability. However, it does not explicitly state that the call is read-only or describe behavior for unknown customers or customers with no eligible SKU history.

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?

Though longer than a typical description, every sentence serves a distinct purpose: audience, core action, output behavior, bucket labels, example queries, backend support, and a platform exclusion. It is front-loaded with the essential action and contains 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 absence of an output schema, the description sufficiently explains the return value shape (predicted next-order dates, confidence, buckets) and provides usage triggers. It also covers optional filtering and backend constraints. Minor gaps remain: no explicit read-only declaration, no error-handling notes for missing customers, and no handling of customers with fewer than two ordered SKUs.

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 already provides 100% parameter description coverage, including customer_id format variants (numeric vs. GID) and product_id's optional filtering purpose. The tool description reinforces the product_id usage with a query example but does not add new parameter-level semantics beyond what the schema already gives.

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: 'predict when a B2B customer / account is due to reorder.' It goes further to specify output granularity (per-SKU next-order dates), confidence based on cadence regularity, and concrete bucket labels ('overdue' / 'due_soon' / 'on_track' / 'not_predictable'), which clearly distinguishes it from sibling forecasting and recommendation tools like forecast_bundle or score_cross_sell.

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 supplies explicit trigger queries ('what's Acme Corp due to reorder?', 'when will customer X need more of Y?') and a broader use case ('show me stockout risks for my B2B accounts'), plus proactive replenishment. It also states supported backends and an explicit exclusion ('Not available on OroCommerce'), giving an agent clear when-to-use and 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?

With no annotations provided, the description carries the full behavioral burden and fully delivers: it discloses the returned bundle composition, cadence semantics, confidence range, monthly_value conditionality, customer_id blending behavior, fallback logic, and platform-specific limitations on OroCommerce. This gives the agent a clear picture of what happens under different inputs.

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 information-dense but every sentence earns its place: core purpose, output summary, explicit trigger phrases, behavioral fallback, and cross-platform caveats. It is front-loaded and avoids filler or repetition of schema details.

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

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

Given no output schema and no annotations, the description is remarkably complete. It explains what the tool returns, how the inputs affect behavior, when the output is approximate, and where the tool is unsupported. An agent has enough context to select and invoke this tool 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 100%, so the schema already documents all four parameters. The description adds valuable semantics beyond the schema, such as cadence snapping when cadence_days is supplied, the seed catalog cohesion fallback when customer_id is absent, and the monthly_value being reported 'when prices are known.' This is solid but not exhaustive extra meaning.

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: 'Propose a recurring subscription bundle for a customer based on their first-order items.' It further clarifies the input (1-5 seed products) and output (3-6 items, cadence, confidence, monthly value), making the tool's purpose unmistakable and distinct from sibling tools like predict_reorder or get_recommendations.

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 explicit when-to-use signals with concrete example queries ('what should they subscribe to?', 'propose a subscription bundle') and explains fallback behavior when customer_id is absent. It does not explicitly name alternative tools or state when not to use this tool, so it stops 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?

With no annotations provided, the description carries the full burden and delivers key behavioral detail: it returns confidence backed by real co-purchase data, and it returns a 'clear no signal' result when no qualifying rule exists. It doesn't discuss read-only guarantees or confidence scale, but the described fallback and data source cover the most important behavioral nuances for a scoring 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 front-loaded sentences with no waste: the first states the operation and output, the second gives usage and example questions. Every phrase earns its place, and the most important information appears 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?

There is no output schema, so the description must explain return behavior—it does, by promising either a confidence value or a no-signal result. It also covers usage scenarios. It doesn't specify the confidence format or scale, but for a simple two-parameter tool this is a minor gap rather than a completeness failure.

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 product_a and product_b clearly described as antecedent and consequent. The tool description adds little beyond that, only framing them as 'two specific products.' Baseline 3 is appropriate since the schema already documents the parameters fully.

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 ('score'), resource ('cross-sell strength between two specific products'), and explicitly distinguishes this pairwise scoring from other tasks by giving example questions ('is X a good cross-sell for Y?'). It clearly differentiates from siblings like find_substitutes or get_recommendations without needing to inspect their schemas.

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

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

It provides concrete usage context: 'Use this to validate a proposed pair before recommending it,' plus example queries that map to user intents. It doesn't explicitly mention when not to use it or name alternative tools, but the guidance is clear enough for an agent to select it for pair-level validation.

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 and does so well: it discloses that the composite rate is the max of item rates, that each item's historical return rate is included, that a low/medium/high recommendation is produced, and that it is backed by the merchant's real order and refund history. This goes well beyond a generic prediction description.

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 efficient and front-loaded: purpose, output, trigger phrases, and backing data each earn their place in three compact sentences. No filler or redundancy is present.

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, but the description fully covers what the agent should expect: composite bundle return rate, per-item historical rates, and a low/medium/high recommendation. Combined with the complete parameter schema and clear trigger examples, nothing essential is missing 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 description coverage is 100%, so the schema already fully documents product_ids and threshold, including the fixed low/medium/high bands and threshold override behavior. The description adds only contextual phrasing like 'candidate bundle' and '2-6 products', which does not meaningfully extend 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?

The description opens with a specific verb and resource: 'Predict return risk for a candidate bundle of 2-6 products.' It further distinguishes itself from siblings by focusing on return risk and bundle-level return rate, which is clearly different from forecast_bundle, score_cross_sell, or predict_reorder.

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 lists natural-language triggers and an agentic use case: verifying a bundle won't hurt return KPIs. It gives clear positive guidance but does not state when not to use the tool or name alternatives/exclusions, so it stops 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?

With no annotations provided, the description carries the behavioral disclosure burden. It clearly discloses that the operation is 'State-mutating,' guarded by confirm=true, and that archiving 'permanently retire[s]' an opportunity. It also warns about platform availability. It stops short of describing response format or failure modes, but the core behaviors are well covered.

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 compact and front-loaded with the core action, then expands with action semantics and platform context. Every sentence contributes useful information; there is 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?

For a state-changing tool with no annotations and no output schema, this provides essential context: mutation, confirmation guard, action semantics, permanence, and platform limitations. A small gap remains around expected response/return values, but the description is strong enough for an agent to invoke 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 100%, so the baseline is 3. The description adds real semantic value by explaining what each action means (activate publishes, pause hides, archive permanently retires) and reinforces the purpose of confirm. This goes beyond the schema's terse field 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 description names a specific verb set ('Pause, activate, or archive') and a specific resource ('a specific opportunity from get_opportunities'). It also differentiates the action types clearly, so an agent can distinguish this state-changing tool from read-only sibling tools like get_opportunities or explain_opportunity.

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 when to use the tool: 'after the merchant has explicitly picked an opportunity to act on.' It also gives platform-specific guidance, noting that on non-BigCommerce platforms the tool returns a not-available message. It does not explicitly list alternative tools, but the use context is sufficiently clear.

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