Why We Built an MCP Server Before We Built a Slack Integration
Every analytics vendor has a Slack integration. We deliberately built ours last, and shipped the MCP server first. Here's the reasoning.
In product analytics, the standard integration order is Slack first, everything else later. Send an alert to a channel when a metric breaks. Drop a daily KPI digest. Let someone slash-command a query. Half of every competitor’s homepage screenshots are “look, the answer arrived in Slack.”
We shipped our Slack integration months after our Model Context Protocol server. That ordering was deliberate, and the reasoning is worth writing down because we don’t think it’s been articulated well anywhere else.
Slack integrations solve the wrong problem
The implicit pitch of an analytics-to-Slack integration is: “you don’t have to open the dashboard.” But that’s not really true. The Slack message tells you something happened. The actual work — figuring out what happened, which segment broke, whether it’s a real signal or noise — still requires opening the dashboard, running queries, slicing the data.
So the Slack integration is a notification layer, not an answer layer. It’s a doorbell, not a doctor.
For the past decade, doorbells have been the best you could do. The dashboard required a human to drive it, so the integration’s job was to get the human’s attention. That ceiling has now lifted.
What an MCP server actually changes
The Model Context Protocol lets an AI client — Claude Desktop, Cursor, Zed, whatever the user already has open — call tools on a remote server. When you expose your analytics data as MCP tools, you’ve changed the interaction model: the human asks a question in natural language, the assistant calls a sequence of tools (list events, query a funnel, break down by a property), and a synthesised answer arrives.
The difference from a Slack integration is qualitative, not incremental:
| Slack integration | MCP server |
|---|---|
| Pushes notifications when a rule fires | Answers arbitrary questions on demand |
| Constrained to pre-built alerts and digests | Composes queries the engineer didn’t anticipate |
| Tells you something is wrong | Tells you what’s wrong and which segment is affected |
| Requires you to context-switch to the dashboard | Answers in the tool you already had open |
The honest version of why every analytics vendor built Slack first is path dependence — Slack integrations have existed since 2015, the API is well-trodden, the engineering is straightforward. MCP is two years old. It’s just newer.
But “newer” is not the same as “less important.” For the specific job of getting analytics answers to a human, an MCP server is closer to the right shape than a Slack bot ever was.
What we found shipping it
A few things we didn’t fully expect:
Engineers stop opening the dashboard for one-off questions. “What’s our D7 retention this week?” used to be a context switch — open dashboard, find chart, set date range. Now it’s a sentence in Cursor between commits. The dashboard is for exploration; the assistant is for answers.
The questions get better. When asking a question is cheap, people ask more of them. We’ve seen power users ask three or four follow-ups in a row that they would never have bothered to run as separate dashboard queries. “OK but break that down by plan tier” is a sentence away, not a five-minute detour.
Read-only is the right default. Our MCP tokens are scoped per project and read-only by default. There is no scenario in which an AI assistant should be writing to your analytics store, and we made that hard to even configure.
It does not replace the dashboard. People who thought the MCP server would mean nobody opens the UI were wrong. Visual exploration of a funnel, scrubbing a session replay, configuring an experiment — these are still UI jobs. The MCP server replaces the “I have one specific question” trip to the dashboard, which turns out to be most trips.
Why this isn’t just a feature, it’s a position
The category default is to bolt an “AI assistant” onto the dashboard sidebar. There’s now one in Mixpanel, one in Amplitude, one in Heap, all functionally similar — a chat widget that calls the same backend.
That model loses to MCP for one reason: it forces the user to come to the analytics tool. The analytics tool is not where the user is. The user is in Cursor, in Claude Desktop, in their IDE, in their notes app. An MCP server meets them there.
Shipping a chat widget in our own dashboard would have been faster, easier to demo, and — strategically — wrong. The product surface that matters for AI-assisted analytics is the one the user has already chosen, not the one we wish they’d choose.
The Slack integration is live now, by the way. It’s a doorbell. It’s good at being a doorbell. But the doctor lives somewhere else.
MCP setup is a three-line config. Drop it into your client and ask your first question.