PostHog MCP

Create a feature flag in the current project.

Update a feature flag by ID in the current project.

### Using the `posthog` tool PostHog makes your product self-driving: it reads your data and ships changes with you, never without you. Spans analytics, experiments, flags, replay, and more. Pass CLI-style commands in the `command` parameter for all PostHog interactions. **Requirements** 1. Find unknown tools with `search` or `tools`. 2. Run `info ` once if its schema is not in context. Reuse it unless the tool changes or a schema error occurs. Never guess a schema or run `info` before every call. **Commands (in order):** ```text # 1. Find unknown tools posthog:exec({ "command": "search " }) posthog:exec({ "command": "tools" }) # fallback: list all # 2. Inspect once if the schema is missing posthog:exec({ "command": "info " }) # 3. Drill into complex fields : REQUIRED for any field with a `hint` posthog:exec({ "command": "schema " }) # 4. Call; reuse the schema posthog:exec({ "command": "call " }) posthog:exec({ "command": "call --json " }) ``` **Schema drill-down:** - `info` returns the full schema if it fits the token budget; otherwise it auto-summarizes (names, types, required, enums, defaults) and attaches `hint` entries pointing to `schema ` for complex fields. - `schema ` (no path) returns the summarized top-level schema. - `schema ` resolves a dot path, descending through: - object `properties` (e.g. `query.source`) - array `items` : numeric segments step into items (`events.0.properties`), or jump to a property on the item type (`events.id`) - `anyOf`/`oneOf` : numeric segment picks a variant by index, or a property name matches any object variant defining it - Oversized sub-schemas are also summarized with a `note` to drill further. - Unknown paths return an error listing available child paths. **Not supported:** - `search` matches tool metadata only, not input schemas. - No pattern-based field projection : drill one path at a time.

Get details of a specific role including its name, creation date, and creator.

Trigger a manual materialization run for a saved query. This immediately refreshes the materialized table with the latest data. The view must already be materialized. Use 'view-run-history' to check run status.

Get a specific data warehouse saved query (view) by ID. Returns the full view definition including the HogQL query, column schema, materialization status, sync frequency, and run history metadata.

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, paths or HogQL query. Where possible, use a trend, funnel or paths query rather than a HogQL query, unless you know the HogQL is correct (e.g. it came from a previous insight.). Use PathsQuery to visualize user flows and navigation patterns : set includeEventTypes to ['hogql'] with a pathsHogQLExpression for custom path steps.

Get a specific alert by ID. Returns the full alert configuration including check results, threshold settings, detector_config (for anomaly detection alerts), and subscribed users. Check results include anomaly_scores, triggered_points, and triggered_dates for detector-based alerts. By default returns the last 5 checks. Use checks_date_from and checks_date_to (e.g. '-24h', '-7d') to get checks within a time window, and checks_limit to control the maximum returned (default 5, max 500). When date filters are provided without checks_limit, up to 500 checks are returned. Check history is retained for 14 days.

List all data warehouse saved queries (views) in the project. Returns each view's name, materialization status, sync frequency, column schema, latest error, and last run timestamp. Use this to discover available views before querying them in HogQL.

Get full details of a specific reverse proxy by ID. Returns the domain, CNAME target (the DNS record value the user needs to configure), current provisioning status, and any error or warning messages. Use this to debug why a proxy isn't working or to check DNS verification status.

List all managed reverse proxies configured for the current organization. Returns each proxy's domain, CNAME target, provisioning status, and the maximum number of proxies allowed by the current plan. Use this to check whether a reverse proxy is set up before recommending one.

Get a specific action by ID. Returns the action configuration including all steps and their trigger conditions.

