Inventory reorder plans from SKU sales, stock and lead times. $19 a run, paid by card.
Scored across 4 tools
Each tool has a distinct role in the run lifecycle: list_bots for discovery, validate_inventory_reorder_inputs for free pre-flight checks, start_inventory_reorder to initiate a paid run, and get_run to poll results. validate and start share the same input shape, but their descriptions clearly separate free validation from paid initiation.
All names follow lower snake_case with a verb-first pattern (get_run, list_bots, start_inventory_reorder, validate_inventory_reorder_inputs). The bot-specific tools consistently share the inventory_reorder prefix, while the generic tools use clear verbs.
Four tools neatly cover the discover-validate-start-retrieve lifecycle for a paid bot run. No tool feels redundant, and the set is well-scoped for the server's narrow purpose.
The core workflow from bot discovery through payment to result retrieval is fully covered. Minor gaps exist (e.g., no way to cancel a run or list past runs), but these are reasonable given the focused paid-run model.
Check a run started with a start_ tool and fetch its results. Needs the receipt_id AND the access_token that start_ returned: the token is the proof that the caller started the run, and without it nothing is returned. Status is awaiting_payment (the user has not paid yet), running, completed or failed. When completed, structuredContent.result is the bot's full JSON result, ready to act on, and pdf_url links the PDF report (presigned, expires after 7 days). Free and read-only; poll about once a minute.
| Name | Required | Description | Default |
|---|---|---|---|
| receipt_id | Yes | receipt_id from start_<bot>, like RG-202610-1A2B3C4D. | |
| access_token | Yes | access_token from start_<bot>. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only/idempotent/no-destructive safety, and the description adds substantial context beyond them: the access_token is required as proof of ownership and yields nothing without it, the four status values, and that completed runs return structuredContent.result plus a presigned pdf_url that expires in 7 days.
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?
Dense but front-loaded and waste-free: the core action, the required credentials, the status enum, the return payload, and the polling cadence each appear once and in a logical order.
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 separate output schema, the description carries the return-value burden and does so (structuredContent.result JSON, pdf_url with expiry). Together with the prerequisite and polling guidance, an agent has everything needed to call and interpret 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 baseline is 3, but the description adds real meaning: the access_token is not just an ID but an authorization proof the caller started the run, and the receipt_id format/provenance is clarified via the start_<bot> link.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Check a run started with a start_ tool and fetch its results') and ties itself explicitly to the start_<bot> family, which cleanly separates it from siblings list_bots and validate_inventory_reorder_inputs.
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 clear usage context: call it after a start_ tool, and poll about once a minute. The prerequisite chain (receipt_id and access_token come from start_) is spelled out. No explicit when-not or named alternative retrieval 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.
List the bots this server can run: what each one does, its price per run, what a run returns, its input schema, and the names of its validate_ and start_ tools. Free and read-only.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false. The description adds genuinely new context beyond those: 'Free' (no cost per call) and the fact that it surfaces per-bot pricing and tool names, which tells the agent this is a zero-cost discovery call. It stops short of describing output format or pagination.
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?
A single front-loaded sentence that packs the resource, the enumerated return contents, and the cost/safety profile with no filler. 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 output schema, the description carries the burden of explaining what is returned, and it does so explicitly (per-bot description, price per run, return shape, input schema, validate_/start_ tool names). Combined with annotations covering safety, an agent has everything needed 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?
The tool takes zero parameters, which is the baseline-4 case; there is nothing for the description to disambiguate. The description correctly implies no input is required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (List) and resource (bots this server can run), and goes further by enumerating exactly what each entry contains (behavior, price, return shape, input schema, sibling tool names). This clearly distinguishes it from the per-bot get_run/validate_/start_ 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 implies this is the discovery/entry-point tool that precedes the validate_/start_ siblings, and 'Free and read-only' hints at when it is safe to call. However, it never explicitly says when to use this versus the sibling tools or states any prerequisites, so usage is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | The buyer's email: Stripe sends the payment receipt there and botx402 emails the results link. | ||
| inputs | Yes |
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.
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.
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.
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.
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.
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.
Check inputs for Inventory Reorder Snapshot before asking a human to pay. Free; nothing is charged, stored or run. Takes exactly the JSON start_inventory_reorder takes: {"inputs": {...}}, plus "email" if you have it (checked too, optional here). Returns either valid (with a one-line summary of what will be analysed) or every problem found at once, each with its path (e.g. inputs.skus[2].unit_cost) and how to fix it. Fix them all, call again, then call start_inventory_reorder with the same JSON plus the buyer's email.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| No | The buyer's email: Stripe sends the payment receipt there and botx402 emails the results link. | ||
| inputs | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description still adds meaningful context beyond them: 'nothing is charged, stored or run', that it is deterministic/rule-based and not a forecast, that it does not connect to Shopify, and that it returns either valid or every problem at once. That is genuine added disclosure, though a lot of it describes the downstream analysis rather than this tool's own behavior.
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 lead sentence is front-loaded with the essential distinction (free, nothing charged, exact input shape) and the error-path example is compact and actionable. The middle paragraph describing what the reorder analysis produces is arguably padding for a pure validator, but it justifies what 'valid' means, so the length is defensible rather than wasteful.
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 carry the return contract, and it does: valid plus a one-line summary, or every problem with a path such as inputs.skus[2].unit_cost and a fix. Combined with the input-shape aliasing to start_inventory_reorder and the size limits, an agent has everything needed to call it 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 description coverage is only 50%, but the description compensates by naming the container shape ({"inputs": {...}} plus optional email), the required SKU fields, the 1-800 SKU bound, the 28-365 window_days default of 90, the requirement that lead_time_days appear per SKU or in defaults, and the 200 KB request limit (which the schema does not state). It omits meaning for several optional per-SKU fields (moq, order_multiple, days_out_of_stock, safety_days, target_cover_days), which the schema does describe, so the gap is closed just well enough for a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('Check inputs for Inventory Reorder Snapshot') and immediately scopes it as a free pre-flight step before payment. It explicitly contrasts with the sibling start_inventory_reorder by describing itself as the validation that precedes it and pointing the agent to the follow-up call.
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 workflow: call this, fix every reported error, call again, then call start_inventory_reorder with the same JSON plus the buyer's email. No alternative routing is left to inference, and it explains the return contract (valid vs. all problems).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_runlist_botsstart_inventory_reordervalidate_inventory_reorder_inputsFind the cash trapped in your inventory, then size reorder points, safety stock and EOQ.
Safety-stock & reorder planning, FBA-vs-FBM decision, and inventory health audit for sellers
Inventory, restock planning, and sales analytics for your Amazon FBA business.
Read-only supply-chain decision support: forecasting, reorder policies, ABC-XYZ, data quality.
Add one secure layer between your agents and this server.
