You can connect PostHog to Claude using the Model Context Protocol (MCP), and once it’s connected, Claude can query your product analytics, look up insights, and check feature flag state without you switching tabs to the PostHog dashboard. This guide covers what PostHog’s MCP server does, both ways to connect it — directly or through a gateway — and what’s worth checking before you point an AI client at your product data.

What the PostHog MCP server actually does

PostHog publishes a remote MCP server at mcp.posthog.com. It exposes your project’s analytics, insights, and feature flags as tools Claude can call directly, so prompts like these work against your real project:

  • “What does last week’s signup funnel look like?”
  • “Pull up the insight we built for weekly active users.”
  • “Is the new-onboarding feature flag on for more than 10% of users yet?”
  • “Summarize what changed in this event’s volume this month.”

Claude reads through the same project permissions your PostHog account already has — it’s querying live data and existing insights, not a static export you’d have to keep refreshing by hand.

The good news: PostHog’s OAuth just works

Several servers in gate’s directory — Figma, Vercel, Slack, HubSpot — currently only admit AI clients the vendor has allow-listed in advance, which can mean a connection attempt fails at the authorization step for no obvious reason. PostHog isn’t one of those. Its OAuth is open to any client that asks, so connecting it is a standard consent-screen flow with no allow-list wall to hit. If you want the general pattern behind why some servers gate this and others don’t, see the unauthorized client error, explained.

Option 1: Connect PostHog to Claude directly

Connecting PostHog on its own takes a few steps:

  • Open Claude’s connector or MCP settings.
  • Add a remote server pointing at PostHog’s MCP endpoint.
  • Sign in with your PostHog account when prompted — standard OAuth, so Claude never sees your PostHog password, and you can revoke access from PostHog’s own account settings at any time.

That’s enough if Claude is the only AI client you use with PostHog. The tradeoff shows up once a second client or a second teammate needs the same access — each one repeats the same OAuth step and ends up with its own independent grant to your project data.

Option 2: Connect it once, through a gateway

If you’re already connecting more than one MCP server or using more than one AI client, wiring each pair directly gets old fast — that’s the connection sprawl covered in what an MCP gateway is. The idea is to connect PostHog (and everything else) to one gateway URL, then point every AI client at that single URL instead of reconfiguring each one and re-running OAuth per client.

With gate specifically, connecting PostHog looks like this: add gate’s gateway URL to Claude once, then pick PostHog from the PostHog server page in the directory and sign in the same way you would directly. gate’s catalog tracks each server’s currently verified connectivity, so you know before you start whether a server is open OAuth like PostHog or allow-listed like some others. See the full list on the MCP servers page.

What to check before you connect your analytics

A PostHog project usually holds more than the one dashboard you had in mind when you connect it — every event, every cohort, every flag across the project. A few things worth checking before or right after you connect:

  • Which project is actually in scope? If your PostHog organization has more than one project — staging and production, or separate apps — know which one the connection points at before you ask Claude to summarize “our numbers.”
  • Do your events carry personal data? Event properties can include emails, names, or other identifiers depending on how your team instruments tracking. An AI client reading raw event data surfaces whatever’s actually captured, not a redacted view.
  • Who else on the team connects it? If more than one person wires up PostHog to their own client, a shared, revocable setup beats everyone holding their own grant to the same project — the same question covered in MCP access control for teams.

You can run a quick, no-signup check on any server’s tool list with gate’s free MCP security scanner, which looks for prompt injection and hidden instructions in tool descriptions before you rely on a server day to day.

Troubleshooting the connection

  • Claude can’t find an insight you know exists. Check that the connection is pointed at the right project — insights don’t carry over between separate PostHog projects even inside the same organization.
  • A feature flag reads differently than the dashboard shows. Flag evaluation can depend on the same targeting rules (cohorts, rollout percentage) the dashboard uses; double-check you’re asking about the same environment.
  • Tools disappear after a PostHog update. Remote servers can change their tool list without warning. If you’re connected through a gateway, that’s exactly what drift detection is meant to catch — see how MCP rug pulls work for why a one-time review isn’t enough.
Where gate fits: gate’s directory lists each server’s currently verified connectivity — one-click OAuth like PostHog, key-based, or allow-listed — so you know what kind of setup to expect before you start. Every server is scanned for prompt injection before it goes live, and every call goes into a plain-language log. See the full gateway at /mcp-gateway.

The bottom line

Connecting PostHog to Claude with MCP is one of the easier setups in the catalog — no allow-list to wait on, just a standard OAuth consent screen. Go direct if Claude is your only client, or once through a gateway if you want the same project access shared and governed across every AI client on the team.