The analytics your AI agent can read
What a dashboard assumes
Every analytics product you have used makes four assumptions about its reader. All four were reasonable when the reader was a person with a browser open, and none of them survives contact with an agent.
| The assumption | Why it fails for an agent |
|---|---|
| The reader can see | a chart is pixels. The agent needs the rows, not a picture of them |
| The reader will navigate | an agent cannot click through a screen; whatever it needs has to come back in the reply |
| One metric per view is enough | the useful answers live between metrics, so one view per metric is the wrong unit |
| The reader knows what to look for | an agent is often asked the vague question precisely because nobody knows yet |
None of that makes dashboards bad. It makes them a human interface, being handed to a reader who is not human.
What changes when the reader is an agent
An agent wants to ask a question, get structured data back, and reason over it. That changes what "good analytics" means in a specific way: the value moves out of the presentation layer and into the shape of the answer.
A dashboard is optimised for the question you already knew to ask. An agent is most useful on the question you did not.
This is why screenshotting a dashboard into a chat disappoints. You have handed over a rendering of a subset of the data, chosen by you, framed by a date picker you set. The agent can describe that picture back to you. It cannot ask the picture a second question.
The join is the product
"Conversions dropped" is a shrug. "Conversions dropped on the pricing page, which also started throwing a JavaScript error after Tuesday's deploy, and whose exit rate doubled in the same window" is a diagnosis. The difference is not more data. It is data that has been joined.
| Question | Silos it has to cross |
|---|---|
| Is this error costing anything? | incidents joined to conversions, per page |
| Did that ranking dip cost us money? | Search Console joined to sessions and conversions |
| Which section of this page do people use? | section engagement joined to conversions |
| Is the paid traffic worth what we pay for it? | ads spend joined to landing pages and conversions |
A single-source reader cannot produce any of those sentences, no matter how good its own data is. It is not a limitation of the tool. It is a limitation of the silo.
The worked example: twelve calls, four silos, seven minutes
This is what one investigation looked like end to end, taken from the activity log rather than reconstructed. One site on the account, the morning of 4 September 2026, times in UTC.
| Time (UTC) | Tool | What that tool reads |
|---|---|---|
| 05:52:51 | get_incidents | errors, ranked by business impact |
| 05:52:57 | get_incident_detail | the signature behind one failure class |
| 05:53:34 | get_incident_detail | the same tool again |
| 05:53:34 | get_incident_detail | and again, in the same second |
| 05:55:05 | get_search | Search Console: queries, impressions, clicks, position |
| 05:56:07 | get_incident_detail | back to the error detail |
| 05:59:06 | get_engagement | which sections of a page get used |
| 05:59:09 | get_events | custom events |
| 05:59:18 | get_events | custom events again |
| 05:59:55 | get_incident_detail | error detail again |
| 06:00:07 | get_events | custom events again |
| 06:00:24 | get_events | and once more |
The log records which tool ran and when, and not what it was asked. So the arguments are invisible here: what you can read is the SHAPE of the investigation, not its subject.
Twelve calls in seven minutes and 33 seconds, across four different silos, with no export, no tab switching and no date picker set twice. Read the shape rather than the individual rows: the agent goes to errors, leaves for search, comes back to errors, goes to engagement, goes to custom events, comes back to errors again. That is one continuous line of reasoning, and every return trip reads as a question the previous answer produced.
Two calls land in the same second at 05:53:34. Nothing about a human sitting with a dashboard produces that. What the agent concluded is not recorded, because askbowtie keeps no transcript, and the point here is the shape rather than the finding.
Count what the equivalent costs by hand: an error tool, an analytics property, a Search Console property, and whatever holds your custom events. Four logins, four date pickers set to the same window, and a spreadsheet to line them up.
What "agent-readable" requires
"Has an API" is not the same thing. Four properties separate data an agent can reason over from data it can merely fetch.
| Property | Why the agent needs it |
|---|---|
| Structured responses, not rendered ones | it reasons over rows; it cannot parse a chart |
| Joined at read time | otherwise the agent does the join badly, or not at all |
| Specific tool descriptions | the description is the only thing it reads when choosing a call |
| Numbers that carry their window | a figure without its period is a figure it will misquote |
The fourth one is the most important, because getting it wrong is invisible. An agent handed 1.2% with no window attached will cheerfully compare it to a number from a different period. Every per-site askbowtie response echoes back the domain and the period it answered for, which is why get_conversions returns the window alongside the rate rather than just the rate.
What an agent does with a vague answer
An under-specified analytics answer does not produce an error. It produces a confident sentence that is wrong, which is worse, because nothing about it looks wrong.
The clearest example is an error count. Ask most tools "how many errors does my site have" and you get one number, and that number blends your own broken code with third-party scripts an ad blocker stopped and vendor beacons failing on the vendor's side. Nothing you ship can fix the second kind, and none of it means your site is unhealthy.
How big the blend is varies more than people expect, which is the point. askbowtie's own tool description warns that the not-your-code share is regularly 80 to 90% of the blended total. On this site over the eight days from 28 August to 4 September 2026 it was 24 of 127, and the largest slice was 62 problems that were the site's own but not urgent. Either way the blended figure answers nothing: an agent handed it reports it as your error count and then spends a turn investigating noise.
The fix is in the response, not in the prompt. get_incidents returns a triage block that splits the total into action_needed, worth_a_look and not_your_code, summing exactly to it, so the agent can say what is broken without deciding for itself which classes count. Designing the response so the honest answer is the easy one is most of what "agent-readable" means in practice.
Read-only versus still watching
Google's official GA4 MCP server is a good example of the first generation, and an honest one: it reads your Analytics data inside a chat you start, read-only and local. Nothing runs when the chat is closed.
| A local, read-only server | A hosted one | |
|---|---|---|
| While you are asking | answers your question | answers your question |
| While the chat is closed | nothing | still collecting, still watching |
| At 2am when a funnel breaks | nobody finds out until someone asks | an alert reaches a human |
That middle row is the whole difference, and it does not show up in a feature comparison. A doorway is open only while you stand in it.
Where a dashboard still wins
Three cases, and pretending otherwise would be the same mistake in the other direction. A dashboard is better when you are browsing rather than asking, because you do not yet have a question to type. It is better for showing a trend to somebody else in a meeting, because a picture is the right format for a room. And it is better when the answer genuinely is one number that you check every morning.
askbowtie ships a dashboard for exactly those cases. What it does not do is make the dashboard the only way in.
What it costs to be readable
Less than the dashboard did. One script tag, and the MCP connection is not metered: you can query it as often as you like, from your own agent, on the free tier, up to roughly 100,000 events a month across every site on the account. The thing you are paying for with a dashboard product is the interface, and this is the argument for not paying for one twice.
Try it on your own site
Point an agent at your own data and ask the messy question you would never phrase for a dashboard. Not "show me conversions", which is a dashboard question with extra steps, but "why did conversions drop last week, and is anything broken?". The difference in what comes back is the entire argument on this page, and it takes about five minutes to test.