Amazon ads API MCP server: what it does and what it can't see

On February 2, 2026, Amazon Ads opened a beta program for its own MCP server. Any AI agent that speaks Model Context Protocol, Claude, ChatGPT, Gemini, or a custom-built agent, can now connect straight to an advertiser's Amazon Ads account and create campaigns, adjust bids, and pull reports through natural language instead of a stack of API calls.

That announcement changes what "automating Amazon ads" means. It does not change what happens once your agent needs to know what a competitor is doing. Those are two different problems, and conflating them is how teams end up with a fast campaign builder and no idea why their ACoS is climbing.

This post breaks down what the Amazon Ads MCP server actually does, where its access ends, and where a separate competitive ad intelligence layer picks up the work it was never built to do.

What the Amazon ads API MCP server actually does

Amazon Ads' VP of Ads Measurement, Paula Despins, described the server as a "translation layer" that turns natural language prompts into structured calls against the Amazon Ads API. Instead of wiring a custom integration for every tool that wants to touch an ad account, the MCP server exposes a fixed set of tools that any MCP-compatible agent can call.

In practice this means an advertiser can type a single prompt, expand a US campaign into Canada, or generate a full Sponsored Products campaign with ad groups, keywords, and a budget breakdown, and the server handles what used to take three or more separate API operations.

The server is hosted by Amazon on the advertiser's behalf and is natively integrated with existing Amazon campaign management tools, while still letting the advertiser bring their own LLM or agent framework on the front end.

How it works under the hood

The MCP server sits between the agent and the Amazon Ads API. A user prompts a tool, the tool sends structured instructions to the server, and the server executes those instructions against the underlying API endpoints. Despins compared this to giving an agent "the three files you need" instead of dumping an entire file cabinet in front of it and hoping it picks the right document.

That framing matters because Amazon built the server specifically to fix a problem it saw internally: agents pointed at raw, granular APIs would sometimes use a deprecated endpoint or pull three years of Amazon Marketing Cloud data when a standard report would have answered the question. The MCP layer only exposes APIs that match Amazon Ads' current domain model, so an agent can't accidentally reach for a stale version.

Authentication runs through the same OAuth credentials advertisers already use for the Amazon Ads API, and account scoping happens through profile, account, or manager-account identifiers passed as headers, either fixed at setup or resolved dynamically by the connected LLM.

What you can build with it today

The tools available in open beta are built around the workflows advertisers run most often. Two are worth calling out specifically:

A campaign expansion tool that takes an existing campaign running in one country and replicates it into another with a single prompt, useful for sellers scaling from a US catalog into Canada or the UK without rebuilding targeting from scratch.

An end-to-end Sponsored Products tool that creates the campaign, ad groups, and ads in one pass, collapsing what would normally be a multi-screen setup flow into one instruction.

Bid adjustments and campaign pause or enable actions apply near-instantly, in seconds according to early testing. That speed is real, and it is also exactly why the next section matters more than it might seem.

The blind spots that matter for performance marketers

The MCP server operates entirely inside Amazon's own advertising data. It has no line of sight into inventory levels, so an agent can happily raise bids on a product that is three days from going out of stock. It has no access to margin data, COGS, or FBA fees, so it cannot tell a 15% ACoS win from a 15% ACoS loss on a thin-margin SKU. And it has no visibility into organic ranking, so it can't separate a sales lift that came from the ad from one that would have happened anyway.

None of that is a flaw in the MCP server. It was built to execute advertising actions inside a single account, not to reason about profitability or supply. The problem shows up when a team assumes speed of execution means the agent is making good decisions. It's making fast decisions inside a silo.

There's a second, quieter blind spot worth naming: the MCP server only ever sees your account. It has zero access to what a competing brand is bidding, which creative angles they're rotating in, or how their spend shifts week over week. That's not a limitation Amazon is going to fix, because it isn't the product they built. It's a different layer of the stack entirely.

