PostHog
Access your PostHog instance.
От сообщества: Добавлен пользователем или импортирован; проверьте владельца перед подключениемРаботаетБез входаГлобальныйБесплатноМожет изменять данные
Что умеет
- 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 q
- Experiment Get All: DEPRECATED: renamed to experiment-list. This alias forwards to experiment-list and will be removed. Call experiment-list directly with the same arguments.
- Insight Query: Execute a saved insight's query and return results. THIS IS THE ONLY WAY TO RETRIEVE INSIGHT RESULTS — the insights-list, insight-get, insight-create, and insight-update tools all retur
Какие данные видит
Нужен ли аккаунт
Не нужен: сервер работает без входа
Access your PostHog instance. Analytics, HogQL queries, session replays, error tracking, feature flags, experiments, and surveys.
Список инструментов сервера (60)
Технические названия из tools/list. Нужны только разработчикам.
| 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). |
| experiment-get-all | DEPRECATED: renamed to experiment-list. This alias forwards to experiment-list and will be removed. Call experiment-list directly with the same arguments. |
| insight-query | Execute a saved insight's query and return results. THIS IS THE ONLY WAY TO RETRIEVE INSIGHT RESULTS — the insights-list, insight-get, insight-create, and insight-update tools all return metadata and query definitions but never the actual data. Call insight-query whenever the user asks to see, analyze, summarize, or compare data from a saved insight, and immediately after creating or updating an insight if they want to verify the output. Supports two output formats: 'optimized' (default) returns a human-readable summary from server-side formatters ideal for analysis, while 'json' returns the raw query results. Optionally accepts `variables_override` and `filters_override` to run the insight with one-off overrides without mutating the saved definition. |
| 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, paths or HogQL query. For existing PostHog-created data, use system tables with the system. prefix; for example, count SQL insight variables with SELECT count() AS total FROM system.insight_variables. 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. To target a Postgres or DuckDB direct-query data warehouse source instead of ClickHouse, set 'connectionId' on a HogQLQuery (call external-data-sources-list to discover ids). |
| query-validate | Dry-run a HogQL query: parse and type-check it without executing, so there is no ClickHouse cost and no 202 polling. Returns structured errors (with character positions), warnings, notices, and the list of tables the query references. Use this before 'query-run' on any non-trivial HogQL to catch column typos, missing tables, and syntax issues up front instead of iterating on opaque execution errors. Accepts the same language values as the HogQL editor: 'hogQL' (default, full SELECT), 'hogQLExpr' (bare expression), 'hog', or 'hogTemplate'. Pass 'connectionId' to validate against a Postgres or DuckDB direct-query data warehouse source instead of the ClickHouse catalog (use external-data-sources-list to find ids). |
| hogql-schema | Return the HogQL catalog for the active project: every queryable table (PostHog, system, warehouse, view, materialized view, batch export, endpoint) keyed by name, with each table's fields, plus the join graph between data-warehouse tables. Call this once up front when building a HogQL query from scratch so you pick real table and column names on the first attempt instead of guessing. Cheap — no ClickHouse cost. Pass 'connectionId' to introspect a Postgres or DuckDB direct-query data warehouse source instead of the ClickHouse catalog (use external-data-sources-list to find ids). |
| 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 easily readable format. You should also offer to save the query as an insight if the user wants to. |
| 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. |
| 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. |
| projects-get | Fetches projects that the user has access to in the current organization. |
| event-definitions-list | List all event definitions in the project with optional filtering. Can filter by search term. |
| event-definition-update | Update event definition metadata. Can update description, tags, mark status as verified or hidden. Use exact event name like '$pageview' or 'user_signed_up'. |
| properties-list | List properties for events or persons. If fetching event properties, you must provide an event name. |
| 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. |
| survey-create | Creates a new survey in the project. Use this for both in-app surveys and hosted forms. Prefer draft creation by default and do not set start_date unless the user explicitly asks to launch immediately. For in-app surveys, popover is the default unless the user asks for widget or api. For hosted forms, use external_survey. Keep surveys short unless the user asks for a longer flow. |
| survey-get | Get a specific survey by ID. Returns the survey configuration including questions, targeting, and scheduling details. |
| surveys-get-all | Get all surveys in the project with optional filtering. Can filter by search term or use pagination. |
| survey-update | Update an existing survey by ID. Omitted top-level fields are preserved, but nested objects and arrays you provide may replace existing values. Before changing questions, conditions, appearance, targeting, translations, or hosted-form content, retrieve the survey first and preserve fields that should remain. Do not send null to clear a field unless the user explicitly asked to remove it. |
| survey-delete | Delete a survey by ID (soft delete - marks as archived). |
| 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. |
| 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. |
| entity-search | Search for PostHog entities by name or description. Can search across multiple entity types including insights, dashboards, experiments, feature flags, notebooks, actions, cohorts, event definitions, and surveys. Use this to find entities when you know part of their name. Returns matching entities with their IDs and URLs. |
| debug-mcp-ui-apps | Debug tool for testing MCP Apps SDK integration. Returns sample data displayed in an interactive UI app with component showcase. Use this to verify that MCP Apps are working correctly. |
| external-data-sources-db-schema | Validate credentials against a remote source and return the list of tables available to sync (works for database sources like Postgres/MySQL and SaaS sources like Stripe/Hubspot alike). Pass source_type and credential fields in the payload object. Each table entry includes: table name, incremental_available, append_available, cdc_available, supports_webhooks, detected_primary_keys, available_columns (name/type/nullable), rows estimate, and incremental_fields (candidate timestamp/integer columns for incremental sync). Use this BEFORE external-data-sources-create so the user can pick a sync_type per table. Returns 400 with a message if credentials are invalid. |
| external-data-sources-jobs | List sync job history for a data warehouse source. Returns jobs sorted by most recent first, with status, duration, rows synced, and errors. Supports optional filtering by date range (after/before as ISO timestamps) and by schema name. |
| external-data-sync-logs | Get sync job logs for a data warehouse table schema. Returns log entries from the log_entries ClickHouse table, filtered by schema ID and optionally by a specific job's workflow_run_id. Use external-data-sources-jobs to find job IDs and workflow_run_ids. Supports filtering by log level (DEBUG, INFO, WARNING, ERROR) and message search. |
| session-recording-summarize | Generate an AI-powered summary of one or more session recordings. Returns structured analysis including user journey segments, key actions, segment outcomes, overall session outcome, and sentiment analysis (frustration score, rage clicks, confusion signals). Use this instead of asking users to watch full recordings — it provides the key insights in seconds. Accepts up to 300 session IDs and an optional focus_area to guide the summary toward a specific aspect (e.g., "checkout flow" or "error handling"). The response is a dict keyed by session ID. Successful entries contain the summary fields; failed entries contain an `error` (e.g. `no_events_or_too_short`, `summary_failed`) and an `error_message` so callers can distinguish "skipped on purpose" from "tool broke". A bad session ID in the batch is reported as a per-session error and does not fail the whole request. WARNING: First-time summaries call an AI model and are very slow — expect around 5 minutes on average. Previously generated summaries are cached and return instantly. Warn the user about the wait before calling this tool. DEEP LINKS: Key actions include `session_id` and `milliseconds_since_start`. Build deep links as `{posthog_base_url}/replay/{session_id}?t={milliseconds_since_start / 1000}` (the `?t=` parameter is in seconds). Example: 45000ms in session abc123 → `/replay/abc123?t=45`. Always include these links for key actions and frustration signals. |
| action-create | Create a new action in the project. Actions define reusable event triggers based on page views, clicks, form submissions, or custom events. Each action can have multiple steps (OR conditions). Use actions to create composite events for insights and funnels. Example: Create a 'Sign Up Click' action with steps matching button clicks on the signup page. |
| action-delete | Delete an action by ID (soft delete - marks as deleted). The action will no longer appear in lists but historical data is preserved. |
| action-get | Get a specific action by ID. Returns the action configuration including all steps and their trigger conditions. |
| action-update | Update an existing action by ID. Can update name, description, steps, tags, and Slack notification settings. |
| actions-get-all | Get all actions in the project. Actions are reusable event definitions that can combine multiple trigger conditions (page views, clicks, form submissions) into a single trackable event for use in insights and funnels. Supports pagination with limit and offset parameters. Note: Search/filtering by name is not supported on this endpoint. |
| activity-log-list | List recent activity log entries for the project. Shows who did what and when — feature flag changes, dashboard edits, experiment launches, etc. Supports filtering by scope, user, and date range. |
| advanced-activity-logs-filters | Get the available filter options for activity logs — scopes, activity types, and users that have logged activity. Useful for building filter UIs or understanding what kinds of activity are tracked. |
| advanced-activity-logs-list | List activity log entries with advanced filtering, sorting, and field-level diffs. Supports filtering by scope, activity type, user, date range, and search text. |
| alert-create | 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. Note: subscribed_users only controls email recipients. For Slack or HTTPS webhook delivery, see the recipe on cdp-functions-create — it covers integration lookup (integrations-channels-retrieve), dedupe (cdp-functions-list filtered by alert id, limit=1000), and the exact filters/inputs shape to pass. |
| alert-delete | Delete an alert by ID. This permanently removes the alert and all its check history. Subscribed users will no longer receive notifications. |
| alert-get | 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. |
| alert-simulate | Run an anomaly detector on an insight's historical data without creating any alert or check records. Use this to preview how a detector configuration would perform before saving it as an alert. Requires an insight ID and a detector_config object with a type (zscore, mad, iqr, copod, ecod, hbos, isolation_forest, knn, lof, ocsvm, pca, or ensemble). Optionally specify date_from (e.g. '-48h', '-30d') to control how far back to simulate, and series_index to pick which series to analyze. Returns data values, anomaly scores per point, triggered indices and dates, and for ensemble detectors, per-sub-detector score breakdowns. |
| alert-update | 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. Note: Slack/webhook delivery for this alert lives as a HogFunction. See the recipe on cdp-functions-create for the dedupe-and-create flow; to change or remove an existing destination, find it via cdp-functions-list (type=internal_destination, limit=1000) by matching filters.properties value against this alert's id, then use cdp-functions-partial-update or cdp-functions-delete. |
| alerts-list | 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.). |
| annotation-create | Create an annotation to mark an important change (for example, a deployment) on charts and trends. Provide a note in `content`, when it happened in `date_marker` (ISO 8601), and whether it is scoped to the current `project` or the whole `organization`. |
| annotation-delete | Soft-delete an annotation by ID. This hides the annotation from normal lists while preserving historical records. |
| annotation-retrieve | Retrieve a single annotation by ID from the current project. Use this when you already know the annotation ID and want complete details. |
| annotations-list | List annotations in the current project, newest first. Use this to review existing deployment markers and analysis notes before adding new annotations. |
| annotations-partial-update | Update an existing annotation by ID. You can change its text (`content`), when it happened (`date_marker`, ISO 8601), or its visibility scope (`project` or `organization`). Only the fields you provide are updated. |
| approval-policies-list | List all approval policies configured for this project. Shows which actions require approval, who can approve, and bypass rules. |
| approval-policy-get | Get details of an approval policy including conditions, approver configuration, quorum requirements, and bypass rules. |
| batch-export-create | Create a new batch export. Typed destination config schemas are available for Databricks and AzureBlob destinations — both require a team-scoped Integration (use integrations-list to find one). Other destination types are permitted by the API but typically must be created via the PostHog UI because their credentials are stored in the destination config. Always specify the model field (events, persons, or sessions) — omitting it defaults to events but the field should be set explicitly. |
| batch-export-delete | Soft-delete a batch export. Stops all future scheduled runs and hides the export from list and get operations. Historic run records remain attached to the deleted export in the database. |
| batch-export-get | Get a batch export by ID. Returns full non-sensitive configuration including destination type and config, linked Integration id (for Databricks and AzureBlob), schedule, model, and the 10 most recent runs. |
| batch-export-update | Partially update a batch export. Top-level fields (name, paused, interval, schema, filters) work for any destination type. Destination config updates are only typed for Databricks and AzureBlob destinations. Do not change the model field on an existing export — the destination table schema is created on the first run, so switching models causes errors unless the table name is also changed. |
| batch-exports-list | List batch exports in the project. Batch exports send event, person, or session data on a schedule to destinations like S3, Snowflake, BigQuery, Databricks, Azure Blob, Postgres, Redshift, or HTTP. Returns destination type, interval, paused state, and non-sensitive config; credentials are never exposed. Use batch-export-get with the ID for full details including latest runs, query, and filters. |
| cdp-function-templates-list | List available function templates. Templates are pre-built function configurations for common integrations (Slack, webhooks, email, etc.) and transformations (GeoIP, etc.). Filter by type (destination, site_destination, site_app, transformation, etc.) via the 'type' query parameter. Results are sorted by popularity (number of active functions using each template). |
| cdp-function-templates-retrieve | Get a specific function template by its template ID (e.g. 'template-slack', 'template-geoip'). Returns the full template including source code, inputs schema, default filters, and mapping templates. Use this to understand what inputs a template requires before creating a function from it. |
| cdp-functions-create | Create a new function. Requires 'type' (destination, site_destination, internal_destination, source_webhook, warehouse_source_webhook, site_app, or transformation) and either 'hog' source code or a 'template_id' to derive code from a template. Provide 'inputs_schema' to define configurable parameters and 'inputs' with their values. Use 'filters' to control which events trigger the function. Transformations run during ingestion and have an 'execution_order' field. Recipe — deliver an insight alert to Slack or a webhook (canonical reference; alert-create / alert-update point here): 1. Pick the integration. For Slack, call integrations-list (filter by kind=slack) to find the integration id, then call integrations-channels-retrieve with that id to list channels. For a webhook, the user provides the destination URL directly. 2. Dedupe before creating. Call cdp-functions-list with type=internal_destination and limit=1000; the response now includes filters. Look for an existing function whose filters.properties has an entry with key=alert_id and value equal to <alert.id>. If one exists, call cdp-functions-partial-update on that id; if not, proceed to step 3. (Paginate until you have checked every page or found a match.) 3. Create. Use type=internal_destination, template_id=template-slack (or template-webhook), and: filters = { "events": [{"id": "$insight_alert_firing", "type": "events"}], "properties": [{"key": "alert_id", "value": "<alert.id>", "operator": "exact", "type": "event"}] } # Slack. Channel id is preferred (e.g. C0123ABC); "#general" is also accepted. # Override text + blocks with the same shape the alert-wizard UI uses, so # agent-created and UI-created alerts produce identical Slack messages. # Source of truth: HOG_FUNCTION_SUB_TEMPLATES['insight-alert-firing'] for # template-slack in frontend/src/scenes/hog-functions/sub-templates/sub-templates.ts. inputs = { "slack_workspace": {"value": <slack_integration_id_int>}, "channel": {"value": "<channel_id>"}, "text": {"value": "Alert triggered: {event.properties.insight_name}"}, "blocks": {"value": [ {"type": "header", "text": {"type": "plain_text", "text": "Alert '{event.properties.alert_name}' firing for insight '{event.properties.insight_name}'"}}, {"type": "section", "text": {"type": "plain_text", "text": "{event.properties.breaches}"}}, {"type": "context", "elements": [{"type": "mrkdwn", "text": "Project: <{project.url}|{project.name}>"}]}, {"type": "divider"}, {"type": "actions", "elements": [ {"type": "button", "text": {"type": "plain_text", "text": "View Insight"}, "url": "{project.url}/insights/{event.properties.insight_id}"}, {"type": "button", "text": {"type": "plain_text", "text": "View Alert"}, "url": "{project.url}/insights/{event.properties.insight_id}/alerts?alert_id={event.properties.alert_id}"} ]} ]} } # Webhook — must be an https:// URL. inputs = {"url": {"value": "<destination_url>"}} 4. $insight_alert_firing event properties available for templating: alert_id, alert_name, insight_name, insight_id (short_id), state (always "Firing" — the event is only emitted on a firing transition, not on recovery), last_checked_at (ISO 8601 string or null), breaches (human-readable summary, e.g. "Series A is below 1000"), and detector metadata: alert_mode (always present), detector_type and ensemble_operator (null for threshold alerts, set for anomaly detection). Project context is available as {project.url} (already includes /project/<team_id>), {project.id}, {project.name}. Do not reference value, threshold_lower, or insight_url — those are not emitted. |
| cdp-functions-delete | Delete a function by ID (soft delete). The function will no longer appear in lists or process events, but historical data is preserved. |
| cdp-functions-invocations-create | Test-invoke a function with a mock event payload. Sends the function configuration and test data to the plugin server for execution and returns logs and status. Use 'mock_async_functions: true' (default) to simulate external calls like fetch() without making real HTTP requests. |
| cdp-functions-list | List all functions (destinations, transformations, site apps, and source webhooks) in the project. Returns each function's name, type, enabled status, execution order, template info, and filters (the event/property filter expression that gates the function). Filter by type (destination, site_destination, internal_destination, source_webhook, warehouse_source_webhook, site_app, transformation) and enabled status via query parameters. Pagination caps at 100 per page by default — pass limit=1000 (max 1000) when scanning for an existing function by alert id, and follow the next link if more pages exist. |
| cdp-functions-logs-retrieve | Retrieve execution logs for a specific CDP function by ID. Returns log entries with timestamp, level (DEBUG, LOG, INFO, WARN, ERROR), and message. Use to debug why a destination or transformation is failing or not producing expected results. Supports filtering by log level, text search, time range (after/before), and pagination via limit. |