Ask Your Analytics in Plain English with MCP

You can ask your web analytics questions in plain English by connecting an AI assistant (Claude, ChatGPT, Cursor or Claude Code) to an analytics MCP server. The Model Context Protocol (MCP) is an open standard that lets an assistant call tools exposed by another service, so instead of opening a dashboard you type “which sources grew this week, and did they convert?” and the assistant fetches the numbers, cross-references them and answers. Setup takes a few minutes: paste the server URL into the assistant, sign in, and choose what it may access.

What is MCP, in plain terms?

Before MCP, every AI app that wanted to talk to every service needed a custom integration. MCP standardizes the connection: a service runs an MCP server that describes its tools (name, description, input schema), and any MCP client can list those tools and call them. The model decides when a tool is useful, the client executes the call, and the result goes back into the conversation.

Anthropic released MCP on 25 November 2024. OpenAI, Google, Microsoft and most developer tools adopted it during 2025, and in December 2025 Anthropic donated it to the newly formed Agentic AI Foundation at the Linux Foundation. The current specification version is dated 2026-07-28. Remote servers talk over HTTP and use OAuth 2.1 for authorization, which is what makes “paste a URL and sign in” possible.

Why query analytics through an assistant instead of a dashboard?

For a single number, the dashboard is faster. The assistant earns its place on questions that need several reports combined and a bit of arithmetic: compare two periods, find which sources changed, check whether that change reached the pages that convert, and explain it. In a dashboard that is five filters, two exports and a spreadsheet. Through MCP it is one question.

How do you connect Claude or ChatGPT to your analytics?

The steps below use VisitTrack's MCP server as the worked example, because it is the one we can document precisely; other analytics vendors with MCP servers follow the same pattern with their own URL. The server URL is https://visitrack.app/api/mcp, and it is also shown under Settings → API / MCP in the dashboard.

1. 1.Claude (web or desktop): open Settings → Connectors → Add custom connector, and paste the server URL.
2. 2.ChatGPT: open Settings → Apps & Connectors → Advanced, turn on Developer mode, then create a connector and paste the server URL. Custom MCP connectors in ChatGPT depend on your plan and workspace settings.
3. 3.Claude Code: run claude mcp add --transport http visitrack https://visitrack.app/api/mcp in your terminal.
4. 4.Cursor and other clients: add the URL as a remote (HTTP) MCP server in the client's MCP settings.
5. 5.The client opens a sign-in page in your browser. Sign in, pick the site the assistant may see (one site, or all sites you can access), and choose permissions. Reading is always included; configuring goals and funnels and importing historical events are off unless you tick them.
6. 6.Approve, return to the assistant, and ask a first question such as “How did my traffic do this week?”

For clients that cannot do OAuth sign-in, or for scripts, create an API key under Settings → API / MCP and add the server with a bearer header. The API, CSV and MCP docs cover both paths, including the OAuth endpoints for client authors.

{
  "mcpServers": {
    "visitrack": {
      "type": "http",
      "url": "https://visitrack.app/api/mcp",
      "headers": { "Authorization": "Bearer YOUR_API_KEY" }
    }
  }
}

What can the assistant actually see and do?

With a read-only connection, the assistant gets one tool per report: get_stats, get_timeseries, get_pages, get_referrers, get_countries, get_devices, get_revenue, get_goals, get_funnels, get_live, get_visitor, get_people, get_site and list_events. Each takes a time window (days, or from/to) and a traffic filter: human (the default, bots excluded), bot, or all. A connection granted for all sites also gets list_sites, and every tool then takes a site argument.

With the “configure goals & funnels” permission, it also gets create_goal, update_goal, delete_goal, create_funnel, update_funnel and delete_funnel. Creating is idempotent by name, so asking twice does not create duplicates (goals are typically built on events you send, see custom events), and update and delete are flagged as destructive in the MCP tool annotations, so clients that confirm destructive actions will ask you first. Every change is recorded in an activity log with a before/after diff.

Which questions are worth asking?

Questions that combine reports, compare windows or need judgment get the most out of an assistant. A few that work well:

• “Compare the last 7 days with the 7 before them: which sources grew, which shrank, and did the growth land on pages that convert? Tell me the two numbers you are least confident about.”
• “Which landing pages bring visitors who reach /pricing, and which bring visitors who leave after one page?”
• “How much revenue came from visitors whose first touch was an AI assistant this quarter, compared with organic search?”
• “Is the drop on Tuesday real or a bot spike? Compare human and bot traffic for that day.”
• “List the custom events my site sends, then set up a signup goal and a landing → pricing → signup funnel with a 7-day window. Don't delete anything.”

The fourth question is a good habit. Bot spikes are a common cause of “mystery” traffic changes, and being able to ask for human and bot traffic separately depends on the analytics tool filtering bots at ingest (how VisitTrack's bot filtering works). The third depends on revenue attribution being set up, and on AI assistants being recognized as a traffic source (how to track AI referral traffic). The assistant can only reason about data the tool actually has. Questions about AI crawlers, such as “which pages did ChatGPT-User fetch this week?”, need server-side crawler data, which browser analytics never collects (how to track AI crawlers).

How accurate are the answers?

The numbers the tools return are exact; what the model does with them is not always. Models occasionally add up rows wrongly, confuse two time windows, or describe a 3-visitor change as a trend. Three habits keep you safe:

• Ask the assistant to show which tools it called and with which arguments, then spot-check one figure against the dashboard.
• Ask for absolute numbers alongside percentages. “Up 200%” from 2 to 6 visitors is noise.
• For anything you will act on or report, rerun the query through the REST API or CLI, which return the same data without interpretation.

Is it safe to connect an AI assistant to your analytics?

It can be, if you treat the connection like any other integration with access to business data:

• Least privilege. Start read-only and scoped to one site. Grant write access only for the session where you need it, and revoke it after.
• Untrusted text in the data. Referrer URLs, page paths, UTM values and event names are written by the outside world. A malicious referrer could contain text that looks like an instruction to the model. Good clients keep tool output separate from instructions, but don't let an assistant take destructive actions purely on the basis of what it read in your data.
• Confirm destructive actions. Use a client that asks before running tools marked destructive, and read what it is about to delete.
• Review and revoke. Check connected apps periodically; VisitTrack lists every connection with its site, scopes and last use under Settings → API / MCP → Connected apps, where Revoke disconnects it immediately.
• Know what leaves the building. Whatever the tools return is sent to the model provider as part of the conversation, under that provider's data terms. Aggregate analytics is low-risk; individual visitor journeys are more sensitive.

What else can you do with analytics over MCP?

Coding assistants make a second use case possible: implementation. In Claude Code or Cursor, with your repository open and the analytics server connected, you can ask the assistant to look at which events your site actually sends, then add the missing ones to your code, for example a signup event fired after your API confirms the account (see the Next.js analytics guide for where those calls go). Because the same assistant can then call list_events, it can check that the new event arrives.

A third is reporting. A scheduled agent can pull a weekly summary through the same tools and post it to your team channel. For fully deterministic reports, though, a script against the REST API is simpler and cheaper; keep the assistant for the questions you didn't know you would ask.