Reporting lag and the historical data wall

Campaign creation through the MCP server is close to instant. Reporting is not. Performance reports are delivered asynchronously, the agent has to submit a request and then poll for completion, and that round trip can take several minutes rather than returning inline with the prompt.

Historical access is capped too: the server's reporting window tops out at 60 to 95 days. A team used to pulling twelve months of keyword-level data for seasonal planning will hit a wall fast. For anything beyond that window, the data has to live somewhere else before the MCP server was ever queried.

Standard SP-API throttling limits apply to MCP calls as well, so teams already running other integrations against the same account risk rate-limiting their own reporting if they layer heavy agent activity on top.

What this means for agencies managing Amazon accounts

The disruption lands hardest on agencies running Amazon PPC as a service. If campaign execution, the part clients used to pay hourly rates for, now takes one prompt, the billable work shifts. What doesn't get automated is the judgment call: whether a bid increase is worth it given margin, whether a competitor's new creative angle is about to eat a client's share, whether now is the time to expand into a new marketplace.

Agencies that keep treating campaign setup as their core deliverable are competing against a tool that does that part in seconds. Agencies that shift toward profit-aware strategy and competitive positioning are using the same MCP speed to spend less time on setup and more time on the decisions that actually move ROAS.

Where competitive ad intelligence fills the gap

This is the layer the Amazon Ads MCP server was never designed to provide, and it's the one that determines whether fast execution turns into a good outcome. Knowing your own bids, budgets, and campaign structure is table stakes. Knowing what competitors are running, which ad formats they're testing, how their spend concentration shifts by category, and which creative angles are winning attention in your niche is a separate data problem that requires monitoring accounts you don't control.

For a broader look at how agent-based monitoring approaches that problem across platforms, our breakdown of how AI agents find a competitor's best performing ads covers the mechanics in more detail.

The pattern repeats across every ad platform that has shipped its own agent tooling recently. An account-side MCP server makes execution faster inside your four walls; it says nothing about what's happening outside them. That's true whether the platform in question is Amazon, YouTube, or Pinterest.

How to evaluate MCP-connected Amazon ad tools before you adopt them

Before wiring an agent into a live Amazon Ads account through MCP, run the connection through a short checklist:

Audit your baseline Total ACoS before turning on any MCP-connected agent, and re-check it after a few weeks. If TACoS climbs after the agent starts creating or adjusting campaigns, it's optimizing for a metric that isn't your actual goal.

Keep margin and inventory data in a separate system that feeds decisions back to a human or a secondary agent, since the MCP server itself has no access to either.

Watch for SP-API rate limit warnings if you already run other tools against the same account. MCP calls share the same throttling budget as everything else hitting that API.

Treat the reporting lag as a planning constraint, not a bug. Build review cadences around the 60-95 day data window rather than assuming you can pull a year of history on demand.

Pair execution speed with a competitive view. A campaign built in seconds still needs to be built in the right direction, and that direction comes from knowing what the rest of the market is doing, not just what your own account looks like.

Getting started without breaking your account

Amazon's own documentation recommends starting in fixed account mode, statically setting profile, account, or manager-account identifiers when you first connect, rather than letting the LLM resolve account context dynamically. That removes one entire class of mistake: an agent acting on the wrong account because it guessed at scope from a natural language prompt.

From there, the safest rollout path looks like most agentic rollouts: start with a single low-stakes campaign, watch the reporting lag and bid behavior for a couple of weeks, and only expand scope once you trust the pattern of what the agent actually does versus what the prompt asked for.

Amazon isn't alone in shipping this kind of server. Similar MCP servers are now live or in progress for YouTube ads and

Pinterest ads, which means the same evaluation checklist above applies platform by platform as each one rolls out.

The direction is clear: every major ad platform is building the execution layer for agents. The competitive intelligence layer, watching what happens outside your own account, is being left to a separate category of tool on purpose.

Frequently asked questions