Inventory reorder plans from SKU sales, stock and lead times. $19 a run, paid by card.
Scored across 2 tools
get_run retrieves results for an existing run, while list_bots enumerates available bots and their schemas. These are clearly distinct read-only operations with no overlapping purpose, so an agent can easily tell them apart.
Both tools follow a consistent snake_case verb_noun pattern: get_run and list_bots. The convention is predictable and readable, matching the start_ and validate_ prefixes referenced in the descriptions.
Only two tools are exposed, which is too thin for a server whose own descriptions reference start_ and validate_ tools that are absent. An agent cannot initiate a run or validate inputs, so the surface does not earn its scope.
The descriptions explicitly mention start_ and validate_ tools that are not in the tool list, leaving no way to launch a run or validate inputs. The lifecycle is broken: list_bots exposes bots, but get_run can only be used after some missing start_ tool has run, making the surface severely incomplete.
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
start_inventory_reordervalidate_inventory_reorder_inputsget_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.