Query log entries with filtering by severity, service name, date range, search term, and structured attribute filters. Supports cursor-based pagination. Returns log entries with timestamp, body, level, service_name, trace_id, and attributes. Use `logs-attributes-list` and `logs-attribute-values-list` to discover available attributes before building filters. # Workflow : follow this order every time 1. **Discover services first.** Call `logs-attribute-values-list` with `key: "service.name"` and `attribute_type: "resource"` to see available services. 2. **Explore resource attributes.** Call `logs-attributes-list` with `attribute_type: "resource"` to discover resource-level attributes (e.g. `k8s.pod.name`, `k8s.namespace.name`). Then call `logs-attribute-values-list` with `attribute_type: "resource"` for relevant attributes to validate what data exists. 3. **Explore log attributes if needed.** Call `logs-attributes-list` (defaults to log attributes) and `logs-attribute-values-list` to discover log-level attributes. 4. **Check volume with a sparkline.** Call `logs-sparkline-query` with the discovered `serviceNames` and filters to see log volume over time. This confirms there is data and shows patterns before you pull individual entries. 5. **Only then query logs.** Once you have confirmed the service name, volume looks right, and relevant filters are set, call `query-logs` with `serviceNames` and any additional filters. 10 attribute/value queries and 1 sparkline query are cheaper than 1 log query. Prefer thorough exploration over speculative log searches. CRITICAL: Be minimalist. Only include filters and settings that are essential to answer the user's specific question. Default settings are usually sufficient unless the user explicitly requests customization. MANDATORY: Never call query-logs without setting `serviceNames` or at least one `log_resource_attribute` filter. Unfiltered log queries are too broad, expensive, and noisy. If the user hasn't specified a service, use the workflow above to discover services first, then ask or infer. All parameters must be nested inside a `query` object. # Data narrowing ## Property filters Use property filters via the `query.filterGroup` field to narrow results. Only include property filters when they are essential to directly answer the user's question. When using a property filter, you should: - **Choose the right type.** Log property types are: - `log` : filters the log body/message. Use key "message" for this type. - `log_attribute` : filters log-level attributes (e.g. "k8s.container.name", "http.method"). - `log_resource_attribute` : filters resource-level attributes (e.g. k8s labels, deployment info). - **Use `logs-attributes-list` to discover available attribute keys** before building filters. - **Use `logs-attribute-values-list` to discover valid values** for a specific attribute key. - **Find the suitable operator for the value type** (see supported operators below). **Important:** The `logs-attributes-list` and `logs-attribute-values-list` tools default to `attribute_type: "log"` (log-level attributes). To search resource-level attributes (e.g. `k8s.pod.name`, `k8s.namespace.name`), you must explicitly pass `attribute_type: "resource"`. Forgetting this will return log-level attributes when you intended resource-level ones. Supported operators: - String: `exact`, `is_not`, `icontains`, `not_icontains`, `regex`, `not_regex` - Numeric: `exact`, `gt`, `lt` - Date: `is_date_exact`, `is_date_before`, `is_date_after` - Existence (no value needed): `is_set`, `is_not_set` The `value` field accepts a string, number, or array of strings depending on the operator. Omit `value` for `is_set`/`is_not_set`. ## Time period Use the `query.dateRange` field to control the time window. If the question doesn't mention time, the default is the last hour (`-1h`). Examples of relative dates: `-1h`, `-6h`, `-1d`, `-7d`, `-30d`. # Parameters All parameters go inside `query`. ## query.severityLevels Filter by log severity: `trace`, `debug`, `info`, `warn`, `error`, `fatal`. Omit to include all levels. ## query.serviceNames Filter by service names. Use `logs-attribute-values-list` with `key: "service.name"` and `attribute_type: "resource"` to discover available services. ## query.searchTerm Full-text search across log bodies. Use this when the user is looking for specific text in log messages. ## query.orderBy Sort by timestamp: `latest` (default) or `earliest`. ## query.filterGroup A list of property filters to narrow results. Each filter specifies `key`, `operator`, `type` (log/log_attribute/log_resource_attribute), and optionally `value`. See the "Property filters" section above. ## query.dateRange Date range to filter results. Defaults to the last hour (`-1h`). - `date_from`: Start of the range. Accepts ISO 8601 timestamps or relative formats: `-1h`, `-6h`, `-1d`, `-7d`, `-30d`. - `date_to`: End of the range. Same format. Omit or null for "now". ## query.limit Maximum number of results (1-1000). Defaults to 100. ## query.after Cursor for pagination. Use the `nextCursor` value from the previous response. # Examples ## List recent error logs ```json { "query": { "severityLevels": ["error", "fatal"], "serviceNames": [""] } } ``` ## Search for a specific log message ```json { "query": { "searchTerm": "connection refused", "serviceNames": [""], "dateRange": { "date_from": "-6h" } } } ``` ## Filter logs from a specific service ```json { "query": { "serviceNames": ["api-gateway"], "dateRange": { "date_from": "-1d" } } } ``` ## Filter by a log attribute ```json { "query": { "serviceNames": [""], "filterGroup": [{ "key": "http.status_code", "operator": "exact", "type": "log_attribute", "value": "500" }], "dateRange": { "date_from": "-1d" } } } ``` ## Combine severity and attribute filters ```json { "query": { "severityLevels": ["error"], "filterGroup": [ { "key": "k8s.container.name", "operator": "exact", "type": "log_resource_attribute", "value": "web" } ], "dateRange": { "date_from": "-12h" } } } ``` ## Filter by log body content using property filter ```json { "query": { "serviceNames": [""], "filterGroup": [{ "key": "message", "operator": "icontains", "type": "log", "value": "timeout" }] } } ``` ## Check if an attribute exists ```json { "query": { "serviceNames": [""], "filterGroup": [{ "key": "trace_id", "operator": "is_set", "type": "log_attribute" }] } } ``` # Reminders - Always set `serviceNames` or a resource attribute filter. Never run a broad unfiltered log query. - Limit `dateRange` to at most `-1d` (24 hours) unless the user explicitly requests a longer range. - When using `logs-attributes-list` or `logs-attribute-values-list`, remember they default to `attribute_type: "log"`. Pass `attribute_type: "resource"` to search resource-level attributes. - Ensure that any property filters are directly relevant to the user's question. Avoid unnecessary filtering. - Use `logs-attributes-list` and `logs-attribute-values-list` to discover attributes before guessing filter keys/values. - Prefer `searchTerm` for simple text matching; use `filterGroup` with type `log` and key `message` for regex or exact matching.

