An Amazon agent needs access, context, and a method
The model supplies general reasoning. Account connections supply current state. Landed data supplies history and provenance. Skills supply repeatable methods and decision rules. Approval policy determines which proposed actions may execute. These parts solve different problems; connecting a tool alone does not supply the business context needed to interpret its output.
The AI data-moat essay explains the role of account knowledge and operator judgment. The agent-ready data architecture guide turns that premise into storage, freshness, lineage, and workload requirements. The essay is a positioning argument; the architecture guide develops the operating design.
Which connection supplies the data your agent needs?
The Amazon Ads API serves advertising operations and reporting. The Selling Partner API serves selling operations such as orders, listings, inventory, and payments. They have separate authorization and account-scoping requirements. The Ads API versus SP-API guide explains why access to one does not imply access to the other.
| Design choice | Question to answer | Deeper guide |
|---|---|---|
| Live tools or landed history | Do you need current state, a reproducible historical comparison, or both? | Agent-ready data |
| Model prompt or reusable method | Which checks and approvals must survive the next run? | Amazon Skills for Claude |
| MCP tool exposure | What does the client load at connection, and when does it load more? | MCP connection context cost |
| A seller-assistant plugin | Does its documented access cover your actual account questions? | Seller Assistant plugin |
Why do freshness and tool scope matter to the answer?
A stale inventory snapshot and a live inventory response can support different decisions. Preserve the source and capture time with landed records, and identify the account and marketplace on live requests. A plausible answer without that context can be difficult to reproduce or approve.
Tool names also need careful interpretation. The seller Messaging API guide shows a concrete boundary: its messaging operations send supported order messages; they do not read a buyer inbox. Check the actions an order permits before constructing a message. A connection is not permission to perform every imagined workflow.
Keep method, context cost, and execution policy separate
A Skill preserves the workflow; it does not replace authorization or grant a write permission. Similarly, tool-definition overhead depends on the server and the client's loading behavior. The connection-cost guide records a specific comparison, not a universal token bill for every client or future release.
This collection covers selected architecture choices and integration examples. Agent decision rules develops the calculation and action gates, while the MCP overview explains the tool-access layer. Use the Skills reference to inspect a method's actual scope before assigning it recurring work.