Manage inventory and sales opportunities

On this page you can review your FBA inventory status to build the basis for restock and cleanup decisions, and weigh whether to dial ads up or down based on inventory status. From identifying stockout risk to detecting overstock and creating a replenishment order brief, use it to streamline the inventory work that sits right next to ad operations.

About this page

Item	Details
What you can do	List FBA inventory and check weeks of cover, diagnose stockout risk and create a replenishment order brief, detect overstock and slow-moving inventory, consider ad adjustments based on inventory status, and understand lost opportunities from Subscribe & Save stockouts
Applies to	FBA inventory (fulfillable inventory / inbound working inventory / weekly shipment pace / weeks of cover) and Subscribe & Save (SnS) performance data
Data & connection needed	Inventory data and Subscribe & Save performance data for the connected account (no additional setup)
Scope	Mostly analysis and proposals only (read-only). Actual ordering and shipment-plan creation are done manually in Seller Central, and Picaro never places orders. Only the inventory-aware ad adjustment (Prompt 4) hands its proposals to the approval flow of the related pages (bids / budgets) for execution. Each prompt states its own in “Changes”

Do not use needMoreStocks as a recommended restock quantity or a shortfall. It returns the same value as the current inventory quantity (sellableInventory), so it is no basis for a restock amount. For the recommended restock quantity, use the values the tools return, such as reorderQuantitySuggested.
A “0” in weeks of cover or days of cover (weeksOfCover / daysOfSupply) does not necessarily mean a stockout. 0 is also returned when weekly shipments are 0 even though there is inventory, so always distinguish “a stockout with zero inventory,” “cannot be calculated because weekly shipments are 0 (slow-moving, dormant, and so on),” and “data not retrieved.”
For inventory-aware ad adjustment, aggregate the inventory data to ASIN level before assessing. Assessing SKU-level rows as they come would produce proposals that wrongly hold back ads for products that in fact have plenty of stock (this has been observed in practice). Exclude products with 0 weekly shipments from the hold-back candidates as “cannot assess,” and never treat a case with a denominator of 0 as “0 days of cover.”

FBA (Fulfillment by Amazon) … a system where you store inventory in Amazon’s warehouses and Amazon handles storage, shipping, and customer support on your behalf.
SKU … the smallest unit of code for managing a product. Even for the same ASIN, SKUs can differ by listing condition.
weeks of cover … an estimate of how many more weeks the fulfillable inventory lasts at the current weekly shipment pace (fulfillable inventory ÷ weekly shipment pace).
days of cover … the same idea as weeks of cover, expressed in days.
lead time … the number of days from placing an order until stock becomes sellable.
safety stock … the buffer inventory you hold against demand swings and inbound delays (specified in days).
Subscribe & Save (SnS) … Amazon’s system where shoppers register recurring purchases and receive them regularly at a discount.

When to use this

You want to grasp the full FBA inventory picture at a glance, with weeks of cover
You want to diagnose stockout risk and compile a replenishment order brief you can take straight into ordering review
You want to find overstock and slow-moving inventory to use as input for sell-through actions or listing cleanup
You want to decide whether to dial ads up or down (hold back / maintain / reinforce) according to inventory status
You want to understand lost opportunities from Subscribe & Save (SnS) stockouts and factor them into restock priority

Before you run

Connected account … if you handle multiple accounts, confirm the target account is correct first.
Lead time / safety stock / order cycle … these are the basis for the stockout-risk diagnosis (Prompt 2). Specify them to match your actual procurement and inbound reality.
Overstock threshold … used in the slow-moving inventory assessment (Prompt 3). Defaults are “over 180 days = overstock candidate” and “over 270 days = long-term storage fee warning,” and you can change them to fit your product’s turnover profile.
Picaro does not place orders … restock and order execution is done manually via shipment-plan creation in Seller Central.

Prompt quick reference

What you want to do	What you learn / what gets created	Changes	Prompt
Check the full FBA inventory picture with weeks of cover	An inventory list with weeks of cover	No change	Prompt 1
Diagnose stockout risk and create a replenishment order brief	A bucketed table of urgent restock / order candidate / watch / cannot assess, plus an order brief with an overstock list	No change (draft only)	Prompt 2
Find overstock and slow-moving inventory	A list of overstock / long-term storage warnings	No change	Prompt 3
Decide whether to dial ads up or down based on inventory	A list of hold back / maintain / reinforce recommendations	No change (proposal only; execution via the bid / budget categories)	Prompt 4
Understand lost opportunities from Subscribe & Save stockouts	A list of undelivered-due-to-stockout and worsening products	No change	Prompt 5

Prompt 1: See the full FBA inventory picture (with weeks of cover)

Review FBA inventory in one list. Beyond fulfillable inventory, it lines up inbound working inventory, weekly shipment pace, and weeks of cover (how many more weeks the stock lasts at the current pace) so you can grasp the full picture.

When to use — when you want to grasp the full inventory picture at a glance, with weeks of cover.