Get a specific LLM prompt by name. Uses the cached endpoint for fast retrieval. The response always includes `outline`, a flat list of markdown headings parsed from the prompt : useful as a lightweight table of contents. Pass `content=none` to get the outline without the prompt payload, or `content=preview` for a short `prompt_preview` snippet instead of the full prompt.

List all roles defined in the organization. Roles group members and can be used in approval policies and access control rules.

Get a specific survey by ID. Returns the survey configuration including questions, targeting, and scheduling details.

List all insight alerts in the project. Returns alerts with their current state, threshold or detector configuration, timing information, and firing check history. Supports filtering by insight ID via query parameter. Alerts can use either threshold-based conditions (absolute_value, relative_increase, relative_decrease) or anomaly detection via detector_config (zscore, mad, iqr, isolation_forest, knn, etc.).

Get a specific comment by ID including its content, rich content with mentions, and metadata.

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.

Fetch a saved insight by its numeric `id` or 8-character `short_id`. Returns the insight metadata and query definition, but NOT the query results. To retrieve the actual data, call the insight-query tool with the same identifier.

List all LLM prompts stored for the current team. Optionally filter by name. Returns paginated prompt summaries. By default, only prompt metadata is returned, not full prompt content. Every result also includes `outline`, a flat list of markdown headings parsed from the prompt : use it as a lightweight table of contents, and pair with `content=none` to keep responses small.

Retry provisioning a reverse proxy that has failed. Only works for proxies in 'erroring' or 'timed_out' status. Resets the proxy to 'waiting' and restarts the DNS verification and certificate provisioning workflow.

Create a new data warehouse saved query (view). If a view with the same name already exists, it will be updated instead (upsert behavior). The query must be valid HogQL. After creation, the view can be referenced by name in other HogQL queries.

Delete a data warehouse saved query (view) by ID. This is a soft delete : the view is marked as deleted and will no longer appear in lists or be queryable in HogQL. Any materialization schedule is also removed. Cannot delete views that have downstream dependencies or views from managed viewsets.

Update an existing data warehouse saved query (view). Can change the name, HogQL query, or sync frequency. Changing the query triggers column re-inference and sets the status to 'modified'. Use sync_frequency to control materialization schedule: '24hour', '12hour', '6hour', '1hour', '30min', or 'never'. IMPORTANT: when updating the query field, you must first retrieve the view to get its latest_history_id, then pass that value as edited_history_id for conflict detection.

Create a new alert on an insight. Alerts can use either threshold-based conditions or anomaly detection. For threshold alerts: set condition (absolute_value, relative_increase, relative_decrease) and threshold configuration with bounds. For anomaly detection: set detector_config with a detector type (zscore, mad, iqr, threshold, copod, ecod, hbos, isolation_forest, knn, lof, ocsvm, pca) and parameters like threshold (sensitivity 0-1, default 0.9) and window size. Ensemble detectors combine 2+ sub-detectors with AND/OR logic. Requires an insight ID and at least one subscribed user.

Delete an alert by ID. This permanently removes the alert and all its check history. Subscribed users will no longer receive notifications.

Update an existing alert by ID. Can update name, threshold, condition, config, detector_config, subscribed users, enabled state, calculation interval, and weekend skipping. Set detector_config to switch to anomaly detection, or set it to null to switch back to threshold mode. To snooze an alert, set snoozed_until to a relative date string (e.g. '2h', '1d'). To unsnooze, set snoozed_until to null.

List all cohorts in the project. Returns a summary of each cohort including id, name, description, count (person count), is_static (cohort type), and created_at timestamp. Use 'cohorts-retrieve' with the cohort ID to get full details including filters, calculation status, and query definition.