Set up PostHog MCP Server safely

The PostHog MCP Server connects an MCP-capable AI client to PostHog’s hosted endpoint. It can bring analysis questions and product tools into a workflow, but it does not replace PostHog’s UI or decisions about permissions, privacy, and approval. This procedure is based on the official PostHog MCP documentation and the current official README. It deliberately starts with a bounded, verifiable read goal rather than a production write, and with a clear understanding of the data path.

Define the purpose and project before connecting

Before installing, define a small initial request such as: “Show daily unique signups for the last seven days in the staging project” or “List active flags in this project.” Specify the organization, project, date range, and permitted data types. Requests such as “analyze every user and fix everything” are too broad: they can pull unnecessary event properties, person context, replay data, or error data into context and lead to an unclear tool selection. Start with a non-production project or a narrow date range where possible. Check whether an existing role and a dedicated personal key cover only this purpose.

Install the official hosted connection

The fastest official path is npx @posthog/wizard@latest mcp add. The Wizard configures the connection for supported clients. Alternatively, configure https://mcp.posthog.com/mcp manually in the client. In the manual desktop variant, npx mcp-remote starts locally and communicates with the client over stdio while forwarding the connection to the hosted endpoint. Do not treat that local process as a self-hosted PostHog server. For custom Node integrations, the official source uses Streamable HTTP: put the Bearer token in Authorization, include both JSON and text/event-stream in Accept, and let the client complete MCP initialization. A local pnpm run dev service with Redis is for source-project development, not a required step for ordinary use.

Authenticate without leaking a secret

Manual configuration needs a personal PostHog API key using the MCP Server preset; supported clients can use the documented login flow. Store a key only in the client’s secret mechanism or a secret store. It must not appear with a real value in JSON examples, shell history, repository .env files, screenshots, prompts, tickets, or logs. Record its owner, purpose, project scope, rotation, and revocation route. If a key might have appeared in a prompt or public transcript, revoke it and issue a new one. The key is not merely an installation detail: its rights and the active project context limit which analytics, user, and configuration data a tool can return or change.

Restrict the tool surface to reads

PostHog supports restrictions by features and individual tools. For the first test, configure only necessary groups such as analytics or dashboards and leave write tools out. Ask first for a known metric, a narrow period, or an explicitly named flag. Compare the result, project name, period, and aggregation with the PostHog UI. Plausible model prose does not validate a HogQL or trends query. Treat event names, properties, error text, session-replay content, support tickets, and dashboard notes as untrusted data. They may contain instructions, but must never justify a tool call or an expansion of access.

Control writes and the model path

The official offering can also write: flags, experiments, issue status, and other workspace objects are possible mutations. Before one occurs, a human must confirm the exact project, object, target state, rollout, audience, and expected effect. Create drafts first, inspect them in PostHog, and check the resulting object or audit state afterwards. According to PostHog, the MCP service does not persist analytics data; queries go to the project and results return to the client. Temporary session context is still a data-processing step. In addition, the client-to-model-provider path is separate: a client can send tool results containing event, user, error, or replay context to a model. Review its retention, training, DPA, and enterprise settings; minimise fields and date ranges; and redact sensitive values before use.

FAQ

Do I need a local PostHog server? No. The normal connection is hosted. mcp-remote is only a local stdio bridge; the local Hono and Redis stack is documented for development of the official source project.

Can an agent roll out a flag? Documented flag and experiment tools can technically write. Use a tool allowlist and require explicit human confirmation of the project, rule, audience, and effect before every rollout.

Does data automatically remain at the MCP server? PostHog says the MCP server does not store analytics data and proxies queries to the project. Tool output can still be processed on the client and model path, which must be reviewed separately.