connect your analytics to cursor and claude code with mcp

an analytics mcp server lets your editor talk to your analytics directly, so you can ask real product numbers from inside cursor or claude code without opening a dashboard. smolanalytics is an mcp server with 47 tools. you run smolanalytics connect cursor, and then you either ask questions ("how many signups last week") and get the real answer in your editor, or you tell the agent to instrument your app and it writes the track() calls for you. your own model runs the query, so the ai part is free.

a dev told me it took him a while to figure out this even existed, that smolanalytics connects over mcp. that's on me for not making it obvious, so here's the whole thing in one place.

what is an analytics mcp server?

it's an analytics backend your coding agent can call as tools. mcp (model context protocol) is the standard cursor and claude code use to reach outside tools. smolanalytics ships as an mcp server exposing 47 tools, so the agent can run reports, look up events, read your tracking plan, and write instrumentation. the practical result: your product numbers live one sentence away from the code that produced them, instead of behind a browser tab and a context switch.

most "analytics" mcp setups just wrap a rest api and let the model guess. smolanalytics doesn't guess. every answer is a deterministic report with a receipt (more on that below).

how do i connect it to cursor or claude code?

one command. for a local self-hosted instance:

smolanalytics connect cursor

or for claude code:

smolanalytics connect claude

that writes the mcp config into the right place for you. if you're on smolanalytics cloud instead of a local binary, point it at your instance with a host and key and it spins up a local proxy:

smolanalytics connect cursor --host https://you.smolanalytics.com --key sk_...

the proxy is there because cloud auth shouldn't leak into your editor config. it runs on your machine, holds the key, and speaks mcp to the editor on one side and https to your instance on the other. restart the editor once and the 47 tools show up.

what can i actually ask it?

ask in plain english and you get the real number, not a guess. a few that i use constantly:

how many unique visitors in the last 7 days, split by source?
which pages have the most rage clicks this week?
did signups drop after the pricing page change on tuesday?
show me the funnel from landing to checkout, last 30 days.

each answer comes back with a computed_by receipt: the exact deterministic report and scope behind the number. so when the agent says "412 signups," you can see it ran the signups report scoped to last week, not that it summarized a vibe. you can paste the number into a standup and it'll survive someone re-running it.

can the agent instrument my app for me?

yes, that's the other half and honestly the better half. you don't write tracking code. two things cover most of it.

first, autocapture already records pageviews, clicks (with the full $elements selector chain), scroll depth, engagement, rage clicks, dead clicks, form submits, and js exceptions the moment the snippet loads. zero code. so a lot of what people bolt on manually is already sitting in your data.

second, for the custom business events autocapture can't name, the agent does it. over mcp it calls propose_instrumentation, which reads your repo and writes the actual track() calls where they belong, then verify_instrumentation, which proves each event actually fires. it's cloud-aware through that same local proxy. you review the diff like any other pr. no more "we shipped the feature but forgot the event and now the funnel has a hole for three weeks."

and if you'd rather not touch code at all, there's the retroactive move: name a business event from clicks you already captured. call it "clicked upgrade button," point it at the element, and it's retroactive to the day you installed. no code, no agent, no waiting for data to accrue.

how do i know the ai isn't hallucinating numbers?

there's a ci test that makes hallucinated numbers structurally impossible, not just unlikely. it's the agreement test: it asserts the ai's answer equals the /v1 api response equals the dashboard, byte for byte, for the same query. if those three ever disagree, ci goes red and the build stops. you can read it here: github.com/Arjun0606/smolanalytics/blob/main/internal/api/agreement_test.go.

on top of that there's plan-as-code. your tracking plan is a committed file. plan check --code catches drift statically against your source, the traffic-based check catches events that stopped firing in prod, and plan sync keeps the file honest. so the agent isn't inventing an event schema in its head, it's reading the same plan your ci enforces.

put together: the model phrases the question, a deterministic engine answers it, and a test guarantees the phrasing and the engine can't drift apart. the ai is a translation layer, never the source of the number.

why run your own model here?

because it makes the ai free and keeps your data yours. the query runs against your instance with whatever model you've already got wired into cursor or claude code. smolanalytics doesn't sell you tokens or route your events through a third party's llm. self-host the single go binary under mit and you own the data outright, or take cloud pricing that's flat: solo $9, up to business $499, $5 per extra million events. importers exist for posthog, mixpanel, umami, and csv, so switching isn't a rewrite.

no session replay, no feature flags, no heatmaps, no surveys. that's on purpose. it does analytics you can ask, and it does it honestly.

try it: self-host the binary free under mit, take cloud from $9, or poke the live demo at smolanalytics.com. then run smolanalytics connect cursor and ask it something.