Connect Claude to PostHog

Run a HogQL query - ClickHouse SQL over PostHog's own tables - and return the rows with their column names. This is the operation to reach for whenever a question is not already answered by a saved insight: `select properties.$current_url, count() from events where event = '$pageview' and timestamp > now() - interval 7 day group by 1 order by 2 desc limit 20`. The tables are events, persons, sessions, groups and person_distinct_ids. HogQL is select-only, which is why this is a read. Always include a LIMIT: the rows come back verbatim. Response payloads are kept out of the audit log because they can contain person properties.

List the saved insights in the project - the charts people have built and kept - with their id, short id, name, description and type. Use it to find out what the team already measures before writing a HogQL query for it, and to get the id that get_insight needs. Returns definitions, not results.

Fetch one saved insight by its numeric id, including its full query definition and its most recent computed result. Use it after list_insights when you want the numbers a chart shows, rather than rebuilding the chart's logic yourself in run_query.

List raw events in a time window, newest first, with their properties and the person who sent them. Useful for looking at exactly what one user did, or checking that a newly instrumented event is arriving. PostHog treats this endpoint as legacy and it is narrow: without `after` you only get the last 24 hours, the window between `after` and `before` cannot exceed a year, and paging stops at 50,000. For anything aggregate, use run_query instead. Payloads are kept out of the audit log because event properties carry personal data.

Search the people PostHog has identified, by email, distinct id or free text, and return their properties and distinct ids. Call this first when you need the person id that get_person takes. This returns other people's personal data, so the response is never written to the audit log.

Fetch one person by their numeric PostHog id, with every property PostHog holds and all of their distinct ids. Get the id from list_persons - a distinct id is not a person id. This returns another person's personal data, so the response is never written to the audit log.

List the project's feature flags with their key, name, active state, rollout conditions and variants. Call this before get_feature_flag or update_feature_flag - those take the numeric flag id, which only this returns, not the human-readable key. It is also the cheapest call here, so it is the connection's health check.

Fetch one feature flag by numeric id, with its complete filter groups, rollout percentages, variants and payloads. Read this before update_feature_flag: an update replaces the fields you send, so you need to know what is there now to avoid dropping a targeting rule.

List the project's cohorts - named groups of people defined by properties or behaviour - with their id, name, description and member count. Use it to find the cohort id you can then reference from a HogQL query in run_query, or to see how the team already segments its users.

List session replay recordings with their id, duration, start time, click and keypress counts and the person they belong to. Returns the index only - the replay data itself is not available through this endpoint. Use it to find a recording worth watching in PostHog, then open it there. Recordings are other people's browsing sessions, so the response is never written to the audit log.

List the project's dashboards with their id, name, description and the insights on each. Use it to see how the team organises its reporting, and to find which insight ids belong to a dashboard before calling get_insight on them.