What you need — none (use as is). Specify the weeks-of-cover threshold (default is 2 weeks) if you want to change it.

Goal: to catch stockout risk early, make the whole FBA inventory of {{ACCOUNT_NAME (e.g. Torani)}} visible.

[Retrieval] Call get_fba_inventory with account_id specified and retrieve every page up to pagination.totalPages. Reconcile the number of rows returned against pagination.totalRecords, and state it explicitly if they do not match (page_size may be pinned to 100 even when you specify it). Always write coveragePeriod and dataCreateDate from the response at the top (this is the aggregation period for the weekly shipments that form the denominator of weeks of cover, so never present weeks of cover without stating the period).

[Aggregate to ASIN level] The same ASIN can come back in multiple rows (they are SKU-level rows, but the response has no SKU column, so rows cannot be matched to SKUs). Always aggregate to ASIN level before assessing.
- Sum fulfillable inventory and inbound working inventory within the ASIN
- Weekly shipments (weeklyShipmentUnits) is an ASIN-level value that appears identically on every row of the same ASIN, so do not sum it; take a single representative value
- Recompute the aggregated weeks of cover = (ASIN total fulfillable inventory) ÷ (weekly shipments), and show the row-level weeksOfCover that MCP returns alongside it as a reference value
* If you assess row by row without aggregating, you will look only at a zero-inventory SKU row and misjudge it as a "stockout" (the ASIN total may in fact have plenty of inventory).

[Handling weeks of cover = 0 — required] weeksOfCover=0 mixes together cases that mean different things. Do not treat 0 uniformly as "close to a stockout." Always split the output into these three buckets.
A. Needs action (stockout risk) … weekly shipments > 0 and aggregated weeks of cover < {{THRESHOLD (e.g. 2 weeks)}}. If the ASIN total inventory is 0, state "complete stockout" explicitly
B. Cannot be calculated (denominator 0) … weekly shipments = 0. Write weeks of cover as "cannot be calculated," not as 0. Further:
   B-1 has inventory, 0 shipments → slow-moving (an overstock-side question; hand it to Prompt 3, "Identify overstock and slow-moving inventory")
   B-2 0 inventory, 0 shipments → a candidate for dormant / discontinued / not listed
C. Healthy … aggregated weeks of cover >= {{THRESHOLD (e.g. 2 weeks)}}
Always distinguish "zero inventory (stockout)," "zero sales," and "inventory data not retrieved," and never conflate them.

[Output] Lead with bucket A and, in ascending order of aggregated weeks of cover, lay out ASIN, product name, fulfillable inventory, inbound working inventory, weekly shipment pace, aggregated weeks of cover, and bucket in a table. For buckets B and C, show the counts and representative examples.
Note: fulfillable inventory (sellableInventory) is a total that already includes inbound working inventory, so state explicitly that weeks of cover is a figure with inbound arrivals factored in.
Note: the get_fba_inventory response has no SKU column. Fill SKUs in with lookup_sku_for_asin only when they are needed; annotate ASINs that cannot be filled in as "SKU not registered," and, because rows cannot be matched to SKUs, annotate that as "SKU not shown (API specification)."
Note: do not use needMoreStocks as a recommended restock quantity (it returns the same value as the inventory quantity, so it is no basis for a restock amount).

Finally, output these three points.
1. Recommended action — state the priority, the reason, and the expected risk (stockout, lost opportunity) for bucket A. Base priority on fewest weeks of cover first, but weight it by both weeks of cover and shipment pace, since an ASIN with a small weekly shipment pace has little impact even if it runs out
2. How to execute — hand the bucket A ASINs to Prompt 2 (FBA inventory risk diagnosis) to confirm restock quantities. Send bucket B-1 to Prompt 3 (Identify overstock and slow-moving inventory)
3. Measurement — on {{REVIEW_DATE (e.g. 7 days later)}}, retrieve weeks of cover again and check whether the number of bucket A items rose or fell

Even when bucket A has zero items, state "0 items found" explicitly, and check the bucket B count and the data retrieval status (totalRecords, coveragePeriod) before concluding that the actuals are zero.

What you can change — the weeks-of-cover threshold (e.g. 2 weeks) / the review date for re-checking (e.g. 7 days later).

What you get back — a table of ASIN × product name × fulfillable inventory × inbound working inventory × weekly shipment pace × aggregated weeks of cover, ordered needs action → cannot be calculated → healthy. Weeks of cover is an estimate of “fulfillable inventory ÷ weekly shipment pace,” with inbound arrivals factored in. ASINs with 0 weekly shipments are set apart as “cannot be calculated” and their weeks of cover is not shown as 0. SKUs are not shown by default and are filled in individually only when needed.

Changes — no change (read-only).

Next steps — for the ASINs in the needs-action bucket, diagnose stockout risk with Prompt 2. For those that have inventory but whose shipments have stopped (bucket B-1), check them as overstock or slow-moving inventory with Prompt 3.

Prompt 2: FBA inventory risk diagnosis (stockout risk and recommended restock quantity)

Diagnose stockout risk, recommended restock quantity, and overstock by ASIN in one pass, and produce a replenishment order brief you can take straight into an ordering decision. Use it to prevent both lost sales from stockouts and the cost of over-ordering.

When to use — when you want to diagnose stockout risk and compile a replenishment order brief you can take straight into ordering review.

What you need — lead time (days from placing an order until stock becomes sellable; 14 days in the example), safety-stock days (buffer for demand swings and inbound delays; 7 days in the example), and order-cycle days (14 days in the example). Adding an overstock threshold and a minimum order lot (e.g. 100 units) improves the accuracy of the assessment and of the order/no-order call.

Goal: To prevent both lost sales from stockouts and the cost of over-ordering, diagnose stockout risk, recommended restock quantity, and overstock by ASIN in one pass from the FBA inventory of {{ACCOUNT_NAME (e.g. Torani)}}, and produce a replenishment order brief that can be used directly for an ordering decision.

[How to frame this diagnosis]
- Business Objective … prevent both lost sales from stockouts and the cost of over-ordering, and place appropriately sized replenishment orders.
- User Decision … decide "which ASINs, and how many units" to order in this order cycle (also state explicitly, with reasons, the ASINs you are not ordering or are putting on hold).
- Expected Outcome … a state where the list of ASINs to order with recommended restock quantities, the ASINs whose orders are on hold and why, and the ASINs to watch on the overstock side are all available in one pass, with no follow-up questions needed.
- Guardrail KPI … overstock cost / order lot efficiency. Storage fee and long-term storage fee amounts cannot be retrieved from Picaro MCP, so monitor them by proxy using days of cover, days over threshold, and ltsfRisk (warning/watch), and do not convert to monetary amounts.

[Retrieval] Call the following two with account_id specified.
1. detect_restock_needs (lead_time_days={{LEAD_TIME_DAYS (e.g. 14)}} / safety_stock_days={{SAFETY_STOCK_DAYS (e.g. 7)}} / reorder_cycle_days={{REORDER_CYCLE_DAYS (e.g. 14)}} / max_pages=10 / include_low_confidence=true)
2. detect_overstock (same account_id / max_pages=10. Leave thresholds at their defaults, or specify {{OVERSTOCK_THRESHOLD_DAYS (e.g. 180)}})
Do not use generate_restock_brief. It returns the same data as detect_restock_needs for critical / reorder / monitor and as detect_overstock for overstock, but it does not return the total-count field (equivalent to totalSkusEvaluated) or the idle detail array (idleItems), which makes the count reconciliation below and the separation of idle SKUs impossible.
include_low_confidence=true is required. With false, idle disappears from summary as well, the sum of the bucket counts no longer matches totalSkusEvaluated, and the excluded count is not shown either.
Check that thresholds in the response matches the values you specified, reconcile totalSkusEvaluated from both tools against pagination.totalRecords from get_fba_inventory, and state at the top whether all records could be evaluated. Also write salesDateRange (the aggregation period for weekly shipments) and inventoryCreatedAt (the inventory snapshot date) at the top.

[Aggregate to ASIN level — required] detect_restock_needs returns SKU-level rows but the response has no SKU column, and the same ASIN appears in multiple rows and multiple buckets at once (a row with zero inventory lands in critical while a row with inventory lands in monitor). Always aggregate to ASIN level before assessing.
- Sum sellableInventory and inboundWorkingQuantity within the ASIN
- weeklyShipmentUnits, reorderPointUnits, and targetStockUnits are ASIN-level values that appear identically on every row of the same ASIN, so do not sum them; take a single representative value
- Recompute the aggregated recommended restock quantity = max(0, targetStockUnits − (ASIN total sellableInventory + ASIN total inboundWorkingQuantity))
- Recompute the aggregated days until stockout = (ASIN total sellableInventory ÷ weeklyShipmentUnits) × 7, and show the row-level daysUntilStockout alongside it as a reference value
- For ASINs that drop out of urgent restock or order candidate as a result of aggregation, exclude them as "another row of the same ASIN has inventory; no order needed," and always state the excluded count and quantity
* If you handle rows without aggregating, you will look only at the zero-inventory SKU row and misclassify it as "urgent restock," over-ordering for ASINs that actually have plenty of stock (in verification, 2 of 5 urgent-restock items were false positives, amounting to roughly 14,000 units of over-ordering).

[Distinguishing 0 from null — required] weeksOfCover / daysOfSupply return 0 when weekly shipments are 0 even if there is inventory, so always break "0" down into these three cases.
- Case A, stockout with zero inventory … sellableInventory = 0. An actual stockout. Subject to urgent restock
- Case B, cannot be calculated because weekly shipments are 0 … weeklyShipmentUnits = 0 (daysUntilStockout comes back as null). It merely returns 0 despite having inventory; this is not a stockout. Place it in Idle as slow-moving, dormant, or discontinued, and do not write "0 days until stockout"
- Case C, healthy … both inventory and shipments exist, and days of cover can be calculated
Do not use weeksOfCover / daysOfSupply on their own as evidence of a stockout.
Do not use needMoreStocks (in every SKU verified it was identical to sellableInventory; it is not a recommended restock quantity). For the recommended restock quantity, use reorderQuantitySuggested (when aggregating to ASIN level, the value recomputed with the formula above).
Always distinguish "zero inventory (complete stockout)," "zero sales (cannot be calculated)," and "data not retrieved."

[Buckets] Treat classification from detect_restock_needs as the primary bucket, and demote to Monitor any ASIN that no longer meets the Critical conditions after ASIN aggregation. Do not reclassify on day counts alone (Reorder includes the case "days of cover remain, but fulfillable inventory + inbound working inventory is below target stock," and cutting on a day-count threshold would drop order candidates).
- 🔴 Urgent restock (critical) … fulfillable inventory is at or below the reorder point and there is no inbound working inventory / days of cover is at or below lead time
- 🟡 Order candidate (reorder) … fulfillable inventory + inbound working inventory is below target stock
- 🟢 Watch (monitor) … target stock is met
- ⚪ Cannot assess / idle (idle) … no recent shipments, cannot be assessed (confidence=low, Case B above)
Overstock (detect_overstock) is a separate axis, orthogonal to the restock classification. Show it in its own table rather than adding it to the four buckets above, and note that a plain sum of the bucket counts includes duplicates.

[Identifying SKUs] For each 🔴 and 🟡 ASIN, look up the SKU with lookup_sku_for_asin and show it in a SKU column.
If **multiple different** SKUs are returned for one ASIN, sellableInventory for each SKU holds the ASIN total and cannot be split per SKU, so state "SKU cannot be identified — check the inventory management screen" and do not finalize an order quantity for that SKU. If the same SKU name is merely returned more than once under different parentAsin values (that is, deduplication leaves one entry), this does not count as "cannot be identified." Deduplicate before assessing.

[Output] First show the restock side in per-bucket tables, then show overstock in a separate table.
- Restock-side columns … product name, ASIN, SKU (only when it could be identified), aggregated days until stockout, fulfillable inventory, inbound working inventory, weekly shipments, recommended restock quantity, confidence, reason for the assessment
- Overstock-side columns … product name, ASIN, days of cover, days over threshold, fulfillable inventory, ltsfRisk (warning/watch)
For items whose bucket changed through ASIN aggregation, note "Critical before aggregation → Monitor after aggregation (false positive from SKU row splitting)."

[Order brief] Following the tables above, summarize in these five parts.
1. What happened — the counts and scale of urgent restock, order candidates, and overstock. Show both the post-ASIN-aggregation values and the raw pre-aggregation counts
2. Why — the drivers of stockouts / overstock. However, the sales data is only a snapshot of the most recent week with no time series, so changes in shipment pace and seasonality cannot be determined. State that this cannot be assessed, and do not assert conclusions from speculation
3. So what — the stockout risk and overstock risk of leaving this alone. Do not convert to monetary amounts; go only as far as days of cover, days over threshold, and ltsfRisk
4. What was done — orders placed since the previous brief. No MCP tool returns order history, so unless the user provides it, state "awaiting user input" (do not assert "none")
5. What should we do next — the ASINs to order this time and their priority

[Data quality] Always observe the following, and treat the reconciliation results as required output items.
- Reconcile whether the sum of the bucket counts (critical + reorder + monitor + idle) matches totalSkusEvaluated, and if it does not, state the difference in count and the reason (SKUs whose weekly shipments are below min_weekly_units are excluded by default / the include_low_confidence setting, and so on)
- If totalSkusEvaluated does not match totalRecords from get_fba_inventory, or if the run was cut short by max_pages, state the total count, the number confirmed, and the number unconfirmed (if [N of M rows omitted] appears, state "⚠️ only Y of X records retrieved" at the top)
- Do not include unretrieved SKUs in the tables; note separately that "the remaining N records were not retrieved," and do not assert speculation such as "presumably equally urgent" (write unretrieved items as "unknown because not retrieved")
- Back-calculating or fabricating individual ASIN or individual SKU values from aggregates (totals over N rows) is prohibited. List only the rows actually retrieved

At the end of your answer, state the assumptions used (lead time, safety stock, order cycle, overstock threshold, inventory snapshot date, and sales data period), and note that Picaro's data does not exactly match the values shown on the FBA inventory management screen and that final confirmation should be done on that screen.

Finally, output these three points.
1. Recommended action — among urgent restock and order candidates, present those whose recommended restock quantity is at least {{MINIMUM_ORDER_LOT (e.g. 100 units. Order lot, MOQ, and case pack do not exist in any Picaro MCP response, so the user specifies them)}} as "ASINs to order in this order cycle," sorted by days until stockout ascending and recommended restock quantity descending. If no minimum order lot is specified, state "not specified, so no order/no-order call is made," do not round to order units (state "order unit requires user confirmation"), and show only the list of recommended restock quantities. List separately, as "SKU confirmation required," any ASIN whose SKU could not be uniquely identified, and do not finalize its order quantity
2. How to execute — hand the list over as the basis for ordering (there is no order execution path inside Picaro, so ordering is manual)
3. Measurement — on {{REVIEW_DATE (e.g. 7 days later)}}, retrieve detect_restock_needs again with the same assumptions and check whether the ASINs judged urgent restock have dropped out of critical (and whether any new stockouts have occurred). Do not judge recovery by weeksOfCover / daysOfSupply (they also return 0 when weekly shipments fall to 0, which would be misread as recovery). If they have not recovered, suspect an order delay and investigate

What you can change — lead time (e.g. 14 days) / safety-stock days (e.g. 7 days) / order-cycle days (e.g. 14 days) / overstock threshold / minimum order lot. Adjust them to your actual procurement and inbound reality.

What you get back — a table of bucket (🔴 urgent restock / 🟡 order candidate / 🟢 watch / ⚪ cannot assess or idle) × ASIN × SKU (only when it could be identified) × days until stockout × fulfillable inventory × inbound working inventory × weekly shipments × recommended restock quantity, a separate overstock table, and a five-part replenishment order brief structured as What happened / Why / So what / What was done / What should we do next. This is draft generation only; no actual ordering or external sending is performed.

Changes — analysis and proposal only (draft generation only). No orders are placed.

Next steps — execute orders via shipment-plan creation in Seller Central. To dig deeper into the overstock side, use Prompt 3 (Identify overstock and slow-moving inventory).

Prompt 3: Identify overstock and slow-moving inventory

Detect SKUs whose estimated days of cover exceed a threshold as overstock candidates. Inventory that sits too long increases storage-fee load, so this becomes input for decisions on discounts, ad reinforcement, or listing cleanup.

When to use — when you want to find slow-moving inventory to use as input for sell-through actions or listing cleanup.

What you need — none (use as is). Default thresholds are “over 180 days = overstock candidate” and “over 270 days = long-term storage fee warning.”

Goal: to prevent long-term storage fees and wasted inventory cost, identify "overstock" and "slow-moving inventory" separately from the FBA inventory of {{ACCOUNT_NAME (e.g. Torani)}}. These two are distinct concepts (overstock = too much quantity / slow-moving = no movement).

[Retrieval]
1. Call detect_overstock with account_id specified (overstock_threshold_days={{OVERSTOCK_THRESHOLD_DAYS (e.g. 180)}} / ltsf_warning_days={{LTSF_WARNING_DAYS (e.g. 270)}} / max_pages=10).
2. Call get_fba_inventory with the same account_id and page_size=500, then look at pagination.totalPages in the response and retrieve every page. page_size is capped server-side (it may come back as 100) and the value you specify is not necessarily the one used, so always judge counts by pagination.totalRecords and totalPages.
Check that thresholds in the response matches the values you specified, reconcile totalSkusEvaluated from detect_overstock against pagination.totalRecords from get_fba_inventory, and state at the top whether all records could be evaluated.

[Stating the observation period — required] Always write salesDateRange (the aggregation period for weekly shipments) and inventoryCreatedAt at the top. salesDateRange currently only ever returns 7 days, and no parameter exists to specify the period. State explicitly that for SKUs with seasonality, extrapolating from a single week of shipments is distorted. Also check the ingestion status for each day of salesDateRange with get_data_ingestion_status. However, do not use the day-level rollup_status to judge finalization: if even one ad type has no delivery, the whole day falls to no_data even when every other report is completed. Open reports[] report by report and judge on whether the reports relevant to inventory and sales are completed, and if unfinalized days are included, state so.

[Assessing overstock] Use the output of detect_overstock.
- Long-term storage fee risk … ltsfRisk="warning" (estimated days of cover over {{LTSF_WARNING_DAYS}})
- Keep watching … ltsfRisk="watch" (between {{OVERSTOCK_THRESHOLD_DAYS}} and {{LTSF_WARNING_DAYS}})

[Assessing slow-moving inventory — required, and not retrievable from detect_overstock]
For SKUs whose weekly shipments are 0, detect_overstock returns 0 rather than null in daysOfSupply, so they always fall below the threshold and it structurally never returns a single zero-turnover SKU. Specifying min_weekly_units=0 does not change the result. Slow-moving inventory therefore has to be extracted by you from all the rows of get_fba_inventory.
- Slow-moving … weeklyShipmentUnits=0 and warehouseQuantity>0 (inventory on hand that is not moving)
- Effectively discontinued … weeklyShipmentUnits=0 and warehouseQuantity=0 (do not count as slow-moving inventory)

