PostHog MCP
Official PostHog MCP server for analytics, feature flags, experiments, surveys, dashboards, and error tracking (archived repo; server moved to PostHog monorepo Jan 2026)
Score Breakdown
Server Info
- Package
- @posthog/agent-toolkit
- Registry
- npm
- Repository
- PostHog/mcp
- Maintainer
- PostHogVendor
- Category
- Analytics & Data
- Tags
- product-analyticsfeature-flagsexperiments
- Last Scanned
- 28 May 2026
Findings
8 issuesAuthentication & Identity
HIGHNo MCP OAuth spec implementation
Server does not implement the MCP OAuth authorization server spec. The platform must handle the full OAuth flow, token management, and credential injection externally.
Implement the MCP OAuth spec (.well-known/oauth-authorization-server) for native per-user authentication.
HIGHEnv var credentials with no rotation mechanism
Credentials (INKEEP_API_KEY, POSTHOG_BASE_URL) are read from environment variables at startup. Rotation requires restarting the server process. All requests share the same service account credential.
Support dynamic credential refresh or secrets manager integration.
Tool Schema Quality
CRITICALDangerous execution surface: query-run accepts raw HogQL SQL string input
Tool allows raw code/query execution which could be exploited via prompt injection.
Use parameterized queries or validated command sets.
CRITICALDangerous execution surface: query-generate-hogql-from-question generates and executes SQL from natural language
Tool allows raw code/query execution which could be exploited via prompt injection.
Use parameterized queries or validated command sets.
LLM Safety
MEDIUM2 tool descriptions are too vague
Short or generic descriptions make tool selection unreliable.
Expand descriptions with specific actions, data types, and side effects.
HIGHTool descriptions contain instructional language
Descriptions include directives that could influence LLM behavior beyond tool selection.
Remove instructional language. Descriptions should be purely factual.
Data Exposure
MEDIUM4 list operations lack pagination
dashboards-get-all, insights-get-all, surveys-get-all, event-definitions-list, and properties-list support limit/offset pagination. feature-flag-get-all and experiment-get-all return all records without pagination. No field selection; responses return full records. query-run returns complete analytics result sets.
Add limit/offset or cursor-based pagination.
LOWNo field selection on responses
Responses return full records rather than projected fields.
Implement field selection to return only relevant fields.
Tools
44 total| Name | Description | Risk |
|---|---|---|
| add-insight-to-dashboard | Add an existing insight to a dashboard. Requires insight ID and dashboard ID. Optionally supports layout and color customization. | write |
| dashboard-create | Create a new dashboard in the project. Requires name and optional description, tags, and other properties. | write |
| dashboard-delete | Delete a dashboard by ID (soft delete - marks as deleted). | write |
| dashboard-get | Get a specific dashboard by ID. The response will include insights / tiles that are on the dashboard. | read |
| dashboards-get-all | Get all dashboards in the project with optional filtering. Can filter by pinned status, search term, or pagination. | read |
| dashboard-update | Update an existing dashboard by ID. Can update name, description, pinned status or tags. | write |
| docs-search | Use this tool to search the PostHog documentation for information that can help the user with their request. Use it as a fallback when you cannot answer the user's request using other tools in this MCP. Only use this tool for PostHog related questions. | read |
| error-details | Use this tool to get the details of an error in the project. | read |
| list-errors | Use this tool to list errors in the project. | read |
| create-feature-flag | Creates a new feature flag in the project. Once you have created a feature flag, you should: Ask the user if they want to add it to their codebase, Use the "search-docs" tool to find documentation on how to add feature flags to the codebase (search for the right language / framework), Clarify where it should be added and then add it. | write |
| delete-feature-flag | Delete a feature flag in the project. | write |
| feature-flag-get-all | Get all feature flags in the project. | read |
| feature-flag-get-definition | Get the definition of a feature flag. You can provide either the flagId or the flagKey. If you provide both, the flagId will be used. | read |
| update-feature-flag | Update a new feature flag in the project. To enable a feature flag, you should make sure it is active and the rollout percentage is set to 100 for the group you want to target. To disable a feature flag, you should make sure it is inactive, you can keep the rollout percentage as it is. | write |
| experiment-get-all | Get all experiments in the project. | read |
| experiment-create | Create a comprehensive A/B test experiment. PROCESS: 1) Understand experiment goal and hypothesis 2) Search existing feature flags with 'feature-flags-get-all' tool first and suggest reuse or new key 3) Help user define success metrics by asking what they want to optimize 4) MOST IMPORTANT: Use 'event-definitions-list' tool to find available events in their project 5) For funnel metrics, ask for specific event sequence (e.g., ['product_view', 'add_to_cart', 'purchase']) and use funnel_steps parameter 6) Configure variants (default 50/50 control/test unless they specify otherwise) 7) Set targeting criteria if needed. | write |
| experiment-delete | Delete an experiment by ID. | write |
| experiment-update | Update an existing experiment by ID. Can update name, description, lifecycle state, variants, metrics, and other properties. RESTART WORKFLOW: To restart a concluded experiment, set end_date=null, conclusion=null, conclusion_comment=null, and optionally set a new start_date. To make it draft again, also set start_date=null. COMMON PATTERNS: Launch draft (set start_date), stop running (set end_date + conclusion), archive (set archived=true), modify variants (update parameters.feature_flag_variants). NOTE: feature_flag_key cannot be changed after creation. | write |
| experiment-get | Get details of a specific experiment by ID. | read |
| experiment-results-get | Get comprehensive experiment results including all metrics data (primary and secondary) and exposure data. This tool fetches the experiment details and executes the necessary queries to get complete experiment results. Only works with new experiments (not legacy experiments). | read |
| insight-create-from-query | Create an insight from a query that you have previously tested with 'query-run'. You should check the query runs, before creating an insight. Do not create an insight before running the query, unless you know already that it is correct (e.g. you are making a minor modification to an existing query you have seen). | write |
| insight-delete | Delete an insight by ID (soft delete - marks as deleted). | write |
| insight-get | Get a specific insight by ID. | read |
| insight-query | Execute a query on an existing insight to get its results/data. Provide the insight ID to retrieve the current query results. | read |
| insights-get-all | Get all insights in the project with optional filtering. Can filter by saved status, favorited status, or search term. | read |
| insight-update | Update an existing insight by ID. Can update name, description, filters, and other properties. You should get the insight before update it to see it's current query structure, and only modify the parts needed to answer the user's request. | write |
| query-run | You should use this to answer questions that a user has about their data and for when you want to create a new insight. You can use 'event-definitions-list' to get events to use in the query, and 'event-properties-list' to get properties for those events. It can run a trend, funnel or HogQL query. Where possible, use a trend or funnel rather than a HogQL query, unless you know the HogQL is correct (e.g. it came from a previous insight.). | read |
| query-generate-hogql-from-question | This is a slow tool, and you should only use it once you have tried to create a query using the 'query-run' tool, or the query is too complicated to create a trend / funnel. Queries project's PostHog data based on a provided natural language question - don't provide SQL query as input but describe the output you want. When giving the results back to the user, first show the SQL query that was used, then provide results in reasily readable format. You should also offer to save the query as an insight if the user wants to. | read |
| get-llm-total-costs-for-project | Fetches the total LLM daily costs for each model for a project over a given number of days. If no number of days is provided, it defaults to 7. The results are sorted by model name. The total cost is rounded to 4 decimal places. The query is executed against the project's data warehouse. Show the results as a Markdown formatted table with the following information for each model: Model name, Total cost in USD, Each day's date, Each day's cost in USD. Write in bold the model name with the highest total cost. Properly render the markdown table in the response. | read |
| organization-details-get | Get the details of the active organization. | read |
| organizations-get | Get the organizations the user has access to. | read |
| switch-organization | Change the active organization from the default organization. You should only use this tool if the user asks you to change the organization - otherwise, the default organization will be used. | write |
| projects-get | Fetches projects that the user has access to in the current organization. | read |
| event-definitions-list | List all event definitions in the project with optional filtering. Can filter by search term. | read |
| properties-list | List properties for events or persons. If fetching event properties, you must provide an event name. | read |
| property-definitions | Get event and property definitions for the project. | read |
| switch-project | Change the active project from the default project. You should only use this tool if the user asks you to change the project - otherwise, the default project will be used. | write |
| survey-create | Creates a new survey in the project. Surveys can be popover or API-based and support various question types including open-ended, multiple choice, rating, and link questions. Once created, you should ask the user if they want to add the survey to their application code. | write |
| survey-get | Get a specific survey by ID. Returns the survey configuration including questions, targeting, and scheduling details. | read |
| surveys-get-all | Get all surveys in the project with optional filtering. Can filter by search term or use pagination. | read |
| survey-update | Update an existing survey by ID. Can update name, description, questions, scheduling, and other survey properties. | write |
| survey-delete | Delete a survey by ID (soft delete - marks as archived). | write |
| surveys-global-stats | Get aggregated response statistics across all surveys in the project. Includes event counts (shown, dismissed, sent), unique respondents, conversion rates, and timing data. Supports optional date filtering. | read |
| survey-stats | Get response statistics for a specific survey. Includes detailed event counts (shown, dismissed, sent), unique respondents, conversion rates, and timing data. Supports optional date filtering. | read |
Deploy PostHog MCP securely
CompleteFlow adds per-user authentication, permission scoping, and audit logging to any MCP server out of the box.
Deploy on CompleteFlow