The Mixpanel MCP server: Q&A with the engineer and PM teams who built it

Building an MCP server is one thing. Stress-testing it against real teams with messy data, ambiguous taxonomies, and cross-tool workflows nobody scripted in advance is where things get interesting.

We went to the Mixpanel team who did both: Sharan Multani (Staff Product Manager for MCP), Sonya Park (Engineering Manager), and Gonzalo Gonzalo Lopez Bascur (Senior Software Engineer). What follows is a look at how the Mixpanel MCP server works, what it took to get it right, use cases, and more.

Sharan: A lot of teams talk about self-serve analytics, but still end up with one or two people fielding data requests for everyone else. The tool isn't really the problem. The problem is getting a reliable answer still requires knowing which events to look at, how to build the right report, and whether the numbers you're seeing actually mean what you think they mean. Most non-technical stakeholders hit one of those walls and either ask someone else or give up.

The MCP server isn't generating data. It's querying the same compute layer that powers the Mixpanel UI. The data that comes back goes through our standard processing pipeline, so you're getting the same clean, trusted numbers you'd see in a report. The gap MCP closes is the one between having a question and knowing how to answer it yourself.

Gonzalo: There are two noticeable steps. The first is experimentation where you try simple things like, "What was the most common error in the last 24 hours?" and check that the results make sense. If that goes well, you start to trust it.

The second step happens when you're working on something real and you remember the MCP server exists. You give it a shot on an actual problem rather than a test. In my experience, if that works, you stop looking at it like a new toy and begin using it every day. That’s the shift when teams realize the true value.

Sharan: We're doing both, but they serve different use cases. The in-app experience is Mixpanel-scoped. Our MCP server is composable. A single conversation can pull Mixpanel data, search a codebase, check a Notion doc, and update Lexicon. That cross-platform workflow is something an embedded chatbot fundamentally can't do because it only has access to one tool. MCP puts Mixpanel into the user's workflow instead of asking the user to come to ours.

Sonya: MCP tools are more versatile and applicable across a wider range of AI clients, including Cursor for coding workflows. It also supports full CRUD at this point, not just querying. It integrates with tools your team already uses and brings Mixpanel into that context.

Gonzalo: With our MCP server, we give customers the tools and they choose the brain they want to use. It also lets customers build their own agents and try any configuration they want. As an example, someone could wire together Mixpanel, Notion, and Figma in the same workflow. Two quick examples of how I’ve used it are with Slack and Notion.

With Slack, I prompt the MCP server with, “See the activity my app had yesterday and publish a message in Slack with the most visited item.” And then with Notion, I say “Read this report (link) and create a Notion doc with the 5 actions we should take to improve <specific metric>.”

Sonya: Hallucination isn't really an issue for MCP the way people assume. The server takes in serialized data, JSON responses, and turns that into natural language, or converts natural language into tool arguments. It's not generating data from nothing.

Sharan: I’d agree that the real risk isn't hallucination. It's the model picking the wrong event because your taxonomy is ambiguous. That's why investing in data governance (clean naming, descriptions, tags in Lexicon) pays off more now than it ever has.

Gonzalo: I’ll add that we also built a validation layer into the MCP server. We expose JSON schemas to the model with the parameters we expect, but sometimes it still sends incorrect data. Rather than surfacing that error to the user, we want the model to auto-correct, so we always return actionable errors it can actually use. 

For example, if an unsupported report type is requested, the server returns something like: report.type: 'barchart' not supported, value must be insights|retention|funnels|flows. Or for a funnels query with a bad chart type: 1 validation error for FunnelsQueryResult chart_type — Input should be 'ttc', 'frequency', 'trends' or 'steps'. The model reads that, self-corrects, and retries. Most of the time the user never sees any of it.

Sonya: Our MCP server follows the same permissions and resource management we use for the entire Mixpanel web app.

Sharan: The governance story here is additive, not new. If you've already configured Data Views, classified sensitive properties, and scoped project access, the MCP server respects all of it. You're not redoing governance for a new surface. That's a deliberate design choice: every way to access Mixpanel data (UI, API, MCP) inherits the same trust layer. What our MCP server does is compress the time it takes to discover governance gaps that were already there.

Sharan: One line between assistant and agent is the ability to write back. An assistant surfaces answers. An agent acts on what it finds. MCP now supports full CRUD—creating dashboards, tagging events, hiding stale data. When the AI finds undocumented events and fixes them in the same conversation, that's not answering a question. That's closing the loop for everyone on your team.

Sonya: In my opinion, we've already crossed over to "agent." The model can auto-correct and expand based on MCP responses without waiting to be asked. Using it as an assistant is good, but requires more human intervention. Using it as an agent saves human time.

Gonzalo: Agent is the natural next step. Most teams start with an assistant approach, but once you see what it can produce, the follow-up thought is usually the same: "Wouldn't it be nice if I got this report every day?" or "I'd love a notification when X happens." That's when you've crossed into agent territory.

Gonzalo: The impact is significant. With the MCP server you can create Mixpanel dashboards and reports with zero clicks in the product. You don't have to select events, set filters, pick a time range, or interact with the UI at all. You describe what you want, Claude (for example) shows you a report, and if it's right, you’re done. Analysts can focus entirely on the analysis instead of the mechanics of building it.

For instance, I wanted to monitor the tool Run-Query closely because it’s one of the most popular tools in the MCP server. Instead of creating a dashboard from scratch, I prompted Claude with, "We have MCP data in project 'MCP Project'. I recently added Run-Query that’s very popular and I want you to create a Mixpanel dashboard to monitor this new tool. Be creative, but at the very least I want to see errors, error messages, and latency.” It spun up a Mixpanel dashboard in minutes and has become one of my go-to dashboards.

Mixpanel’s MCP server is available for all customers in every region. Existing customers can turn it on in Org Settings. New to Mixpanel? Create a free account and connect it with the AI tools you already use.