--- title: "How to Connect MCP to Analytics Tools" description: "Query product data in plain language over MCP, with the read-only boundary that keeps it safe, and the checks that separate a right answer from a fluent one." canonical_url: "https://builderscamp.com/guides/tools/mcp-for-analytics-tools" date_published: "2026-09-18" date_modified: "2026-09-18" author: "Andre Albuquerque, Mário Araújo" publisher: "Builders Camp" guide_class: "tools" --- # MCP for analytics tools, and the read-only boundary that keeps it safe **TL;DR:** Analytics over MCP replaces the weekly assembly job, not the dashboard: you ask the question in plain language and get a follow-up in the same thread. The boundary that makes it safe is read-only enforced at the database, as in Supabase's server, which runs every query as a read-only Postgres user. The boundary nobody sets is the one that decides whether the answer is actually right. ## What does a conversational query actually replace? Not the dashboard. The assembly job around it. The weekly ritual is familiar: open the analytics product, filter to last week, export, open the database client for the number the product does not track, check the error tool for anything that would explain a dip, then write four sentences. Most of that is mechanical, none of it is judgement, and all of it gets redone identically seven days later. An MCP connection collapses that into one thread. The part that matters is not speed, it is the follow-up. A dashboard answers the question it was built for. When the number moves and you want to know which segment moved it, the dashboard sends you to build another dashboard. A connected assistant answers in the same breath, which is the first genuinely new thing this category offers. ## Which servers reach product data, and what do they cover? PostHog runs a hosted endpoint at mcp.posthog.com/mcp that its own documentation describes as letting an agent use PostHog through plain text questions. It covers analytics queries including HogQL, error triage with stack traces from inside an editor, and feature flag and experiment management, and it both reads and writes. It routes to the correct data region, US or EU, based on the account you sign in with. Supabase publishes a server for your own application database, which is the one to reach for when the question is about your data rather than your event stream. Sentry's server at mcp.sentry.dev/mcp covers error search, performance analysis and issue triage over OAuth, with optional scoping down to an organisation or a single project. Notice what PostHog bundles: analytics questions and feature flag management behind the same connection. Nothing is wrong with that, and it is worth seeing before you connect rather than after, because "answer a question about retention" and "change which users see a feature" are not the same risk. ## What does read-only actually mean here? Supabase's documentation is the clearest example in the category, and its opening line is a warning rather than a feature: connecting a language model to your projects carries security risks. Its read-only mode is a URL parameter that executes every query as a read-only Postgres user, and its project scoping parameter pins a connection to a single project so the assistant cannot reach data in the others. The mechanism is the part to copy. Read-only is enforced by the database, not by the assistant agreeing to behave. A guardrail the model could be talked past is a suggestion. A guardrail enforced by the system underneath is a boundary, and the protocol's own security guidance makes the same argument in general terms when it asks servers and clients to start from a minimal scope and widen only when a specific operation demands it. Supabase's production guidance is worth adopting whatever your stack: connect to production only when the task genuinely requires production evidence, and use the narrowest query that answers the question. ## The boundary that read-only does not give you Read-only stops the assistant changing your data. It does not stop your data changing the assistant. Supabase names the mechanism directly: content sitting in the database can carry instructions that steer the model into doing something you did not ask for. Any product where outsiders can write text you later query is exposed to this. A support ticket body, a user-submitted company name, a feedback field. The protocol's security guidance takes the same position at the level of tool descriptions, treating text arriving from a server as untrusted unless the server itself is trusted. The practical consequence is small and specific. Treat an answer built on free-text customer content the way you would treat a quote from an anonymous source: usable, attributable, and not something you act on without looking at the underlying rows. ## Which account and which environment should the connection use? Two decisions get made by default if you do not make them, and both are easier to set correctly on day one than to unwind in month three. The account decides the scope. A connection authenticated as you inherits everything you can see, which for anyone with an analytics admin role is far more than the question needed. Where the product supports it, authenticate with an identity created for this purpose, with access to the projects the question touches and nothing else. The side benefit is an audit trail that distinguishes a query run by an assistant from a query run by a person, which is the difference between investigating an anomaly in ten minutes and in a day. The environment decides the cost of being wrong. A staging copy answers questions about shape, schema and whether the query is well formed. Production answers questions about what actually happened. Most exploratory work is the first kind, and Supabase's own guidance points the same way: reach for production when the task requires production evidence, not as the default connection. ## How do you tell a right answer from a fluent one? Three checks, none of which needs you to write SQL. Ask for the query alongside the result, every time. You are not auditing the syntax, you are checking whether the filters match the question you asked. Most wrong answers are right answers to a slightly different question. Re-run with one dimension changed and confirm the number moves the way you expect. If weekly active accounts for last month and the month before are within one percent of each other and you know you ran a migration in between, something is being filtered out. Anchor one figure to something you already trust. A revenue number from finance, a signup count from the invite log. One anchor per session catches the class of error where a whole query is correct but pointed at the wrong table. ## When is a dashboard still the right answer? When the number is one you will look at every week for a year. A fixed definition rendered identically is what makes a trend legible, and a query regenerated conversationally each time quietly changes definition as your phrasing drifts. Keep the standing metrics on a dashboard and send the one-off questions through the connection. The failure underneath all of this is not the tooling. It is definitions. If activation means three different things across your instrumentation, a connected assistant will produce three defensible numbers and explain each one convincingly. That is an instrumentation problem, and it is what Builders Camp's Product Analytics bootcamp works on directly, over 1 week with 2 live sessions and 9 microlessons under Mário Araújo, covering how to define events, user properties and group properties in a B2B product, what a real activation moment looks like, and how cohort retention separates healthy accounts from churn risk. Data for Product Managers is the broader version, 2 weeks with 4 live sessions and 8 microlessons on metrics, funnels, cohorts and experiments. Building with Claude Code covers the connection layer itself, naming MCP and tool integrations in its syllabus. [See the Product Analytics bootcamp](https://builderscamp.com/bootcamps/product-analytics?utm_source=guide&utm_medium=organic&utm_campaign=mcp-for-analytics-tools) A first week worth running: pick the single number you currently assemble by hand every Monday, connect one read-only server, and answer it both ways for four weeks. If the connection never disagrees with you, it saved you an hour a week. If it does disagree, the interesting work is finding out which of you was right. For the version of this that runs inside a coding agent, [pulling data without SQL in Claude Code](https://builderscamp.com/guides/tools/claude-code-data-pull-without-sql) and [metric analysis in Claude Code](https://builderscamp.com/guides/tools/claude-code-metric-analysis-for-pms) go deeper, and [MCP for product managers](https://builderscamp.com/guides/tools/mcp-for-product-managers) covers the protocol underneath. ## Frequently asked questions ### Which analytics products publish their own MCP server? PostHog runs a hosted endpoint at mcp.posthog.com/mcp covering analytics queries, HogQL, error triage and feature flag and experiment management. Supabase publishes a server for querying your own application database. Sentry runs one at mcp.sentry.dev/mcp for error search, performance analysis and issue triage. Check the vendor's own documentation rather than a directory, because this list changes. ### What does read-only mode actually do? In Supabase's server it is a URL parameter that runs every query as a read-only Postgres user, so the restriction is enforced by the database rather than by the assistant's good behaviour. That distinction matters: a restriction the model could talk its way past is not a restriction. ### Can I point one of these at production data? Supabase's own guidance is to connect to a production project only when the task requires production evidence, and then to use project scoping, read-only mode, restricted feature groups and the narrowest query that answers the question. That is a good default whatever the product, because most questions a product manager asks can be answered from a subset. ### Does read-only make the connection safe? It makes it non-destructive, which is not the same thing. Supabase names prompt injection as the primary risk: instructions hidden in content already sitting in your database can steer the model. Read-only limits what that steering can do, and does not stop a poisoned summary from reaching a slide. ### How do I check an answer I cannot verify by hand? Ask for the query, not just the result. Then re-run it with one dimension changed and confirm the number moves in the direction you would expect. Then check one figure against something you already know is right. Three cheap checks catch most confidently wrong answers. ### Will this replace our dashboards? No, and trying is how teams lose their baseline. A dashboard is a fixed definition rendered the same way every week, which is what makes a trend readable. A conversational query is better at the one-off question a dashboard was never built for, and at the follow-up question that a dashboard cannot answer at all. ### What is the biggest failure that has nothing to do with the tooling? An inconsistent event taxonomy. If activation is defined three ways across your instrumentation, an assistant querying it produces three defensible numbers and a fluent explanation of each. Connecting a server to unclear definitions accelerates the disagreement rather than resolving it. ## Sources - [PostHog: Model Context Protocol](https://posthog.com/docs/model-context-protocol) - [Supabase: Model context protocol (MCP)](https://supabase.com/docs/guides/getting-started/mcp) - [Sentry: Sentry MCP Server](https://mcp.sentry.dev/) - [Model Context Protocol: Security best practices](https://modelcontextprotocol.io/specification/2026-07-28/basic/security_best_practices) ## How this guide was made Researched from Builders Camp's bootcamp, track and masterclass material and the sources listed on this page, drafted with AI, and fact-checked against every source cited.