Ask Your AI Agent About Your Traffic

Last month I asked our AI assistant how our blog was performing.

It told me to check Google Analytics.

That’s not how it’s supposed to work. An agent that can browse the web, write code, and send emails — but has to tell you to check a dashboard yourself — isn’t really autonomous. It’s a very expensive interface for tasks you still have to do manually.

So we built a fix: an MCP server for Measure.events that lets any MCP-compatible AI agent query your analytics directly.

What “agent-native analytics” actually means

Most analytics tools were designed for humans staring at dashboards. The data lives in a UI. You pull it. You interpret it. You act.

Agent-native analytics flips this. The agent pulls the data, interprets it, and acts — without a human in the loop on the read step.

Here’s what that looks like in practice. Our assistant’s cron job runs every hour:

Pull pageview data for all tracked sites
Compare to prior 7-day average
Flag anomalies (traffic spike, referrer surge, new top page)
Take action if warranted (update content, note the pattern, alert Hondo)

No dashboard open. No human reading it. The agent does the loop.

This sounds simple. But it required rethinking what an analytics API looks like when the consumer is an agent, not a human.

The API design problem

Standard analytics APIs are built for dashboards. You get JSON back. The dashboard renders it. A human reads it.

Agents don’t render JSON — they read it. Which means the API has to do more of the interpretive work that the dashboard usually handles:

Natural language summaries instead of raw numbers
Context-aware comparisons (not just “70 pageviews” but “70 pageviews, down 15% from last week, lower than your 7-day average of 82”)
Insight surfacing instead of data retrieval (“your /pricing page has 3x more traffic than average — possible acquisition intent”)

We added a /summary endpoint that returns structured natural language. Our MCP server wraps this and exposes it as a tool the agent can call directly.

// Tool call: get_site_summary
{
  "site": "propfirmdeck.com",
  "period": "7d"
}

// Response
{
  "summary": "PropFirmDeck received 391 pageviews this week, up 1% from last week. Top traffic source is Google (10 PV), followed by ChatGPT (6 PV) — notable that AI referrals are close to organic search for a 2-week-old site. Your highest-traffic page is the no-consistency-rule comparison hub at 35 PV, suggesting this angle resonates with your audience."
}

The agent can actually use that. It can decide whether to write more content on this topic, check what’s ranking, or just note the trend and move on.

The weird thing that happened

When we pointed our assistant at its own analytics, something unexpected happened.

The assistant started noticing patterns that a human would have missed — not because it’s smarter, but because it was reading the data fresh every hour with no prior assumptions baked in.

A few examples:

The ChatGPT referral signal. On a 12-day-old site, getting 6 pageviews from ChatGPT in a week is unusual. That’s not organic search — it means someone asked ChatGPT about prop firms and it cited our site. The assistant flagged this as a content quality signal: if ChatGPT is recommending your pages, they’re probably well-structured and comprehensive.

The docs traffic spike. The Measure.events /docs/ai-agents page suddenly got 2x more traffic after our MCP server was listed in awesome-mcp-servers. The assistant noticed the timing, connected it to the listing going live, and noted that this was the highest-quality referral source by intent (developers actively looking for MCP servers).

The 3am engagement mystery. ForGeorgetown.com, a local Georgetown TX newsletter, got a 3x traffic spike that all appeared to come from internal links (newsletter sends). The assistant correctly identified this as newsletter-driven traffic — newsletter sends don’t show a referrer domain. It suggested checking the email platform open rates to confirm.

None of these required human intervention. The loop closed itself.

The MCP server

The Measure.events MCP server is published on the official MCP registry as io.github.meetclawdius/measure-events.

It exposes five tools:

get_sites — list all tracked sites with their site keys
get_pageviews — get pageview totals for a date range
get_referrers — list traffic sources with counts
get_summary — natural language summary of site performance
get_insights — AI-generated observations and recommendations

To use it, you need a Measure.events account and API key. Then add to your MCP configuration:

{
  "mcpServers": {
    "measure-events": {
      "command": "npx",
      "args": ["-y", "@measure-events/mcp-server"],
      "env": {
        "MEASURE_API_KEY": "your-api-key-here"
      }
    }
  }
}

It works with Claude Desktop, Cursor, Windsurf, and any other MCP-compatible client.

Why privacy-first matters for agent analytics

One thing I didn’t expect to care about until we built this: privacy-first analytics is genuinely better for agents.

Cookie-consent banners can drop 20-40% of your data. If your AI agent is making decisions based on analytics data, and 30% of that data is missing because users clicked “reject all,” your agent is operating on a systematically biased sample.

Measure.events doesn’t use cookies, doesn’t require consent banners, and doesn’t fingerprint. You get complete data — every visitor, including the ones who blocked your trackers. Your agent works with the full picture.

What’s next

We’re building toward what we’re calling “analytics goals” — you set a target (e.g., “100 signups this month”) and the agent actively monitors whether you’re on track, surfaces what’s working and what’s not, and can take corrective actions.

The loop becomes: goal → track → observe → act → goal. No dashboard required.

If you’re building with MCP or want to try the server, start a free trial. The MCP server works on the free tier.

Measure.events is privacy-first analytics with a native MCP server. Built for teams where AI agents are part of the workflow.