Your agent reads what broke, and fixes the tracking.

An agent connected to this does three things, and it is worth being exact about where each of them runs, because two of them run on your machine and one of them cannot.

• 1It runs the suite from the editor. This is the local server, npx smolanalytics mcp, MCP over stdio. run_tests takes the URL your app is running on, drives a real browser through the accessibility tree, and comes back with a verdict per test: passed, failed (the app did not do what your sentence describes), stale (a recording stopped fitting — never a failure), errored (our runner, never your app) or flaky (failed then passed on a retry, so never counted as a pass). can_i_ship is the same run with the gaps foregrounded — the flows that were not actually verified — and list_tests says what is already covered. A passing run is recorded and replayed with zero model calls. In CI nobody runs it: a workflow file does, on every pull request, and posts one comment.
• 2It explains a failure instead of listing twelve. Same reply. Failures that share a cause — the same changed file, the same control, the same path — are grouped, so an agent reading the result fixes one thing rather than eleven copies of it. On a pull request the comment goes one step further and names the changed files it can connect to the failing test, with the string or path that connects them; a file it cannot connect is never mentioned, and zero matches means no blame at all.
• 3It writes and keeps the tracking. This is the remote server, the org connection at smolanalytics.com/api/mcp over HTTP, because proving an event fired needs the events. instrumentation_coverage names the user actions nothing measures; propose_instrumentation hands back the exact call for each site in whichever SDK the repo already runs (Google Analytics, PostHog, Plausible, Mixpanel, Amplitude or Segment), and your agent applies it with its own editor; verify_instrumentation answers FIRING, WIRED or MISSING per event; and suggest_instrumentation_fix finds where an event that went quiet was tracked. When an event in your tracking plan stops arriving but the traffic behind it doesn't, smolanalytics finds the commit that deleted the track() call and opens a pull request putting it back.

> run the checkout tests against localhost and tell me what broke
  ran 5 tests, 4 passed. one failed:
  "an expired card is refused with a message that says so" — the page said
  "something went wrong" instead of naming the card.
> anything in this repo that nothing is measuring?
  instrumentation_coverage: 3 actions with no event — payment, invite, delete

A test drives a browser against an app that is running on your laptop, on your branch, with your model key. No hosted endpoint can reach that, so the testing half speaks MCP over stdio and runs in the same place the code does. Four rules shape it, and they are the reason it is a small server:

• 1It never softens a verdict. Every tool returns the real status word, stale, errored and flaky included. An agent that reads "passed" for a stale recording tells its user the feature works, and that is worse than returning nothing.
• 2It never writes anywhere public. No pull request comment, no share link, no post to a project. An agent calling a tool is exploring; publishing that to a team channel is a side effect nobody asked for. The CLI still does all of it when a person runs it.
• 3It never spends without saying so. A run costs model calls only when a recording is missing or stale, every reply carries the cost line, and a ceiling on model calls is honoured per run.
• 4It only runs what the change could have broken, if you ask. Pass a git ref as since and the run is limited to the tests that change could have touched, with what was skipped written out. Anything it cannot rule out still runs.

> can I ship this?
  6 passed, 1 stale, 1 skipped by since.
  not verified: "a returning customer can check out with a saved card" — the
  recording stopped fitting and was not re-run. run it before you merge.

Everything. The agent writes the tracking calls inside whichever SDK your repo already runs — Google Analytics, PostHog, Plausible, Mixpanel, Amplitude or Segment — and never adds a second one beside a working one, because two SDKs on one action double-count it. PostHog's collector keeps collecting, GA4 stays on your page, Plausible keeps counting. The tests are markdown files in your repo and the recordings sit beside them, so if this has not earned its place in a fortnight you delete a folder and you are exactly where you started.

To be exact about the boundary, because it matters: we write tracking for more vendors than we can read. Telling you an event stopped firing needs the numbers, and which connection can be read is written out on integrations.

smolanalytics runs end-to-end tests that have no test code: you write a sentence describing what should work, and an agent does it in a real browser against a URL you already have. The same walk through your product is what knows which user actions exist, which is why the same tool keeps your analytics tracking correct.

Both halves speak the Model Context Protocol, the open standard for connecting AI assistants to external tools — so the model in your editor runs the suite, reads a verdict, writes a track() call or checks whether it is firing the same way it calls any other MCP tool. The instrumentation tools come with two named prompts, whole routines under one name: instrument-my-app and did-my-deploy-break-anything.

