_1788776417798.webp?w=256&q=75)
You connect your AI tool to Amazon Ads through MCP, type a natural-language question: "Show me which campaigns wasted money last week," and the AI confidently replies that it has submitted a report request. It will be ready in approximately 15 minutes.
That is not a bug. That is not a slow server. That is how Amazon MCP's reporting works, by design, and it surprises almost every advertiser who encounters it for the first time: because every other part of MCP responds instantly.
Tell the AI to pause a keyword? Done in seconds. Create a new campaign? Launched. Change a bid? Applied. But the moment you ask it to tell you something about performance: ROAS, ACoS, which search terms are bleeding budget, the experience shifts entirely. The request goes into a queue. You wait.
Understanding why this happens, and more importantly, what to do about it, is the difference between using MCP effectively and spending half your sessions staring at a loading indicator.
The One Distinction That Changes How You Use Amazon MCP
Campaign Management and Reporting Follow Different Workflows
Amazon MCP has two completely different speed profiles depending on what you are asking it to do.
Campaign-management actions such as creating, pausing, or updating campaigns can be executed without going through the asynchronous report-generation workflow. This instant execution applies across all Amazon Sponsored Ads formats: Sponsored Products, Sponsored Brands, and Sponsored Display. The AI confirms it, and it is done.
If you are asking it to tell you something about past performance: how campaigns performed, which keywords converted, what the spend breakdown was: that request goes through Amazon's asynchronous report generation system. This is a completely different path, with a completely different waiting time.
Why This Split Matters More Than It Sounds
Most advertisers who try MCP do so expecting a live dashboard experience in conversational form. They imagine asking questions and getting answers the way they would in a chat. That works perfectly for account structure questions: "How many active campaigns do I have?" or "Is this keyword in the account?" Those rely on campaign configuration and account-management information that can be accessed through Amazon Ads campaign-management capabilities without generating a performance report.
Performance analysis is different. "What was my ROAS last week?" "Which keywords had the highest ACoS in the last 14 days?" These require Amazon to aggregate millions of impressions, clicks, and conversion events across your account, apply attribution logic, and structure them into a usable report. That process takes time: not because Amazon is failing, but because the task genuinely requires it.
What Async Actually Means: Without the Jargon
The Restaurant Kitchen Model
Imagine ordering food at a busy restaurant counter. You place your order. The cashier accepts it, gives you a number, and says, "We'll call you when it's ready." You step aside, the kitchen works on it, and eventually your number is called, and you collect the food.
Nobody expects the food to appear the moment they finish ordering. The kitchen needs time to prepare it. That is not a flaw in the system: it is how the kitchen works at scale.
Amazon's async reporting works the same way. You submit the request (place the order). Amazon's systems work on it in the background (the kitchen prepares it). When it is done, the data is available for you to collect (your number is called). The difference is that with async reporting, you have to come back and check rather than being called directly, unless the system is set up to notify you.
Sync vs Async in Plain Terms
Inside the Two-Step Flow: create_campaign_report and retrieve_report
Step 1: Submit the Report Request (create_campaign_report)
When an AI tool connected through MCP asks for performance data, it calls the create_campaign_report tool. This tool submits a report job to Amazon's reporting system and immediately receives back a report ID: a reference number for that specific report job.
The AI now has a ticket, but not the data. It knows the report has been queued. It does not know when the report will be done. The report ID is the equivalent of your restaurant table number: proof you ordered, a placeholder for what is coming.
Step 2: Come Back Later and Collect It (retrieve_report)
To collect the data, the AI calls retrieve_report with the report ID it received in step one. This checks the status of the report job. If the job is still running, the response will say so: the data is not ready yet. If the job has completed, the response contains the report data.
In practice, this means an AI session that needs performance data has to either wait and poll (check repeatedly until the status changes) or submit reports at the beginning of a session and retrieve them later in the same session, after enough time has passed for them to complete.
Why a Simple Question Can Take 30 Minutes
A question that feels simple: "what were my top 10 keywords by spend this week?": requires Amazon to pull all impression and click data for your account across the requested date range, apply your account's attribution model, aggregate spend by keyword, sort and structure the output, and make it available through the API. At Amazon's advertising scale, even a single account's weekly data involves many millions of events.
Simple reports (a single campaign, a short date range) often come back in 5 to 10 minutes. Complex reports (all keywords across all campaigns for 30 days) can take 20 to 30 minutes or longer. Some jobs stall in the queue and take longer still. The delay is not random; it scales with the complexity and volume of the request.
Why Amazon Designed It This Way
The Scale Problem: Millions of Data Points, Not Dozens
Amazon's advertising network processes an enormous volume of ad events every day: impressions, clicks, conversions, and attribution data across millions of sellers, billions of product listings, and multiple ad formats. Amazon Ads uses asynchronous report generation for applicable performance-reporting workflows, with the completed report retrieved separately after processing.
Amazon Ads API uses asynchronous processing for applicable reporting workflows, while other Amazon Ads services, such as Amazon Marketing Stream, provide more frequent access to supported advertising data. The async design is not a workaround: it is a deliberate match between the architecture and what the data pipeline can realistically deliver.
Why Performance Data Is Not the Same as Account State
There is a useful distinction here: account state and performance data are stored and accessed very differently. Campaign configuration operations use Amazon Ads campaign-management capabilities rather than the asynchronous report-generation workflow used for applicable performance reports. That is why creating a campaign or changing a bid through MCP is instant.
Applicable performance-reporting requests follow Amazon Ads' asynchronous reporting workflow, where reports are generated and subsequently retrieved. Querying it requires running a report job, not reading a live record. The async delay reflects this architectural difference, not slowness in the engineering.
The Real Cost of the Delay: and When It Matters
When 30 Minutes Does Not Matter at All
If your goal in an MCP session is primarily execution: launching a new campaign, pausing underperforming keywords, adjusting bids, expanding to a new marketplace, the async delay is essentially irrelevant. These campaign-management actions do not require advertisers to wait for an asynchronous performance report before the action can be submitted.
For execution-heavy workflows, MCP's async reporting limitation has almost no practical impact. The delay only becomes a problem when the session depends on reading performance data before deciding what to do next.
When It Matters a Lot
The delay becomes costly in two specific situations. The first is when you want to use MCP as a live analytics interface: asking performance questions, getting answers, making decisions based on those answers, all in a single conversational session. The async wait breaks that flow every time a data question is asked.
The second is when the data that eventually arrives is itself incomplete. Amazon's performance data does not settle immediately after events occur. Conversion attribution, in particular, continues to update for days after a click.
This means that a report pulled through MCP immediately after a campaign runs shows data that may materially undercount the actual conversions that will eventually be attributed. Acting on early async report data: cutting a campaign that looks unprofitable on Day 1 can mean cutting something that would have shown strong results by Day 10. The async delay is the first problem; data recency is the second.
Three Practical Approaches for Advertisers Who Cannot Wait
Approach 1: Restructure Your MCP Sessions
The simplest fix requires no new tools. If you know an MCP session will include performance data queries, submit all report requests at the very beginning of the session, before doing anything else. While you work through execution tasks: reviewing account structure, making bid changes, checking keyword lists, the report jobs are running in the background.
By the time you are ready to analyse performance, the reports may already be done. A session structured as: submit reports → execute changes → retrieve reports makes the async wait invisible rather than a blocking interruption in the middle of analytical work.
Approach 2: Use Amazon Marketing Stream for Closer-to-Live Data
Amazon Marketing Stream provides near-real-time access to supported advertising data through supported AWS delivery options. Updates arrive with some hours' latency rather than minutes, and data is pushed to you rather than requiring you to request it each time.
This is not live data: it is significantly fresher than standard async reports, but still not real-time. It also requires data engineering infrastructure to receive, store, and query the incoming data from S3. Marketing teams without developer support cannot implement this independently. For teams with engineering resources, it is the most practical way to get closer to current data than standard async reporting provides.
Approach 3: Use a Pre-Processed Data Layer for Instant Answers
The most complete solution to async delays is not to use MCP's reporting tools for analysis at all. A pre-processed data layer: a structured data warehouse that continuously ingests Amazon advertising data, computes metrics with the correct business logic, and makes them instantly queryable: completely bypasses the async mechanism.
When an AI tool is connected to a pre-processed layer rather than raw MCP reporting, performance questions return in seconds rather than 30 minutes, because the computation has already been done. The data is current as of the last warehouse refresh cycle (typically every few hours) rather than real-time. Still, it is infinitely more accessible than waiting for each job report individually.
Platforms like Hector Ai are built around this architecture: a pre-processed data warehouse that AI tools can query instantly for campaign performance, diagnostic analysis, and strategic decisions, while MCP handles the execution layer where speed is native. Unlike standard Amazon PPC software that still relies on async API calls for every data request, Hector processes and stores the data continuously so queries resolve in seconds. The two functions work together rather than trying to use one system for both.