PostHog MCP Setup: Pick a Project, Region, and Read-First Workflow
Use PostHog’s Wizard or hosted MCP endpoint, then confirm the intended US or EU organization and project before doing anything else. Start with read-only checks for insights, errors, and feature flags. Permit flag, dashboard, destination, or other changes only after the reads match expectations, and evaluate AI-backed tools as a separate spend decision.
Use PostHog’s Wizard or hosted MCP endpoint, then confirm the intended US or EU organization and project before doing anything else. Start with read-only checks for insights, errors, and feature flags. Permit flag, dashboard, destination, or other changes only after the reads match expectations, and evaluate AI-backed tools as a separate spend decision.
Table of contents
- What can PostHog MCP access?
- How do you install with the Wizard or hosted endpoint?
- How do you select the correct region, organization, and project?
- How do you verify analytics and errors with reads?
- How do you gate feature flags, destinations, and AI spend?
- How do you fix region, project, token, and tool-surface problems?
- FAQ
What can PostHog MCP access?
Use PostHog’s Wizard or hosted endpoint to connect MCP, confirm the correct region, organization, and project, then begin with read-only requests. PostHog MCP can provide access to analytics, errors, feature-flag information, and other available PostHog tool surfaces.
Treat the connection as a controlled path into project data:
- Use insight reads to confirm analytics context.
- Use error reads to inspect the selected project.
- Use feature-flag reads before allowing flag changes.
- Delay dashboards, destinations, and other changes until the read results are correct.
The PostHog MCP documentation describes the connection options and available workflow. PostHog’s web analytics documentation also describes using analytics through MCP, which makes it a practical starting point for a read-first setup.
The goal is to establish identity and scope before action. If a response references the wrong project or region, stop there and correct the connection rather than interpreting the result as valid.
For a directory entry and setup context, see PostHog MCP on MCPtrove.
How do you install with the Wizard or hosted endpoint?
Run npx @posthog/wizard@latest mcp add for the guided setup, or configure your MCP client to use https://mcp.posthog.com/mcp. The hosted endpoint routes authentication to your PostHog data region.
Use this sequence:
-
Run the Wizard command in the environment where your MCP client is configured:
npx @posthog/wizard@latest mcp add -
Complete the authentication flow presented by PostHog.
-
If using the hosted route directly, enter the exact endpoint:
https://mcp.posthog.com/mcp -
After connecting, make a read request that identifies the intended project before trying a change.
The Wizard is the quickest operational path when you want PostHog to guide the connection. The hosted endpoint is useful when your MCP client accepts a remote server URL directly. Do not substitute the archived standalone repository for the current implementation: PostHog says the implementation moved into its monorepo, and the old repository is archived. The current source is available in PostHog’s MCP service directory.
MCP separates the client, server, and protocol roles, so the client configuration determines how the endpoint is presented to the model or application. The MCP architecture documentation provides the relevant protocol context.
How do you select the correct region, organization, and project?
Use the hosted endpoint’s authentication flow, then verify the selected US or EU data region, organization, and project before reading or changing data. The correct connection is the one whose returned context matches the project you intend to operate.
Use a short confirmation checklist:
- Region: confirm whether the organization belongs in the US or EU route.
- Organization: distinguish the intended organization from other organizations available to the same account.
- Project: confirm the project name or identifier before interpreting insights, errors, or flags.
- Scope: keep the first requests read-only until all three selections match.
The endpoint is not a reason to skip project identification. Authentication routing and project selection answer different questions: the first establishes where the request belongs, while the second establishes which PostHog project the tools should use.
If several environments have similar names, record the exact intended project before connecting. When the result does not match, return to authentication or client configuration and correct the selection. PostHog’s personal API key guidance is the reference point for key-related access details.
How do you verify analytics and errors with reads?
Verify the connection with narrow reads for insights, errors, and feature flags before permitting any write-capable tool. A read is successful only when its returned context and data correspond to the selected project.
A practical verification sequence is:
- Request an analytics insight read and check that the result belongs to the intended project.
- Request an error read and confirm that the returned issues are associated with the same project.
- Request a feature-flag read and compare the flag names or states with what you expect.
- Stop if the results conflict across tools, especially if one response suggests a different region or project.
Keep the prompts specific enough to expose a scope error. “Read the selected project’s insights” is more useful than asking for an unrestricted summary because the result can be checked against the connection context.
PostHog documents web analytics over MCP as a supported way to work with analytics data through the protocol. Use the web analytics MCP guide alongside the main setup documentation when analytics is your first verification surface.
Do not treat a plausible-looking result as proof that the setup is correct. The project identity, region, and requested data should agree before you continue.
How do you gate feature flags, destinations, and AI spend?
Keep feature flags, dashboards, destinations, and other changes behind explicit approval until read checks are correct. Treat AI-backed tools as a separate spend decision because PostHog says MCP connection and ordinary tool calls are free, while some internally AI-powered tools can consume PostHog AI spend when AI data processing is enabled.
| Tool surface | First action | Approval gate |
|---|---|---|
| Insights | Read and verify project context | Permit only after the result matches |
| Errors | Read and confirm scope | Investigate mismatches before proceeding |
| Feature flags | Read names and states | Approve changes separately |
| Dashboards or destinations | Inspect before changing | Require explicit change approval |
| AI-powered tools | Check whether AI processing is enabled | Decide on spend independently |
This separation keeps protocol connection costs, ordinary tool calls, project changes, and AI processing as distinct decisions. Do not assume that a free connection means every internally AI-powered operation has no spend implication.
The MCP security best practices are useful when deciding how approval, authorization, and tool boundaries should work in your client. The operational rule is simple: reads establish context; writes require a new decision.
How do you fix region, project, token, and tool-surface problems?
Fix these problems by isolating one variable at a time: region, organization, project, credentials, then available tools. Start with read-only diagnosis and use the current hosted endpoint or Wizard rather than relying on the archived standalone repository.
| Symptom | Likely check | Next action |
|---|---|---|
| Data appears to belong to another region | US or EU routing | Re-authenticate and confirm the data region |
| Results show the wrong project | Organization or project selection | Correct the selected project before more calls |
| Authentication fails | Personal API key or auth flow | Review the key guidance and reconnect |
| Expected tool is missing | Available tool surface or client setup | Confirm the current connection and client configuration |
| Setup references an old repository | Archived implementation | Use the Wizard, hosted endpoint, or current monorepo source |
For a configuration-focused diagnostic, try MCPtrove’s Config Doctor. It can be the practical next step when the issue is unclear, while the MCP security guide helps frame authorization and approval boundaries.
Avoid “fixes” that weaken authentication, TLS, or permission checks. A missing tool may reflect the connected surface or client configuration rather than a server failure. Likewise, a token problem should be handled through the documented authentication and key process, not by exposing credentials in prompts or configuration shared with others.
If the current implementation is the question, consult PostHog’s MCP source. If the issue is about tool limits or client behavior, Cursor tool-limit math provides additional MCPtrove context.