Seller Central Inventory Reference for AI Agents

Most sellers still treat Seller Central inventory like a set of screens. Amazon treats it like a ledger.

That difference matters because Amazon's own inventory stack already exposes structured state across sales history, inbound shipment status, stock condition, and reconciliation events. The FBA Inventory report tracks restock, excess, aged, and unfulfillable inventory from one place, includes seven-day, 30-day, 60-day, and 90-day sales and units shipped, and breaks shipment quantities into working, shipped, and receiving statuses, all in Amazon's own help documentation for the report and page Seller Central FBA Inventory report reference. Amazon's inventory ledgers go further by recording movements such as received, sold, returned, removed, damaged, lost, found, and adjusted units, with the Inventory Ledger report available for up to 18 months of history Inventory Ledger and FBA Inventory overview.

For an MCP client, that means seller central inventory isn't a UI automation problem. It's a data access problem with known objects, known refresh behavior, token constraints, and explicit write boundaries.

Table of Contents

• Inventory as a Data Layer for Agents
  • What an MCP client should read
  • Why this framing matters operationally
• Core Inventory Objects and Field Definitions
  • The five objects that matter
  • Field semantics and boundary control
  • Shipment and removal enums
• Canonical Inventory Reports in Seller Central
  • The report set operators actually use
  • What each report is good for
  • Where the report model breaks down
• SKU FNSKU and ASIN Mapping
  • Identifier roles
  • Practical mapping table
  • Edge conditions
• Standard Inventory Workflows as Data Operations
  • Replenishment reads before it writes
  • Inbound shipments and removals
  • Stranded inventory is not a stockout problem
• SP-API Rate Limits and OAuth Constraints
  • Token mechanics that shape the data layer
  • Rate limits by operation
  • Failure handling
• Amazon Ads MCP Server Compared to agentcentral
  • The architectural difference
  • Comparison table
• How agentcentral Syncs Inventory and Exposes Tools
  • Sync shape
  • Tool exposure and access control
  • Auditability
• Read and Write Patterns for Inventory Agents
  • Three read modes
  • Guarded write modes
• Cross-Reference Index for Inventory Resources
  • Cross-reference table
  • How to use the index
• Quick Reference Glossary and Lookup Block

Inventory as a Data Layer for Agents

Seller central inventory becomes much easier to reason about when it's modeled as a read surface instead of a browser workflow. An agent doesn't need tabs, filters, and exported spreadsheets if the inventory layer already resolves inventory state as typed records.

At the source level, Amazon inventory data comes through a bounded set of API operations and report exports. A hosted MCP server should treat those outputs as the schema of record. That means fields such as sellerSku, asin, fnSku, quantity fields, and update timestamps are read from structured payloads instead of scraped from HTML.

What an MCP client should read

For inventory work, the useful read path is usually:

• Identity resolution: map a seller SKU to its ASIN and FNSKU
• Sellable state: determine whether units are available, reserved, inbound, researching, or unfulfillable
• Inbound state: check whether quantity is still working, shipped, or receiving
• Historical state: retain prior snapshots so an agent can compare current inventory against earlier points in time

That framing also keeps permissions clear. An agent can enumerate inventory objects and their fields without being allowed to create shipments, submit removals, or adjust stock. Inventory reads and inventory writes shouldn't share the same default scope.

Practical rule: If an inventory workflow starts by opening Seller Central, the data layer is still too thin.

Why this framing matters operationally

Amazon itself presents inventory as a balance problem between sold units and on-hand units, with explicit emphasis on avoiding excess and aged stock while keeping popular products in stock on the FBA Inventory page Amazon FBA Inventory page guidance. That is already a machine-readable operations model, even if many teams still consume it manually.

For operators building planning workflows around replenishment, assortment, and fulfillment, the broader operating model in this CPG growth checklist for 2026 is useful context because inventory data rarely lives alone. It interacts with ads, ranking, retail readiness, and cash planning.

An MCP layer should expose the inventory state exactly as Amazon structures it. No recommendation engine framing. No pseudo-analytics in place of source fields. Just inventory objects, report outputs, and guarded write access when a workflow explicitly needs it.

Core Inventory Objects and Field Definitions

Treat Seller Central inventory as a typed data model, not a single stock table. Identity fields, quantity buckets, shipment state, and removal state change on different timelines, come from different read paths, and should not share the same write surface.

