Can you trust the ad numbers an AI agent gives you? Checking which account, which period, and what was counted

Translated from the Japanese original on mureo.jp.

Have an AI agent read your ad account and ask it to “give me this week’s spend and cost per acquisition,” and a table comes back in a few seconds. The question is how far you can trust that table. Among the inquiries to mureo.jp, alongside questions about how the tool works, we were asked how to check the quality of the material an AI produces.

When people imagine why an answer is off, most think of calculation mistakes or misreading a metric. But the ways answers went wrong in our own operations almost all sat before that. The agent was looking at a different account, its period boundaries differed from the platform UI, or it reported the number of times an event fired as a number of people. The numbers themselves had been retrieved correctly; the agent was looking in the wrong place.

Below, we split the ways an agent’s numbers go wrong into three forms, set out the record of mix-ups that happened to us, and then describe steps you can take with read-only access before adopting an agent. Differences in metric definitions and attribution dates are covered in Why the numbers in your ad reports and the API do not match, so here we focus on what comes before that: which account’s numbers, for when, counted as what.

The bigger picture of handing ad ops to an AI agent is in Can you automate ad ops with Claude Code?.

Three ways the numbers go wrong

When the numbers an agent returns do not match the platform UI, the cause almost always falls into one of the following three.

Looking in the wrong place: there are several ad accounts, there are several analytics properties, or the MCP server holds credentials for only one account. In environments like these, the agent resolves the “our ads” in your question to one of them and answers. Even if that resolution differs from what the person meant, nothing feels wrong on the agent’s side.

Different period boundaries: what time zone do “this week” or “yesterday” break on? The platform UI breaks days on the account’s time zone, but it is not unusual for the timestamps returned by an API or a customer relationship management system (CRM) to be in Coordinated Universal Time (UTC). Anything that happens between midnight and 9 a.m. Japan time is an event of the previous day in UTC.

Counting a different unit: the number of form submission events and the number of people who made an inquiry are different things. If the same person submits twice, the analytics tool counts two. The number of contacts newly created in the CRM and the number of inquiries that came from your own site’s form are different as well.

The third is an extension of what we wrote in Checking whether ad conversion tracking is working, that the counts in the analytics tool and the CRM drift apart in both directions. The difference is that the issue here is whether the agent’s answer is correct. When a person looks at the platform UI, the screen’s headings let them notice the unit, but the agent’s answer leaves only the number.

Mix-ups that happened to us

In running mureo.jp, we read the site’s analytics tool, Search Console and the CRM from Claude Code, and regularly check how many inquiries came in and how many people landed on which article. Here are four mix-ups that actually happened along the way.

There are two analytics properties
We keep separate analytics properties for the Japanese site (mureo.jp) and the English site (mureo.io). Ask for “sessions in the last 7 days” as of October 13, 2026, and the answer is 101 for the Japanese site and 4 for the English site. If the answer does not say which property was specified, someone could look at 101 and read it as the English site doing well.

CRM creation timestamps are recorded in UTC
On the morning of October 13, 2026, when we counted the new contacts created in the last four days, one had been created at 0:02 on October 13 Japan time. The value the CRM API returns is 15:02 on October 12. Whether it counts as “an inquiry on October 12” or “on the 13th” changes with how the reader handles the time.

Of 5 new contacts, 0 were inquiries from our own site
Over the same four days, the CRM had 5 new contacts. But the breakdown was 4 from the inquiry forms of other services run by the same company and 1 test submission of an internal webinar signup; not one came from the mureo.jp form. An agent that answers 5 to “how many came from the site this week” has not got the number wrong. It simply resolved the “from the site” in the question to the whole CRM. The clue that told them apart was the form name left on each contact.

The MCP server refused another workspace
Our MCP server is built so that one process is bound to one workspace (one client’s credentials and settings). While working on the Japanese site, we tried to read the English site’s Search Console, and the server refused. That refusal is the correct behavior. Consider what would happen if it had not refused: another client’s numbers would mix into the same conversation, and you could no longer tell afterwards where an answer came from.

What the four have in common is that not one of them is a case of the agent calculating a number wrongly. In every case, the retrieved value itself was correct, and the resolution of where to look had drifted from what the person meant.

We will add one example heard from outside. In September 2026 we came across a post from a business selling its own products, saying that when they had an agent check Meta Ads through MCP, it returned “not delivering,” but retargeting was running in another account and had spent 438 yen (a post on X; we have not verified that the account is real or what the business is). Their conclusion was to check the AI’s answer in the platform UI.

Steps to check before adopting an agent

Mix-ups happen quietly, and you notice them only when you open the platform UI. So before having an agent read your ad numbers, we recommend checking in the following order. All of it can be done with read-only access.

Have it state the account it is looking at: before asking for numbers, have it list the name and ID of the accounts it is currently connected to. Match the returned IDs against the account ID in the platform UI. If several accounts come back, specify the ID in every question from then on. The same goes for analytics properties and CRM portals.
Have it state the day boundaries: ask for “yesterday’s” numbers, and have it add to the returned table the start and end time of the period and its time zone (Japan time or UTC). Compare with the time zone in the account settings in the platform UI, and if they differ, fix the time zone in your instructions to the agent.
Have it state the unit: for any answer that includes a count, have it add whether that is a number of events, a number of people, or a number of CRM rows. If what was counted when you asked for “number of inquiries” is on record, you can reread it later.
Reconcile just one number against the platform UI: you do not need to reconcile the whole table. Pick one number in the table that matters to your decision, open the screen in the platform UI with the same conditions, and compare. If it matches, the rest of the numbers came out under the same retrieval conditions, which gives you grounds to trust them just as much.
Have it distinguish a failed retrieval from 0: check that it is not built to report 0 when the API did not respond. If a day it could not read because authentication expired is recorded as “a day when nothing happened,” you will not notice later.

