botx402

Start a paid Inventory Reorder Snapshot run ($19.00, card checkout)

start_inventory_reorder

Start a paid Inventory Reorder Snapshot run ($19.00 per run). This tool never charges anyone; it returns a Stripe checkout link that a person opens and pays. It creates the checkout and returns the link with a receipt_id and access_token. Nothing runs until the person pays on Stripe's page. Show the user the link and the price and ask them to pay; then call get_run with the receipt_id and access_token. Results are also emailed to the address given. Takes the same JSON as validate_inventory_reorder_inputs ({"inputs": {...}, "email": "..."}); run validate_inventory_reorder_inputs first, since invalid inputs are rejected here too. Each call creates a new checkout, so do not retry a call that succeeded.

Returns: A PDF report and a JSON plan: one row per SKU (status, order quantity, days of cover, cash tied up) plus summary totals.

Turns a store's per-SKU sales history, stock on hand, open purchase orders and supplier lead times into a reorder plan: which SKUs to reorder now and how many units (rounded up to MOQ and case pack), which are out of stock or will run out before the next delivery could arrive, which are overstocked or not selling, how much cash is tied up in excess stock, and which SKUs earn the revenue (ABC tiers).

It is rule-based and deterministic, computed only from the figures supplied. It is not a forecast: it does not model seasonality, trend or promotions, multiple locations, variant roll-ups, supplier price breaks or margin. It does not connect to Shopify or any other system; the data is sent inline.

Inputs: an as_of date, an optional window_days (28 to 365, default 90) that units_sold covers, and 1 to 800 SKUs, each with sku, units_sold, on_hand, unit_price and unit_cost. lead_time_days is needed per SKU or in defaults. The whole request must stay under 200 KB.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`email`	Yes	The buyer's email: Stripe sends the payment receipt there and botx402 emails the results link.
`inputs`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 4, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Annotations declare readOnlyHint=false, idempotentHint=false, openWorldHint=true and destructiveHint=false; the description corroborates and enriches this by clarifying the tool never charges anyone, returns a Stripe checkout link, produces receipt_id/access_token, emails results, and that each call creates a new non-idempotent checkout. That is substantive behavior 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.

Conciseness4/5

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

Front-loads the critical payment/no-charge fact and the link flow, then the return contents, then the computation scope. It is on the long side and the 'rule-based, not a forecast' enumeration is dense, but each block carries needed information for a paid, no-output-schema tool.

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?

Covers the full picture an agent needs: pricing, payment flow, downstream get_run call, validation prerequisite, input format and size limits, and what the returned report/plan contains. With no output schema, the description carries the return-value burden and does so adequately.

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

Parameters5/5

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

With only 50% schema coverage on 2 top-level params, the description compensates well: it says inputs takes the same JSON as validate_inventory_reorder_inputs, enumerates as_of, window_days (28–365, default 90), 1–800 SKUs with required per-SKU fields, lead_time_days in defaults, and the 200 KB request limit. This adds constraints and usage semantics the schema alone does not convey.

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?

States a specific verb and resource ('Start a paid Inventory Reorder Snapshot run') with the price and mechanism in the title/description. It is clearly distinguishable from the sibling validate_inventory_reorder_inputs (validation only) and get_run (fetch results). An agent can tell what this tool does without opening the schema.

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

Usage Guidelines5/5

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

Gives an explicit ordered workflow: run validate_inventory_reorder_inputs first, show the user the link and price, then call get_run with receipt_id and access_token. It also adds a when-not rule ('do not retry a call that succeeded') and clarifies nothing runs until payment, leaving nothing to inference.

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

All botx402 tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?