analytics for apps built with cursor or claude code (over mcp)

if you built the app with cursor or claude code, the thing you are missing is not another place to collect events. collection is solved, solved well, and mostly free. posthog's collector is excellent, ga4 is already on the page, and ours is a snippet like everyone else's. every tool in this category is a very good pen. none of them is a reader. that is the gap: your event log is write-only, and nobody ever goes back and reads it.

an analytics mcp server closes it, because it lets your editor talk to your analytics directly, so you can read your real product numbers from inside cursor or claude code without opening a dashboard. and you do not have to replace anything to do it: keep posthog, ga4, mixpanel or plausible where they are, and bring your history across in one call with migrate_from (a keyed pull from posthog or mixpanel over a date range you name, dry-run first, and the key is never stored; amplitude and umami arrive as an export file instead). there is no continuous sync from any vendor, so do not let anyone tell you otherwise. smolanalytics is an mcp server with 97 tools. you run npx 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 npx 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 97 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:

npx smolanalytics connect cursor

or for claude code:

npx smolanalytics connect claude

that writes the mcp config into the right place for you. to point it at your instance explicitly, pass the host and key and it spins up a local proxy:

npx 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 97 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. and every answer carries a computed_by receipt naming the exact report and parameters behind it, so you can re-run the number yourself.

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 own isolated 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, and pricing is flat: Pro $19 or Scale $49, $6 per million events. importers exist for posthog, mixpanel, amplitude, umami, csv, and jsonl, so switching isn't a rewrite, and your data exports in one file any time, so leaving isn't either.

it ships flags, experiments, heatmaps, surveys, and a session inspector too, all from the same install; the one thing it does not do is pixel-perfect DOM session recording, and that's on purpose. it does analytics you can ask, and it does it honestly.

try it: the trial is 14 days at Pro limits, no card, then from $19, or poke the live demo at smolanalytics.com. then run npx smolanalytics connect cursor and ask it something.