@marketbasketanalysis/mcp

propose_subscription_bundle

Generate a recurring subscription bundle from a customer's first-order items, returning predicted reorder cadence, confidence score, and monthly value. Use for 'what should they subscribe to?'.

Instructions

Propose a recurring subscription bundle for a customer based on their first-order items. Given 1-5 seed products the customer has bought, returns a recurring subscription bundle (3-6 items) of the seeds plus complementary products, with a predicted cadence (median days between reorders), a 0..1 confidence score, and a rough monthly_value when prices are known. Use this when a merchant agent asks 'what should they subscribe to?', 'build a monthly subscription bundle from this order', 'propose a subscription bundle', 'recommend a recurring replenishment bundle', or 'what's the right subscription frequency for this customer?'. If a customer_id is supplied the tool blends in the customer's per-SKU reorder cadence; without one it falls back to the seed catalog cohesion alone. Works for all five platforms: Shopify, BigCommerce, WooCommerce, Magento, and OroCommerce (the optional reorder-cadence blend needs a customer_id and is not available on OroCommerce).

Input Schema

TableJSON Schema

Name	Required	Description
`kit_size`	No	Target total items in the subscription bundle (seeds + complements). Default 4, clamped to [3, 6].
`customer_id`	No	Optional customer id (numeric storefront id or GID). When supplied, the tool pulls the customer's reorder-prediction history to anchor the cadence and confidence. Without this, the proposal uses seed-only catalog cohesion.
`cadence_days`	No	Optional target subscription frequency in days (e.g. 30 for monthly, 14 for biweekly). When supplied, the tool snaps the predicted cadence toward this target and weights candidates whose individual cadences are close to it.
`seed_product_ids`	Yes	Products the customer bought in their first order (1-5). The proposed subscription bundle will include these plus complementary items.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.7.0Aug 28, 2026

TDQS

A4.7/5.0

Behavior5/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

propose_subscription_bundle

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools