How to Check Analytics Across All Your Sites by Asking Claude One Question

If you run more than a handful of sites, you know the Monday ritual. Open the analytics dashboard, click into the first site, look at the graph, click back, click into the second site. By site six you are skimming. By site twelve you have stopped looking at anything except the biggest number, and the site that quietly lost its tracking script three weeks ago slips past again.

The question you actually have is simple: how is everything doing, and did anything move? Dashboards are bad at that question because they are built for one site at a time. So we rebuilt Abner's query surface around it.

Why dashboards fit this problem so badly

Before this release, an AI agent connected to Abner over MCP could already answer per-site questions well. But a portfolio question meant the agent had to list your sites, fire a metrics query per site, fire a second round for the previous period, then do the comparison arithmetic itself. We watched a real session sweep a 29-site portfolio: 16 parallel tool calls plus hand-written math to answer one sentence.

It worked, but it was slow, expensive, and the arithmetic lived in the model where it does not belong. Percent changes computed by a language model are a coin you should not flip twice a day.

One question, one call

The MCP server now has two portfolio tools. query_portfolio returns every site in your account in one call, each metric already compared to the previous period on the server: current value, previous value, percent change. Each row also carries last_event_at and a liveness status (live, quiet, or silent), so a site whose tracking silently died shows up instead of hiding.

get_changes answers the follow-up: anything weird? It returns only the sites whose visitors moved at least 30 percent against the previous period (with a 50-visitor noise floor so tiny sites do not spam you), ranked by swing size, each with the top pages and referrers that explain the move. An empty list is a real answer: nothing moved.

A real exchange from our own account this week: asked "how are my sites doing, anything weird?", Claude made those two calls and reported that one site had jumped seventeenfold on a single blog post picked up by search, another was slipping after losing Google referrals, and everything else was steady. Two tool calls, no arithmetic in the model, and the answer named the exact pages responsible.

The rest of the release

• Arbitrary date ranges. Every query tool takes date_from and date_to (up to 366 days) instead of only preset windows, in your site's timezone.
• Server-side comparison. Pass compare: "previous_period" to query_metrics and each metric comes back as current, previous, and percent change. The server does the math so the model never has to.
• Liveness everywhere. Every surface that lists sites now reports when each site last saw an event and whether it is live, quiet, or silent.
• Nine tools total. Site listing and creation, metrics, realtime, Core Web Vitals, funnels, portfolio, changes, and deletion, all under OAuth 2.1. Everything on the MCP server has an identical twin in the REST API.

One design rule holds across all of it: the agent never writes SQL, never invents a metric name, and never does the statistics. The query vocabulary is a fixed, server-defined set, and every number in a response was computed deterministically in the database. The model's job is choosing the right question and narrating the answer.

Try it right now, no account

We publish a read-only demo token that exposes the live analytics for abner.app itself, the site you are reading. One command connects it to Claude Code:

claude mcp add --transport http abner-demo https://mcp.abner.app/mcp \
  --header "Authorization: Bearer abner_ws_demo_portfolio_readonly"

Then ask it how the site is doing. The demo is read-only: any tool or endpoint that writes returns a clear "demo access is read-only" error, so there is nothing to break. The same token works against the REST API if you prefer curl. Details are in the MCP docs.

What this is not

Abner is still web analytics: traffic, referrers, custom events, funnels, Web Vitals. It is not product analytics; if you need user-level cohorts and retention curves, a tool like Mixpanel fits better and we say so in our comparison. And the thresholds behind get_changes are fixed server constants for now. If they prove too chatty or too quiet in practice, tuning them is a one-line change on our side, not a prompt change on yours.

The tracking side has not changed: a 2 KB cookieless script, no consent banner needed, no personal data stored. The whole release lives behind the same script you may already have installed.