Listing Suppression Diagnosis: Stranded or Buyable

Create this workflow as a reusable Skill called silent-asin-diagnosis. It reads live BUYABLE and DISCOVERABLE status through the Selling Partner MCP, uses Amazon Agent Atlas to interpret the exact suppression or stranded-inventory rule, and returns the reason-specific fix plus its deadline before anyone edits the listing. I start there when a top ASIN suddenly has no orders or impressions. Search suppression, a non-buyable offer, a block, a deletion, and stranded Fulfillment by Amazon (FBA) stock can look identical from the sales graph, but each demands a different repair.

A plain ChatGPT or Claude conversation hits three walls: no access to your data, including the live SKU, ListingsItemStatus, FBA units, listing issues, or current report; no way to take action, such as requesting evidence or applying an approved fix; and generic knowledge, not Amazon's exact reason fields and deadlines. You must paste disconnected snapshots, expose account data, and carry out every step yourself. Connected AI clients get past those walls through the MCP's reads and actions, Atlas-grounded rules, reusable Skills, and the Amazon Agent Data layer that records the decision.

BUYABLE and DISCOVERABLE separate suppression from stranding

When a listing is search suppressed, Amazon removes discoverability but can leave the offer buyable; stranded inventory is FBA stock in a fulfillment center that does not have an active offer. That distinction is the first branch, not a semantic detail.

The Skill reads ListingsItemStatus, whose relevant values are BUYABLE, DISCOVERABLE, and DELETED. BUYABLE without DISCOVERABLE points to search suppression. An absent BUYABLE status establishes that the offer is not buyable, but it does not establish stranding until the agent also finds FBA units and no active offer. If both status flags are healthy, I move the investigation away from catalog repair.

The suppression reason chooses the repair

GET_MERCHANTS_LISTINGS_FYP_REPORT contains only suppressed listings, the reason for each suppression, and instructions for removing it. It can be requested for a current investigation or scheduled for continuous monitoring.

I use the report to identify the affected SKU, then add its live listing issues to the evidence. The Suppressed Listings Management playbook routes the result through Fix Your Products: image failures go to image requirements, missing attributes expose the absent value, and newly required compliance attributes get patched directly. Rewriting unrelated copy or adding stock does not repair those causes.

The bulk report is not real-time proof. Later report calls can be 1 to 6 hours old, and the stock-data freshness commitment is three hours, so the Skill pairs that evidence with the live listing read before proposing a patch.

The stranded reason chooses relist, restore, or removal

Stranded reason determines whether the operator should relist the SKU, restore an offer, correct price or condition, fix the fulfillment channel, or remove the units. The Fix stranded inventory page is the most accurate source when Manage Inventory and stranded status disagree. Until the active offer returns, those FBA units cannot sell and continue to accumulate storage fees.

The Resolve stranded inventory issues playbook reads Stranded reason and the accompanying Additional information or Recommendations. Common evidence includes a missing listing, a missing price or condition, or a merchant-fulfilled listing attached to FBA units. For a catalog-wide repair, the same playbook uses the Bulk Fix Stranded Inventory workflow.

The clock matters. If the seller does not create a listing or order removal within 30 days of Amazon's notice, Amazon designates the inventory unsellable and it must be removed. The deadline begins with Amazon's notice, not with the day I diagnose it.

A repair is complete only when status returns

A submitted change is not a completed repair. Suppression closes when discoverability returns; stranded stock closes when buyability and an active offer return.

The Skill watches LISTINGS_ITEM_STATUS_CHANGE, schedules GET_MERCHANTS_LISTINGS_FYP_REPORT, and re-reads the affected SKU after Amazon's processing window. It records the branch, approved action, evidence, and stranded deadline in the run log. If BUYABLE and DISCOVERABLE are both healthy but demand is still absent, the workflow hands the ASIN to the Amazon Ads MCP instead of misclassifying a traffic problem as a listing problem.

What happens next

I route the completed diagnosis to one owner. Product-data issues go to the team approving an image, attribute, or compliance patch. Offer and FBA issues go to the inventory team with the reason-specific action packet. A healthy listing with no demand moves to the advertising team with its catalog state already cleared.

That handoff can run as one recurring Skill through Amazon Agent Flow, so each new silent-ASIN alert arrives with its evidence and owner instead of becoming another unclassified ticket.

The pattern is status, reason, scoped action, and verified return. That keeps a silent ASIN from turning into an expensive guess.

Next, use the listing audit-to-patch guide to turn a verified attribute issue into the smallest safe catalog change.