[Distinguishing 0 from null — required]
- A 0 in daysOfSupply / weeksOfCover comes back both for "a stockout with zero inventory" and for "cannot be calculated because weekly shipments are 0 (= slow-moving)." Always read warehouseQuantity alongside it to break this apart and state which one it is. Do not write "0 days of cover."
- needMoreStocks returns the same value as sellableInventory, so do not use it as a recommended restock quantity or a shortfall.
- Always distinguish "0 items found," "out of scope for evaluation (no shipment actuals, cannot be calculated)," and "data not retrieved." detect_overstock does not return the number of out-of-scope SKUs, so count them from get_fba_inventory and state it.

[Handling duplicate ASINs — required] get_fba_inventory returns SKU-level rows but the response has no SKU column, and the same ASIN appears in multiple rows. When reporting counts, write the number of rows (SKUs) and the number of ASINs separately. When SKU names are needed, try a reverse lookup with lookup_sku_for_asin, but this errors for ASINs that are not registered in Picaro's SKU master. Treat ASINs that could not be looked up as "SKU unknown," and do not fill in SKU names by guesswork. Also, the sellableInventory returned holds the ASIN total on every SKU, so summing across SKUs double-counts. Do not sum it.

[Limits of the metric — required] Estimated days of cover (daysOfSupply) is a forward-looking number of days needed to sell through the current inventory at the current sales velocity; it is not the storage age of the inventory that long-term storage fees are charged on. MCP has no field that returns inventory age, aged-inventory buckets, or the actual long-term storage fee amount. State at the end of your answer that this result is a proxy metric and that actual amounts should be confirmed in Seller Central's inventory health dashboard.

[Output] In separate tables for overstock (long-term storage fee risk / keep watching) and for slow-moving inventory, state product name, ASIN, estimated days of cover, weekly shipments, fulfillable inventory, inbound working inventory, and the reason for the assessment.

Finally, output these three points.
1. Recommended action — present, prioritized in descending order of quantity held: "sell through with promotion, a price cut, or ad reinforcement" for SKUs over {{LTSF_WARNING_DAYS}}, "keep watching" for {{OVERSTOCK_THRESHOLD_DAYS}} to {{LTSF_WARNING_DAYS}}, and "consider return, disposal, or markdown clearance" for slow-moving inventory
2. How to execute — for SKUs that need ad reinforcement, check ROAS with "cause diagnosis" first, then create a bid adjustment proposal and apply it only after the user has reviewed and approved it. Price cuts, returns, and disposal have no execution path inside Picaro, so state explicitly that they are done manually
3. Measurement — on {{REVIEW_DATE (e.g. 30 days later)}}, re-detect with the same parameters and check whether the number of SKUs with ltsfRisk="warning" and the number of ASINs with 0 weekly shipments but inventory on hand have fallen. At the same time, check that the sell-through actions have not caused stockouts, using the count in classificationSummary.critical from detect_restock_needs (the stockout rate itself cannot be retrieved from Picaro MCP, so check it in Seller Central; state that the critical count is a proxy for the stockout rate)

What you can change — the overstock and long-term storage warning thresholds (e.g. 180 days / 270 days) / the review date for re-detection (e.g. 30 days later). You can change them to fit your product’s turnover profile.

What you get back — a table of overstock (long-term storage fee risk / keep watching) and a separate table of slow-moving inventory (products whose shipments have stopped while stock remains), each with product name, ASIN, estimated days of cover, weekly shipments, fulfillable inventory, inbound working inventory, and the reason for the assessment. Overstock (too much quantity) and slow-moving inventory (no movement) are handled as distinct concepts.

Changes — analysis and proposal only (read-only).

Next steps — to consider sell-through via ads (ad reinforcement, discounts), combine with Adjust bids.

Prompt 4: Consider ad adjustments based on inventory status

Continuing to pour ad spend into ASINs at stockout risk degrades ad efficiency the moment they run out. Conversely, ASINs with inventory headroom have room for ad reinforcement. This prompt cross-references inventory with ad performance and proposes adjustment candidates.

When to use — when you want to decide whether to dial ads up or down (hold back / maintain / reinforce) according to inventory status.

What you need — none (use as is). Specify the lead time and safety-stock days for the inventory risk assessment, or the minimum ROAS for reinforcement, if you want to change them.

Goal: to stop wasting ad spend during stockouts while maximizing the sales opportunity of products
with inventory headroom, identify the stockout-risk ASINs of {{ACCOUNT_NAME (e.g. Torani)}} and line
them up with those ASINs' ad performance.

[Inventory-side retrieval — aggregation to ASIN level is required]
1. Retrieve inventory risk with detect_restock_needs (lead_time_days={{LEAD_TIME_DAYS (e.g. 14)}} /
   safety_stock_days={{SAFETY_STOCK_DAYS (e.g. 7)}} / max_pages=10 / include_low_confidence=true).
   State the total count (totalSkusEvaluated), the per-bucket counts, the inventory snapshot date, and
   the aggregation period for weekly shipments at the top.
