Technical

How Amazon Ads MCP Works: Under the Hood

amazonadsmcp.com

How an Amazon Ads MCP server works under the hood: OAuth and tokens, profiles and regions, tool definitions, the async report cycle, and limits.

Updated June 15, 2026 · The Amazon Ads MCP editorial team

This is the technical view. If you want the plain-English version first, read What is Amazon Ads MCP?, which covers the architecture and the basic request flow. Here we go a level down, into the work an Amazon Ads MCP server actually does on each call.

Authentication and token refresh

Amazon Ads uses Login with Amazon (LWA) OAuth. The flow looks like this:

  1. You authorize the server once, which returns a long-lived refresh token.
  2. The server exchanges that refresh token for a short-lived access token (good for about an hour) whenever it needs to call the API.
  3. It refreshes the access token automatically as it expires, so you never deal with it.

Every request also carries two headers that decide what the call can touch:

  • Amazon-Advertising-API-ClientId identifies the application.
  • Amazon-Advertising-API-Scope carries the profile ID, which maps to one advertiser account in one marketplace.

That profile scope is why a single connection can manage many accounts: the server swaps the profile per call. It is also the foundation for agency multi-account access.

Profiles and regions

The Amazon Ads API is split across three regional endpoints, North America, Europe, and the Far East, and each account lives in one of them. A request sent to the wrong region simply will not find the account. The server keeps track of which profile belongs to which region and routes the call accordingly, which is one more detail you would otherwise manage by hand.

What a tool looks like

Each operation the server exposes is a tool with a name, a description, and a typed input schema. The model reads these to decide what to call and how to fill it in. A simplified bid update tool might be described like this:

{
  "name": "update_keyword_bid",
  "description": "Set a new bid for a keyword in a Sponsored Products campaign.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "keywordId": { "type": "string" },
      "bid": { "type": "number", "description": "New bid in account currency" }
    },
    "required": ["keywordId", "bid"]
  }
}

The quality of these descriptions matters more than people expect. Clear, well-scoped tools lead the model to make one confident call; vague or overlapping ones lead to wrong guesses.

The asynchronous reporting cycle

The single most awkward part of the Amazon Ads API is reporting, and it is where the server adds the most value. You cannot just ask for a report and get rows back. The real sequence is:

1
Request POST a report request, get back a report ID.
2
Poll GET the status until it turns COMPLETED. ↻ repeat until ready
3
Download Fetch the gzip file from the returned URL.
4
Parse Decompress and turn rows into clean data.

An MCP server runs this entire loop for you. To the AI, it is a single tool call.

Behind a tool like get_sponsored_products_report, the server issues the request, polls the status until it is ready, downloads the compressed file, decompresses it, and hands back parsed rows. The model, and you, see one clean step instead of four.

Rate limits, retries, and errors

Production traffic runs into the API’s guardrails, and a good server absorbs them:

  • Throttling. The API returns HTTP 429 when you exceed its limits. The server queues calls, backs off, and retries instead of surfacing raw errors.
  • Token expiry. A 401 triggers a silent token refresh and a retry.
  • Validation. Bad inputs are turned into clear messages the model can act on, rather than cryptic API codes.

How much of this a server handles well is exactly what separates a robust option from a thin wrapper, which is the theme of our comparison of servers.

Write operations and safety

Read calls are low-stakes. Write calls (bids, budgets, campaign state) change real spend, so the mapping matters. Well-built servers add guardrails on top of the raw mutation endpoints, such as validating ranges, batching bulk changes, and logging every action. None of that comes from the API itself; it is the server’s job, which is why the choice of server is a safety decision as much as a feature one.

Sources

  1. Amazon Ads, Advertising API documentation (authentication, profiles, reporting, rate limits). advertising.amazon.com
  2. Anthropic, “Introducing the Model Context Protocol” (tools and schemas). anthropic.com

Frequently asked questions

How does an Amazon Ads MCP server authenticate?+

It uses Login with Amazon (LWA) OAuth. You authorize once, the server stores a refresh token, and it exchanges that for short-lived access tokens as needed. Every API call also carries a client ID header and a profile scope header that identifies which advertiser account and marketplace to act on.

Why is Amazon Ads reporting so awkward to call directly?+

Reporting is asynchronous. You request a report and get an ID, poll the status until it is complete, download a gzip file from a URL, then decompress and parse it. A good MCP server runs that whole loop behind a single tool call so the model never sees it.

Do MCP servers handle Amazon Ads rate limits?+

Good ones do. The Amazon Ads API throttles requests and returns HTTP 429 when you exceed limits. A solid server queues calls, backs off, and retries, rather than passing raw throttling errors back to the model.

Keep reading