How I use the PostHog MCP in my dev loop
Connecting PostHog to my AI coding agent means product data is one question away, right where I write the code that changes it.
There is a gap between shipping a feature and knowing what it did. For years, closing that gap meant switching tabs: write code in the editor, then go dig through a separate analytics tool to find out whether the change helped. The PostHog MCP collapses that. It exposes PostHog to my AI coding agent as a set of tools, so I can ask product questions in the same place I write the code.
The setup
I connect the PostHog MCP to Claude Code. Once it is linked, the agent can reach PostHog directly: insights and dashboards, error tracking, feature flags and experiments, and raw SQL over events. No copy-pasting between the editor and a browser tab.
Asking analytics questions in plain language
Most of my monitoring starts as a question, not a query. “How many people who open the booking widget actually finish?” The agent builds or reads the funnel and hands back the numbers. Because it already has the codebase loaded, it can tie a dip to the exact component or change that likely caused it.
Checking errors around a risky change
When I touch something fragile, I ask the agent to pull recent exceptions for that area before and after I deploy. Catching a spike while the change is still fresh in my head is worth far more than finding it a week later in a report nobody opened.
Feature flags, without leaving the feature
I ship most things behind a flag. With the MCP I can check a flag’s state and rollout right where I am coding the feature it gates. The flag stops being something I manage in another tool and becomes part of the same flow.
SQL for the questions insights cannot answer
Prebuilt insights cover the common questions. For the rest, the agent runs SQL against the event data and returns exactly the shape I need. This is where the MCP earns its keep: the analysis comes to the code instead of me leaving to go get it.
Session replay to see the real path
When a funnel drops or a bug report is vague, the numbers tell me where and replay tells me why. Pulling the relevant sessions turns “it is broken” into “here is the click where it broke.”
Why the MCP specifically
The point is not that PostHog is powerful, though it is. It is that the data meets the agent where it already has context. An agent that knows both the code and the product data can reason about why a metric moved, not just report that it did. Monitoring stops being a separate tab and becomes part of the same conversation where I build.
One guardrail: in my loop it is mostly read. Creating flags or insights are deliberate, reviewed actions, and the project filters out internal and test users by default so the numbers stay honest.