Step 4 is also the method of another business we came across on X. The post said that every week they hand the AI screenshots of the platform UI and their sales totals, have it name the weak products, and check by eye only the supporting numbers against the original screens (this one, too, we have not verified as real). It said this took 5 minutes. It is a way of drawing the line: check not the whole table, only the numbers the decision rested on.

Steps 1 to 3, once written into your first instructions to the agent, get added to every answer after that. The retrieval conditions listed in Why the numbers in your ad reports and the API do not match (period, official metric name, attribution date, unit of aggregation, time of retrieval), with three more added (account ID, time zone and unit counted), make the minimum form of a report you can check afterwards.

Where mix-ups tend to happen

Several accounts grouped under an MCC or Business Manager
At agencies and businesses with several brands, one set of credentials reaches several ad accounts. When the agent says “account,” which level it refers to becomes ambiguous. Put the ID in the question, and have it return the ID in the answer too.

Several accounts or campaigns with the same name
An account duplicated for testing, a new campaign with the same name as an old one that has ended. Have it resolve by name and the agent picks whichever it finds first. Specifying by ID is the reliable way.

Things that happen late at night Japan time
Events between midnight and 9 a.m. fall into the previous day when counted in UTC. In an operation that checks the previous day’s count in the morning, a gap of a few items shows up here every day. Decide which you count in, and have the agent use the same boundary.

Rows dropped by anonymization or thresholds
In Search Console’s per-query numbers and some metrics in the analytics tool, a few rows do not appear in the table. The total the agent gets by adding up the visible rows is smaller than the overall value. When you ask for a total, have it retrieve the overall value directly.

The previous day’s numbers are not in yet
Some metrics in the analytics tool return 0 for the previous day. This is a delay, not a breakage. Making it a rule to wait until the day before yesterday before reading prevents the agent from wrongly reporting that “it stopped yesterday.”

How mureo handles this

mureo, which we develop, is built so that one MCP server process is bound to one workspace. This keeps another client’s numbers from mixing in while you work on one client, and the Search Console refusal described above comes from this design. For each operation the agent calls, the time, the arguments (which account, which period) and the result are kept on record, so you can trace afterwards under what conditions a reported number was retrieved. When a retrieval fails, it is returned as a failure, not as 0. How to choose between this and the official MCPs is covered in Which ad MCP server should you use?.

If you are at the stage of considering adoption and want to see in advance how this check would go with your own account setup (the number of accounts, the combination of analytics tool and CRM) and what the resulting material looks like, write up your setup and send it through the contact form. We will return steps 1 to 5 above applied to that setup.

Frequently asked questions

The agent’s numbers did not match the platform UI. What should I suspect first?

Suspect the account ID and the time zone of the period. Before looking into differences in metric definitions or attribution, have the agent state which account and which period it looked at, and line them up against the conditions in the platform UI. The mix-ups in our own operations were all found here. If they still do not match, move on to the reconciliation order in Why the numbers in your ad reports and the API do not match.

Should I avoid handling several ad accounts in one conversation?

There is no need to avoid it, but you need a rule that both questions and answers always include the account ID. Specify by name and mix-ups happen with accounts that have the same or similar names. With a one-process-one-workspace design like mureo, nothing mixes even if you do not specify on the conversation side, but in exchange you switch processes every time you switch clients.

Should I count inquiries in the analytics tool or the CRM?

If you want the number of people, the CRM. What the analytics tool counts is the number of times an event fired: two submissions by the same person count as two, and your own test submissions and bot submissions are included in the count too. Conversely, there are cases where a server-side submission succeeds but does not show up in the analytics tool. Read them with separate roles: the analytics tool for the values used to optimize delivery, and the CRM for the actual number of prospects.

Running the check every time is a hassle. Can I skip it?

Only step 4 (reconciling one number) needs to be done every time. Steps 1 to 3, once written into your first instructions to the agent, are added automatically to every answer after that. Step 5 is a matter of the connection setup, so checking it once is enough.

Can I do this check without write access?

Yes. Listing accounts, the period boundaries, retrieving counts and reconciling against the platform UI all need only read access. Treat it as work to confirm how far the agent’s answers can be trusted, at the stage before you allow writes. Where to draw the line on how much to hand over is laid out in How much of ad ops to hand to Claude Code.

Summary

When the ad numbers an AI agent gives you are off, the cause sits before any calculation error. It was looking at a different account, its period boundaries differed from the platform UI, or it counted the number of events as a number of people. What actually happened in our operations was four things: room for mixing up two analytics properties, CRM timestamps recorded in UTC, a week in which 0 of 5 new contacts came from our own site, and an MCP server that refused another workspace. In every case the retrieved values were correct, and the resolution of where to look had drifted from what the person meant.

Before adopting an agent, have it state the account it is looking at, the day boundaries and the unit it counts, reconcile just one number that matters to your decision against the platform UI, and have it distinguish a failed retrieval from 0. Then mix-ups no longer happen quietly. All of it can be done with read-only access.