Two things need no server and no account. One test — npx smolanalytics test --url https://yourapp.com --test "the pricing page shows a monthly price" — against a URL you already have, and npx smolanalytics audit, which reads the repo you are standing in and names the user actions nothing measures, with no network call on that path at all. What each surface is for is spelled out on how it works. The setup for both halves, including the workflow file that runs the suite on every pull request, is in the docs.

An agent that just edited your app has no way to find out whether the app still works, and an agent that guesses is worse than one that does not know. Three things make the answer trustworthy:

• 1It reads the page, it does not squint at it. The agent works from the accessibility tree — the role, name and state of everything on the page — and picks an element, so the click that follows is a real locator with actionability checks. Nothing guesses a coordinate off a screenshot, which is how a run clicks the wrong thing and then blames the wrong feature.
• 2Five verdicts, kept apart on purpose. A failure is a bug report: the page, the control, and what the page said instead. Stale, errored and flaky each get their own word and are never counted as a pass or dressed up as a failure, because a suite that cries wolf about a renamed button is a suite nobody reads by month two.
• 3The tracking answer is checked, not guessed. verify_instrumentation says FIRING only when the event is arriving, WIRED when the call exists in the code but nothing has fired yet, MISSING when neither, per event. Your own model phrases the reply; the status comes from the code and the events.

Nine instrumentation tools and four deploy tools, and every one is written as the question that invokes it on every feature. The ones worth knowing before you connect:

• 1regenerate_plan_from_code rebuilds the tracking plan from the track() calls the repo actually contains, so the plan describes the code and not somebody's memory of it. define_event, list_defined_events and delete_defined_event manage the business events named from clicks already captured.
• 2event_source names the file and line an event fires from, and whether it is arriving. A count that dropped is a symptom; a missing call site is a cause.
• 3record_deploy marks that you shipped, list_deploys and delete_deploy keep that list honest, and deploy_impact answers whether last night's deploy moved an event — the mean daily count in the days after against the days before, from your own events, and it says correlation, not proof, every time. A deploy that silently kills your signup event is a tracking bug, and this is where it shows up first.

> is every event in my plan actually arriving?
  verify_instrumentation: 11 FIRING · 1 WIRED (invite_sent, no traffic yet) · 1 MISSING (plan_upgraded)
> signup stopped arriving — where was it tracked?
  suggest_instrumentation_fix: src/app/signup/page.tsx:41 — the submit handler, no track() call.
  insert: track("signup", { plan })

Two entries in your editor, because the two halves run in different places. The tests are a process your editor starts in the repo you have open:

claude mcp add smolanalytics-tests -- npx smolanalytics mcp
# then: "run the tests against http://localhost:3000 and tell me what broke"
#       "can I ship this?"

The tracking is one connection, not one per project. Settings hands you an organization API token pointed at smolanalytics.com/api/mcp, and npx smolanalytics connect writes it into whichever of Cursor, Claude Code, VS Code, Windsurf, Claude Desktop and Cline it finds installed. From there your agent works on 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: "write the tracking this repo is missing, in the SDK it already uses" or
#       "is every event in my plan actually arriving?"

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

The tools are identical in every editor. Exact per-editor config is in the docs, and the Cursor / Claude walkthrough is on the Cursor page.

The work arrives while you write code, not while you stare at a dashboard. So it happens where you already are — the first three lines run against the app you have open, the rest change your repo:

Your agent picks the tool by reading its description, the way it reads any other, which is why the descriptions are written for an agent and not for a listing. The full set, each one as the question that invokes it, is on every feature.

Three things need no account at all, and one of them is the local server. One test — npx smolanalytics test --url https://yourapp.com --test "the pricing page shows a monthly price" — against a URL you already have; npx smolanalytics audit, which reads the repo you are standing in and names the user actions nothing measures, with no network call on that path at all; and npx smolanalytics mcp, which needs a tests/ folder and your own model key and nothing of ours. npx smolanalytics guard is free in the same way: it names the env vars this repo reads that nothing declares, so a deploy does not start and then fail on the line that reads one.

The org connection is the part that needs an account, because the tracking tools need a project to verify events against. When you want one, the 14-day trial provisions it in about a minute, no card.