2. This tool returns SKU-level rows, and the same ASIN appears in multiple rows and multiple buckets at
   once (a row with zero inventory lands in urgent restock while a row with inventory lands in watch).
   Always aggregate to ASIN level before assessing.
   - Sum sellableInventory and inboundWorkingQuantity within the ASIN
   - Demote to watch any ASIN that no longer meets the urgent-restock conditions after aggregation, and
     state the excluded count
   - If you handle rows without aggregating, you will look only at the zero-inventory SKU row and
     misjudge it as "urgent restock," producing the opposite proposal — holding back ads for a core
     product that in fact has plenty of stock. This has been observed in practice
3. Set aside rows with weeklyShipmentUnits = 0 as "cannot assess (slow-moving, dormant, discontinued),"
   exclude them from the hold-back candidates, and list them separately.
   weeksOfCover / daysOfSupply return 0 when weekly shipments are 0 even if there is inventory, so do not
   use them on their own as evidence of a stockout. Always distinguish "a stockout with zero inventory,"
   "cannot be calculated because weekly shipments are 0," and "data not retrieved."
4. Do not use needMoreStocks (it is identical to sellableInventory and is not a recommended restock
   quantity).

[Ad-side retrieval — take it on the ASIN axis]
5. For each target ASIN, retrieve the ad performance attributed to that ASIN on the ASIN axis.
   Calling POST /product-analysis/product-detail/ad with call_picaro_api
   (body: amazon_account_id, from_date, to_date, code=target ASIN, type="asin")
   returns that ASIN's ad spend, ad sales, ROAS, ACoS, CVR, and CPC, both as a per-campaign breakdown
   and as a total.
   - Use ads_spend / ads_sales / roas / acos in the total block as the ASIN-level values
   - Use campaign_id / campaign_name / campaign_type in items[] to identify the campaigns running that ASIN
   - Show ads_sales_same_sku (sales from the same SKU) and ads_sales (including halo) as distinct figures
   - Reconcile pagination.total_count against the number of items and state whether everything was retrieved
   - End the period on the finalized day confirmed with get_data_ingestion_status; do not include today
6. For ASINs with no ad spend, write "no ad performance," and keep 0 distinct from not retrievable.
7. Use the returned ROAS and ACoS as-is; do not recalculate them yourself.
   Reconcile whether the per-campaign breakdown sums to the total, and state the difference if it does not.

[Guardrails] State how the inventory data and the ad data were retrieved, and disclose it if you switched
methods partway through.
Do not call any write tools (bid or budget changes) whatsoever.

Finally, output these three points.
1. Recommended action — present the ASINs that fall under urgent restock or order candidate after ASIN
   aggregation and that are incurring ad spend as "consider holding back," in ascending order of days
   until stockout. Show the ad spend being used while out of stock as a monetary amount, and include the
   scale of the waste on a pro-rated monthly basis.
   Present ASINs in the watch bucket whose ROAS is at or above {{REINFORCEMENT_ROAS_MIN (e.g. 2.0)}} as
   "consider reinforcing." If there are none, state "none applicable" explicitly. Do not put the
   cannot-assess ASINs (0 weekly shipments) among the hold-back candidates; list them separately
2. How to execute — the campaigns to hold back or reinforce can be identified by campaign_id in items[]
   from step 5. List the target ASIN alongside the target campaign, and adjust bids only after the user
   has reviewed and approved the proposal. However, when one campaign runs multiple ASINs, holding that
   campaign back affects the other ASINs too, so state the scope of the impact and defer to human
   judgment. If
   you want to pin this down at the target level rather than the campaign level, hand that over as a note
3. Measurement — {{REVIEW_DATE (e.g. 7 days later)}} after inventory recovers, retrieve
   detect_restock_needs again with the same assumptions and check whether the held-back ASINs have dropped
   out of urgent restock. At the same time, retrieve the ad performance on the same ASIN axis again and
   check with ROAS and ad sales whether the reinforcement proposal worked. Do not judge recovery by
   weeksOfCover / daysOfSupply

What you can change — lead-time days (e.g. 14 days) / safety-stock days (e.g. 7 days) / the minimum ROAS for reinforcement (e.g. 2.0) / the review date for re-checking (e.g. 7 days later).

What you get back — a list that separates the “consider holding back” ASINs (in ascending order of days until stockout, with the ad spend being used while out of stock and the scale of that waste on a pro-rated monthly basis) from the “consider reinforcing” ASINs (in the watch bucket with ROAS at or above the minimum), the target campaigns (campaign_id), and a separate list of the cannot-assess ASINs (0 weekly shipments). Since there is no mechanism that automatically pauses ads on stockout, ads for ASINs close to running out must always be adjusted by human judgment.

Changes — on this page, analysis and proposal only (ad settings are not changed). Actual adjustment is done through the approval flow (analyze → approve → execute) of Adjust bids / Adjust budgets.

Next steps — to execute a hold-back or reinforcement, use the approval flow of Adjust bids / Adjust budgets.