The five objects that matter

That separation prevents two common failures. Teams collapse multiple quantity states into one stock field, or they let a read tool inherit write scopes it never needed.

Field semantics and boundary control

InventoryItem holds identity and listing-level attributes. sellerSku is the merchant key used in day-to-day operations. asin maps the item to Amazon's catalog record. fnSku maps the unit to Amazon fulfillment handling. condition and productName belong here because they describe what the unit is, not whether it is sellable right now. lastUpdatedTime should stay read-only.

InventorySummary holds operational quantity buckets. available is the quantity an agent can treat as sellable now. inbound means units are on the way through the FBA receiving path. reserved covers units Amazon has set aside for customer orders or internal handling states. unfulfillable tracks units that exist physically but cannot be sold. researching is its own class and should not be merged into reserved or unfulfillable, because operators ask different questions of each state.

That distinction matters in practice.

If a replenishment agent sees available=0 and inbound>0, the next read should go to shipment and receiving status, not to catalog or pricing data. If available falls while reserved rises, the issue is usually order allocation or FC processing, not a listing break.

FbaInventory carries fulfillment-center detail that is often lost in flattened exports. fulfillableQuantity is the current FC quantity that can ship. inboundShippedQuantity and inboundWorkingQuantity should remain separate because they represent different receiving stages. strandedQuantity belongs here because stranded stock is a fulfillment-state problem tied to sellability. customerDamagedQuantity should also stay separate from generic unfulfillable counts when returns and reimbursements are being reconciled.

Inventory defects usually start with field collapse. A tool merges available, inbound, and reserved, then every downstream read becomes harder to interpret.

Shipment and removal enums

status on InboundShipment should be enforced as an enum. The same applies to removalType and status on RemovalOrder. Free-text handling creates bad filters, weak validation, and write errors that are hard to trace once an agent is operating through a hosted MCP server.

Timestamps should be stored and returned as ISO-8601 UTC. That keeps historical comparisons stable across marketplaces, report snapshots, and token-scoped API sessions.

For a field-level example of how these entities can be exposed without flattening their meaning, see the agentcentral inventory reference for inventory tools and object schemas. It is a good model for pre-synced reads, where agents query current and historical inventory state in sub-second time without calling Amazon on every request.

Canonical Inventory Reports in Seller Central

Reports still matter because Seller Central inventory isn't purely live-state data. Some of the most useful views are generated on a cadence, not computed on demand.

The report set operators actually use

The point isn't the label of the report. The point is the role. Each report packages a different part of inventory state into a stable export that an agent can read repeatedly.

What each report is good for

The Daily Inventory Report is the closest thing to a stable inventory snapshot. It's where teams usually validate whether a SKU is currently sellable and whether inbound or reserved units are masking that fact.

The Monthly Inventory History Report is more useful for reconciliation and trend checks than for same-day action. Amazon's ledger history matters here because the platform keeps a historical chain of custody rather than just a current count.

The Inventory Age Report and Stranded Inventory Report answer different failure modes. Age is a storage and turnover problem. Stranded is an offer-state problem.

Operator note: A SKU can exist physically in a fulfillment center and still fail commercially because the active offer state is broken.

Where the report model breaks down

Amazon defines stranded inventory as FBA units in fulfillment centers with no active offer, and fixing it often requires relisting, price updates, or removal orders rather than replenishment stranded inventory help page. That's why a report-only workflow often misses lost sales. A team sees stock on hand but can't sell it.

For a broader map of how Seller Central reporting surfaces line up with programmatic data access, this breakdown of Amazon Seller Central reports is a useful companion reference.

SKU FNSKU and ASIN Mapping

Three identifiers carry most of the load in seller central inventory: SKU, ASIN, and FNSKU. Confusing them is one of the fastest ways to break joins between catalog data, stock state, and fulfillment history.

Identifier roles

The seller SKU is merchant-defined. It's the key operators usually recognize first because it appears in listing workflows, exports, and internal ERP mappings.

The ASIN is Amazon's catalog identifier. Multiple sellers can point different SKUs at the same ASIN. That shared catalog layer is why ASIN-level joins are useful for catalog metadata but dangerous for merchant-specific quantity state.

