The analytics MCP server your AI can't fake.

Writing events down is solved, solved well, and mostly free. PostHog's collector is excellent, GA4 is already on your page, Plausible is a good pen, and ours is a snippet like everyone else's, so we are inside that kernel too and not above it. Nobody has a collection problem. Every tool in this category is a very good pen. None of them is a reader.

So you remove nothing. Keep PostHog, GA4, Mixpanel, Amplitude, Umami or Plausible switched on, add one snippet, and your agent brings your history across in one call: migrate_from pulls straight from PostHog or Mixpanel with a key you paste, over a date range you name, dry-run first, and a re-run replaces rather than duplicates because the vendor's own event ids come across. The key is used for that one pull and never stored. Amplitude and Umami arrive as an export file rather than a keyed pull.

To be exact about the boundary, because it matters: there is no continuous sync from any vendor and we do not read your PostHog live. The true sentence is that you remove nothing, you add one snippet, and your agent pulls your PostHog or Mixpanel history across in one call. Everything that connects is listed on integrations.

smolanalytics is a single-binary analytics engine that does web and product analytics from one snippet: visitors, referrers, UTM, funnels, retention, paths, and cohorts. On top of that data it speaks the Model Context Protocol, the open standard for connecting AI assistants to external tools. That makes it an analytics MCP server: it publishes your metrics as 97 callable tools and 15 prompts, so the model in your editor can fetch a funnel or a retention curve the same way it calls any other MCP tool.

There are two ways to ask, reading the exact same reports: a plain-english ask bar inside the dashboard, and your own coding agent over MCP for code-aware questions in the window where you already work. What each surface is for is spelled out on how it works, and the term itself is defined on the MCP analytics server glossary page.

Your AI assistant admits it can hallucinate your numbers. This one can't. Three things make the answer trustworthy, and they are the whole reason to use it over a chatbot pointed at a spreadsheet:

• 1Computed, not generated. Each tool returns a value from the same deterministic report the dashboard renders. The language model phrases the reply, but the figure itself is calculated from your events, never invented by the model.
• 2Pinned to one computation. A test in the build asserts the answer an assistant gets over MCP equals the number the dashboard shows. If they ever drift apart, the build fails. Your editor and your dashboard can't disagree, by construction. Don't take our word for it, watch the surfaces agree on the proof page →
• 3Bring your own model, so the AI is free. The AI already in your editor (your Cursor, Claude, or VS Code subscription) does the asking. The MCP server just answers with computed numbers, so there is no second AI bill from the analytics tool.

That is the difference between "the model guessed a plausible number" and "the model read the real number and read it out loud." A bare chatbot can do the first. Only an MCP server backed by computed reports can promise the second.

smolanalytics is an investigator, not a query surface, and the MCP surface carries that: you don't have to know which question to ask. Three tools do the heavy lifting:

• 1investigate returns the whole desk in one call: the single most expensive finding, the queue with a status on each (needs you, watch, fix first, recovered, verified, acted, auto-reverted), the quarter's metric movements with multiple-comparison correction, and an honest below-detection-floor note when your product is too small to call.
• 2backtest replays your history through the same investigator with the clock moved back: every finding dated by the day it would first have surfaced, so you can see what it would have told you last quarter before you trust it with this one.
• 3mark_finding_acted closes the loop without leaving the editor: tell it you shipped a fix, and when the metric recovers the finding upgrades to verified, you acted on a date and the metric recovered within N days. Acted but still down says so, honestly.

> using smolanalytics, investigate
  1 finding needs you: checkout conversion down 22% since Tue's deploy (correlation, not proof)
> I just shipped a fix for that
  marked acted. I'll report it verified if the metric recovers.

explain_change, fix_brief, and the rest of the report tools are still there when you want one number, and what the desk itself looks like is on how it works.

Computed metrics tell you the re-ask rate. They can't tell you what people were asking about. That needs a model to read the words, and the usual answer is to run one server-side over every message and meter you per message. We don't run a model at all. Yours is already connected over MCP, so it does the reading:

• 1sample_conversations hands your model a sample of whole conversations, your agent_turn events grouped by conversation_id, oldest turn first. Capped and deterministic: same data in, same sample out. Turns only carry text if your app sent a text property, so nothing is invented about what was said.
• 2label_conversation writes its inference back, one label set per conversation (intent, sentiment, frustration, whatever you asked about). It appends a new agent_label event; nothing already recorded is ever mutated. Naming the model that labeled it is required.
• 3agent_labels counts conversations per label value. This part is computed deterministically from your event log, so GET /v1/agent/labels, the MCP tool, and the dashboard cannot disagree.

> using smolanalytics, sample my agent's conversations and label them by intent
  read 20 conversations, wrote 20 agent_label events (labeled_by: your model)
> what are people asking my agent about?
  intent: billing 41 · bug report 22 · pricing 9 · 31 conversations still unlabeled

Keep the split straight, because we do: the label values are that model's inference, and every result names the model that wrote them alongside how many conversations are labeled and unlabeled, so a guess is never dressed up as a measurement. The counts over those labels are computed, same engine as every other number. And because the model is one you already pay for, this is free and unmetered on every plan.

There is one connection, not one per project. Settings hands you an organization API token pointed at smolanalytics.com/api/mcp; paste that single copy block into your editor and you are wired. From there your agent provisions new analytics with create_project (no browser) and queries or manages any project by passing project="<name>" to any tool, which routes to that project's own instance for you. The secret read key stays server-side, so you never handle a key, and the token persists, set it up once:

claude mcp add --transport http smolanalytics https://smolanalytics.com/api/mcp \
  --header "Authorization: Bearer <your-org-token>"
# then: "using smolanalytics, create_project acme" or
#       "what's the signup to paid conversion for project acme?"

Scope the token to a single project with ?project=<id> or to reports only with ?read_only=true.

From there you ask your metrics in the same window you write code, and the 97 tools and 15 prompts are identical in every editor. Exact per-editor config is in the docs, and the Cursor / Claude walkthrough is on the Cursor page.

Your analytics questions arrive while you write code, not while you stare at a dashboard. So ask them where you already are:

The 97 tools cover funnels, retention, paths, cohorts, channels, agent tool-call and conversation health, the sample-and-label loop above, and the investigation itself: investigate for the whole desk in one call, and what to fix first; the 15 prompts are ready-made investigations you can trigger by name. See the full list on every feature.

The dashboard, ingestion, and the MCP server are all one engine: no Kafka, no ClickHouse, no Postgres, which is why every project gets its own isolated instance. The live demo is a populated instance you can ask right now, no account. When you want your own, the 14-day trial provisions one in about a minute, no card.