With Subscribe & Save (SnS), a stockout means registered subscriptions go undelivered, directly creating a loss of sales opportunity. Review “undelivered due to stockout” per product and use it as input for restock prioritization.

When to use — when you want to understand lost opportunities from Subscribe & Save stockouts and factor them into restock priority.

What you need — none (use as is). For the prior period you compare the recent period against, specify a non-overlapping period of the same length explicitly (if you omit it, a range that overlaps the main period is derived automatically).

Goal: to catch lost sales from Subscribe & Save (SnS) stockouts early and use them for restock prioritization, retrieve the per-product SnS performance and inventory status of {{ACCOUNT_NAME}}.

[Definition of the metric — check this first]
The not_delivered_due_to_oos that list_sns_products returns is not a "count" but a rate (%) (e.g. "0.0%" / "88.9%" / "--").
No field equivalent to the number of undelivered shipments, days out of stock, or expected demand exists in any of the SnS or inventory tools.
You therefore must not convert the lost opportunity into a monetary amount or a count. Rank by the rate, and show scale alongside it with shipments and sales.
The denominator of the rate is not documented in the specification, so do not back-calculate a count and present it.

[Retrieval steps]
1. Specify {{RECENT_PERIOD}} using only the most recent completed week, and retrieve list_sns_products with
   sort_key=not_delivered_due_to_oos / sort_order=desc / frequency=weekly.
   * Do not use frequency=monthly: the current month is not yet ingested and comes back as 0.
2. Specify a non-overlapping {{PRIOR_PERIOD}} of the same length explicitly and retrieve again under the same conditions.
   not_delivered_due_to_oos has no *_compare field, so a single call cannot compare periods.
   Also, if you omit the comparison period, a range that overlaps the main period is derived automatically, so always specify it explicitly.
3. The same ASIN can come back duplicated across multiple SKU rows, so consolidate by ASIN before aggregating and ranking.
4. For the top candidates, call get_fba_inventory and show sellableInventory / weeklyShipmentUnits /
   weeksOfCover alongside.

[Rules for interpreting values — strict]
- "0.0%" in not_delivered_due_to_oos means "no stockout-driven undelivered shipments"; "--" means "cannot be calculated (zero shipments in that period, or the SnS offer is INELIGIBLE / SUSPENDED)." Do not treat "--" as identical to 0.
- A drop in shipments for a product showing "--" is most likely caused by the offer ending, so do not conclude it was a stockout.
- weeksOfCover / daysOfSupply from get_fba_inventory return 0 when weeklyShipmentUnits is 0, even if inventory remains. On rows with weeklyShipmentUnits=0, treat weeksOfCover as "cannot be calculated" and do not use it as a stockout signal.
- Always keep null / not retrieved / 0 distinct in your notation.

[Data quality disclosure rules — most important]
(1) State the number of records retrieved and product_count at the top, and if there is a truncation marker, show the total count, the number confirmed, and the number unconfirmed.
(2) Only rows that actually exist in the tool result may be listed in the table; do not invent or imagine the ASIN, product name, or figures of truncated rows
    (fabricating even one row is treated as data misuse).
(3) If the number confirmed is fewer than the total, state that the ranking holds only within the confirmed range.
(4) Only assert causation (e.g. "shipments fell because of a stockout") when not_delivered_due_to_oos is a positive value.
    When it is 0.0% or "--", do not assert causation.

[Output]
- For the recent period and the prior period each, a table of the products with a non-zero rate in descending order (ASIN, product name, stockout rate, shipments, SnS sales, SnS unit price, weeks of cover). For products present in both periods, add the difference in the rate (percentage points).
- Note that products whose rate is high but whose shipments are below {{MINIMUM_SHIPMENTS_THRESHOLD (e.g. 50)}} are "small in scale, so restock priority is low."
- If there are zero non-zero products, state explicitly that "no stockout-driven undelivered shipments were detected in the recent period," and do not force a ranking table.
- Add one line on why the lost opportunity has not been converted to a monetary amount (the number of undelivered shipments, the length of the stockout, and expected demand cannot be retrieved from MCP).

[Judgment] Raise the priority of, and present as candidates for restock review, the products whose stockout rate rose versus the prior period and whose shipment scale is large.
[Measurement / Follow-up] 30 days after the restock response, rerun the same two-period comparison and check whether the not_delivered_due_to_oos rate fell (compare by rate, not by count).

What you can change — the recent period / the prior period / the minimum shipments used as a scale guide (e.g. 50).

What you get back — for the recent period and the prior period each, a table sorted by the undelivered-due-to-stockout rate (not_delivered_due_to_oos — a %, not a count) in descending order (ASIN, product name, stockout rate, shipments, SnS sales, SnS unit price, weeks of cover), plus the difference between the two periods (percentage points). Only products with SnS subscriptions are covered (this is SnS performance data, separate from ad-attributed sales). “0.0%” means no undelivered shipments and ”—” means it cannot be calculated (no shipment actuals, or the offer ended and so on); neither is treated as identical to “0.”