The FNSKU is fulfillment-network specific. It identifies the unit inside Amazon's fulfillment flow and helps separate one seller's physical stock from another seller's catalog participation.

Practical mapping table

The practical traversal for an agent is usually:

1. Resolve SKU to ASIN for catalog linkage.
2. Resolve SKU or ASIN to FNSKU when fulfillment-center stock needs to be inspected.
3. Attach marketplace context before comparing quantities.

Edge conditions

Bundles create ambiguity because the sellable SKU may not map cleanly to one physical inventory record. Variation families create another issue because the parent relationship is catalog structure, not stock state.

Removed or inactive FNSKUs can still matter historically. A history layer should preserve their prior ASIN relationship even after the current live path no longer returns an active fulfillment-unit mapping.

Standard Inventory Workflows as Data Operations

Inventory operations look cleaner when every workflow is treated as a state transition with preconditions, write payloads, and post-state verification.

Replenishment reads before it writes

Replenishment starts as a read operation. The system checks current sellable inventory, inbound state, and any restock or coverage fields already present in source data. Only after that should it generate a purchase order or a shipment plan.

Amazon's current control model adds an external constraint here. Restock limits are storage-type based, calculated from past and forecasted sales, allocated across ASINs, and monitored through maximum inventory level, utilization quantity, and maximum shipment quantity. If on-hand inventory plus shipments in transit exceed capacity, new FBA shipments can be blocked restock limits monitor and capacity rules.

Inbound shipments and removals

Shipment creation is a write path, but it shouldn't be treated like a blind submit. The write should carry an idempotency key, preserve the planned carton or item state, and return the shipment identifier for later polling and reconciliation.

Removal orders follow the same pattern. The system should validate removalType, inventory eligibility, and item scope before submission. After the write, it should store the resulting order state as a separate object, not overwrite the inventory record itself.

• Replenishment transition: read current inventory, check capacity exposure, then stage a shipment plan
• Inbound transition: create shipment plan, confirm shipment details, then track receiving status
• Removal transition: submit removal order, retain item-level references, and poll status changes
• Stranded fix transition: inspect offer state, relist or remove, then verify sellable recovery

Guarded writes need correlation IDs. Without them, a team can't prove whether the system actually submitted a shipment or just displayed a confirmation screen.

Stranded inventory is not a stockout problem

Many operators still send more stock when the issue is stranded inventory. That fails because the problem isn't quantity. It's sellability.

The more durable workflow is weekly detection of units that exist physically but have no active offer path, then routing those records into relisting, price correction, or removal logic. Those are data operations with explicit preconditions, not dashboard chores.

SP-API Rate Limits and OAuth Constraints

Every hosted inventory layer sits inside Amazon's token and throttle envelope. If either side is mishandled, the system fails in ways that look random to users.

Token mechanics that shape the data layer

Amazon's SP-API uses a short-lived access token and a long-lived refresh token. The access token is used to make calls on behalf of the seller, and the refresh token is exchanged for new access tokens without another authorization prompt SP-API website authorization workflow. Amazon also notes that generating a new refresh token doesn't invalidate previous refresh tokens on its authorization flow.

The timing constraints are explicit. Authorization codes expire after five minutes, access tokens are typically valid for about one hour, and selling partners must re-authorize every 365 days. Amazon also sends a reminder email 30 days before refresh-token expiration public app authorization timing.

Rate limits by operation

Amazon documents per-operation throttling and exposes applied limits through the response header in its usage plan documentation usage plans and rate limits.

Failure handling

A usable agent layer should assume that bursty polling will hit limits eventually. That means backoff, queue discipline, and endpoint-specific retry behavior are part of inventory design, not an afterthought.

A practical backgrounder on how these constraints affect integrations more broadly is this Amazon SP-API guide.

Amazon Ads MCP Server Compared to agentcentral

Amazon's first-party MCP direction is important, but it doesn't solve the same problem as a hosted seller central inventory layer.

The architectural difference

An Ads MCP server is naturally centered on the Amazon Ads surface. That means campaign entities, keyword entities, and asynchronous workflows around ad operations. Inventory is adjacent at best.

A hosted inventory MCP layer is different. It needs retained seller history, inventory object joins, shipment state, and repeated synchronous reads against a pre-synced dataset. For teams evaluating server design patterns, this overview of production MCP for AI agents gives useful context on why hosted, audited MCP infrastructure ends up looking different from thin API wrappers.

Comparison table

The difference isn't branding. It's data shape.

An inventory agent needs to ask questions such as whether a SKU is available, inbound, stranded, or capacity-blocked, then compare that answer to earlier snapshots. That requires a persistent inventory model, not just a pass-through call surface.

How agentcentral Syncs Inventory and Exposes Tools

A hosted seller central inventory layer should sync from source systems into merchant-scoped records before an agent asks for data. Otherwise every prompt turns into a live dependency on multiple APIs, report queues, and token refresh steps.

Sync shape

A practical implementation pulls inventory state from Seller Central and SP-API reads, then normalizes those results into seller-scoped tables keyed by merchant, marketplace, and SKU. Historical retention should happen at ingest time, not only when an agent explicitly asks for history.

The useful inventory sync usually combines:

• Inventory summaries for current quantity classes
• Fulfillment inventory detail for FC-oriented states
• Inventory reports for stable snapshot and age-oriented views
• Inbound shipment records for pre-receiving and receiving transitions
• Stranded inventory lookups for sellability breaks

Tool exposure and access control

In one hosted MCP pattern, agentcentral exposes inventory through merchant-scoped tools such as list_inventory, get_sku, get_asin_history, list_amazon_fulfillment_inbound_shipments, and adjust_inventory_quantity. The key design choice is that the client receives a scoped API key bound to seller and marketplace access, not raw Seller Central credentials or reusable SP-API tokens.

That separation matters because Amazon auth has renewal boundaries, while an MCP client needs stable access semantics. Reads stay fast because the system serves from pre-synced records. Writes stay bounded because each tool can require confirmation, preserve payload hashes, and log actor identity plus source request IDs.

Hosted inventory tools should expose facts and before/after states. They shouldn't improvise recommendations that aren't present in the source system.

Auditability

Inventory writes are where teams usually need evidence. A proper audit trail stores the actor, scope, payload fingerprint, and resulting platform identifiers in append-only form.

That doesn't make the write smart. It makes the write reviewable, reversible where possible, and attributable when operators need to investigate a shipment, a quantity adjustment, or a removal request.

Read and Write Patterns for Inventory Agents

The field model only becomes useful when read and write patterns stay narrow.

Three read modes

A solid inventory agent usually works in three modes:

1. Snapshot reads return the latest denormalized record for a SKU or ASIN in a marketplace.
2. Time-series reads return retained history so the agent can compare today's state with prior daily states.
3. Filtered list reads return slices across many SKUs with pagination and explicit filters.

Each mode answers a different question. Snapshot reads answer what exists now. Time-series reads answer what changed. List reads answer where to look next.

Guarded write modes

Write tools should remain limited and explicit. Inventory quantity adjustments and inbound shipment creation are common examples, but both need a nonced payload, a confirmation step, and a follow-up read against the audit record after submission.

Useful guardrails include:

• Marketplace scoping: every request should bind to a marketplace
• Recency windows: reads should support a lastUpdatedSince style filter
• Units clarity: tools should label whether returned quantities are available, inbound, reserved, or total
• Confirmation binding: a write preview should resolve to the exact payload later submitted

Composite flows then become predictable. A restock loop joins history reads with shipment creation. A stranded-recovery loop joins inbound visibility with offer-state remediation records. The agent still doesn't decide policy. It only traverses a reliable inventory data layer.

Cross-Reference Index for Inventory Resources

This lookup layer is where seller central inventory stops being a collection of unrelated screens and starts behaving like a stable interface map.

Cross-reference table

How to use the index

Stable names beat UI labels. Seller Central labels shift, but the underlying resource categories stay recognizable.

A good index lets an operator move from a UI symptom, such as a stranded SKU or blocked shipment, to the programmatic equivalent without rediscovering the object model each time.

Quick Reference Glossary and Lookup Block

The last useful step is compressing the vocabulary into one scan-friendly block. That lowers the cost of moving between seller central inventory screens, SP-API objects, and MCP tools.

agentcentral provides a hosted MCP server that turns Seller Central inventory into a structured, merchant-scoped data layer with retained history, scoped access, and audited writes. For teams building inventory agents, that means fast repeated reads for SKUs, ASIN history, inbound shipments, and stock state without pushing raw SP-API token handling into every client.