PostHog

Switch Organization

Switch the active PostHog organization for subsequent tool calls. Call this proactively whenever the user names an organization they want to operate on. Use `organizations-list` to resolve an organization name to an id. Default to the active organization when no specific organization is mentioned.

Projects Get

Fetches projects that the user has access to in the current organization.

Switch Project

Switch the active PostHog project for subsequent tool calls. Call this proactively whenever the user names a project or workspace they want to operate on. Use `projects-get` to resolve a project name to an id. If the project isn't found, the user may be referring to a project in a different organization, in which case call `organizations-list` and `switch-organization` first, then retry `projects-get`. Default to the active project when no specific project is mentioned.

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'.

Experiment Results Get

Get experiment metric results and exposure data in one call. Each row in `metrics.primary.results` and `metrics.secondary.results` carries a self-describing `metric` summary: `uuid`, `name` (the label users see in the experiment UI), `metric_type`, `goal`, and `source` — `inline` for metrics defined on the experiment, `shared` for metrics attached via a saved metric. For `shared` rows, `saved_metric_id` and `saved_metric_name` identify the underlying saved metric; both are `null` for `inline` rows. Rows are ordered to match the experiment UI (`primary_metrics_ordered_uuids` / `secondary_metrics_ordered_uuids`). A row whose underlying metric query failed is kept with `data: null` so positions stay aligned with the ordered UUIDs — check `data === null` to detect failures. The raw source surfaces (`experiment.metrics`, `experiment.metrics_secondary`, `experiment.saved_metrics`) are preserved on the response for callers who want to audit them, but you do not need to reconcile them yourself — the result rows already merge inline and shared. UI-only bulk fields are stripped from each `data` payload: `clickhouse_sql`, `hogql`, the legacy `insight` visualization payload, and the per-funnel-step session samples — `step_sessions` is removed from `baseline`, each `variant_results` entry, and from `baseline` / `variants[]` inside every `breakdown_results` entry. Statistical fields (`sum`, `sum_squares`, `step_counts`, `number_of_samples`, `credible_intervals`, per-breakdown stats, etc.) are preserved. Only works with new experiments (not legacy `ExperimentTrendsQuery` / `ExperimentFunnelsQuery`).

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.

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.

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.

Execute Sql

Executes HogQL — PostHog's variant of SQL that supports most of ClickHouse SQL. "HogQL" and "SQL" are used interchangeably. ### When to use `execute-sql` **Use `query-*` tools whenever the question maps to a supported insight type.** These tools produce typed, saveable insights; SQL forfeits that. Reach for `execute-sql` only when no `query-*` tool can express the question: - **Searching or listing existing PostHog entities** — insights, dashboards, cohorts, feature flags, experiments, surveys. No `query-*` tool covers these; query the `system.*` tables. - **Multi-event joins or aggregations across event types** that don't fit a single series. - **Sophisticated queries beyond `query-*` schemas** — custom grouping, window functions, non-trivial CTEs, data warehouse joins. - **Pre-filtering or shaping** a large dataset before running a `query-*` call. If a `query-*` tool fits, use it. Default to `query-*`; SQL is the escape hatch, not the starting point. ### Always consult the `querying-posthog-data` skill Before writing any SQL, read the PostHog `querying-posthog-data` skill. It is the source of truth for up-to-date HogQL patterns, system table schemas (`system.insights`, `system.dashboards`, `system.cohorts`, etc.), and function references. Do not rely on training data — table and column names drift. ### Discovery workflow (mandatory) 1. **Warehouse schema** — call `read-data-warehouse-schema` to verify tables, views, and columns. Do not guess names. **This applies to `system.*` tables too** (`system.insights`, `system.dashboards`, `system.cohorts`, …); their column sets differ per entity and drift over time. For a specific custom warehouse table, inspect its columns with: ```sql SELECT columns FROM system.data_warehouse_tables WHERE name = 'my_table' ``` 2. **Event taxonomy** — call `read-data-schema` to verify events, properties, and property values. Do not rely on training data or PostHog defaults. 3. **Write the SQL** only after steps 1 and 2 confirm the data exists, using the verified table and column names. If the required events, properties, or tables do not exist, say so — do not run queries that will return empty results. ### Format SQL for readability Write SQL a human can scan: multi-line with indentation, one column/CTE per line, and inline `--` comments for non-obvious logic. This matters most for queries you save via `view-create` / `view-update` — the SQL editor stores and renders the string verbatim, so a minified one-liner stays unreadable for whoever opens the view later. ### Handling large results Large JSON values in results (notably full `properties` objects) are truncated by default. If you anticipate a large result set, or you are selecting the full `properties` object (e.g., `SELECT properties FROM events`), dump the results to a file and process them with bash rather than returning them inline. Alternatively, cherry-pick specific keys (`properties.$browser`) instead of the whole object. ### Large LLM trace fields are stripped from `events.properties` For LLM events (`$ai_generation`, `$ai_trace`, `$ai_span`, etc.), these specific keys with large values are stripped from `events.properties`: - `properties.$ai_input` - `properties.$ai_output` - `properties.$ai_output_choices` - `properties.$ai_input_state` - `properties.$ai_output_state` - `properties.$ai_tools` Prefer `query-llm-trace` / `query-llm-traces-list` whenever you need any of those six keys — they contain information on the proper read patterns to a dedicated AI events table which contains these fields. Other AI properties (token counts, costs, model, trace IDs) stay on `events` in all three regimes and are safe to query directly. ### Observability data-plane tables: `logs`, `posthog.trace_spans`, `posthog.metrics` PostHog ingests OpenTelemetry signals into three ClickHouse-backed tables that are queryable via HogQL. **Note the namespacing asymmetry** — `logs` is registered at the root, while `trace_spans` and `metrics` live under the `posthog.` namespace and must be referenced as such (e.g. `FROM posthog.trace_spans`): - `logs` — log entries. Common fields: `body` (also exposed as `message`), `severity_text`, `severity_number`, `service_name`, `attributes`, `resource_attributes`, `trace_id`, `span_id`, `timestamp`. Prefer `posthog:query-logs` for filtered list queries; reach for SQL for aggregations across services or joins with `posthog.trace_spans` / `posthog.metrics` by `trace_id`. - `posthog.trace_spans` — OpenTelemetry spans. Common fields: `trace_id`, `span_id`, `parent_span_id`, `is_root_span`, `name`, `service_name`, `kind` (0-5), `status_code` (0 Unset, 1 OK, 2 Error), `duration_nano`, `timestamp`, `end_time`, `attributes`, `resource_attributes`. Prefer `posthog:query-apm-spans` / `posthog:apm-trace-get` for span listing and full-trace fetches; reach for SQL for joins with `logs` / `posthog.metrics` by `trace_id`, exemplar lookups, or aggregations the typed tools don't expose. - `posthog.metrics` — OpenTelemetry metric points. Common fields: `metric_name`, `metric_type` (counter/gauge/histogram), `value`, `count`, `histogram_bounds`, `histogram_counts`, `unit`, `aggregation_temporality` (`delta` or `cumulative`), `is_monotonic`, `service_name`, `trace_id`, `span_id`, `attributes`, `resource_attributes`, `timestamp`. No typed `query-metrics` tool — use SQL. A projection pre-aggregates by `(team_id, time_bucket, toStartOfMinute(timestamp), service_name, metric_name, metric_type, resource_fingerprint)` with `count/sum/min/max(value)`, so per-minute aggregations grouped by those keys are very cheap. **Important for counters:** check `aggregation_temporality` before aggregating — `SUM(value)` over a window is only correct for `delta`. For `cumulative` counters, the value is a running total, so use `argMax(value, timestamp)` (or `max(value) - min(value)` for a rate) to avoid double-counting. Always filter or split by `aggregation_temporality` when both regimes can appear for a given `metric_name`. All three share `team_id`, `time_bucket`, `service_name`, `resource_fingerprint`, and where applicable `trace_id`. `trace_id` on `posthog.metrics` is the OpenTelemetry exemplar pattern — a metric anomaly can be drilled into via a sample `trace_id` to pull the full trace and correlated logs. **Note:** exemplar extraction is not yet wired up in the ingestion pipeline (the `_exemplars` argument is unused in `rust/capture-logs/src/metric_record.rs`), so `posthog.metrics.trace_id` is always empty today. The pattern below describes the intended capability; the "works today" alternative anchors on `posthog.trace_spans` instead. **`trace_id` format:** Both `logs` and `posthog.trace_spans` store `trace_id` as a 24-character base64-encoded 16-byte value (e.g. hex `21EDB3A025A9ECD32ADF3E5D7548A4F4` encodes to `Ie2zoCWp7NMq3z5ddUik9A==`). The MCP API layer converts to hex via `hex(tryBase64Decode(trace_id))` for display. Raw HogQL queries see the base64 form. Unset = `'AAAAAAAAAAAAAAAAAAAAAA=='`. `posthog.metrics.trace_id` is a plain string, empty when unset (once exemplars land it will match the base64 format of the other two tables). Joins are direct equality on `trace_id`. User HogQL queries against `logs`, `posthog.trace_spans`, and `posthog.metrics` are capped at 50 GB read per query to prevent unbounded scans. Always pass a tight `timestamp` window. Default to the last hour and widen only when justified. ### Example: three-signal correlation (works today, span-anchored) <example> User: An error spike on `checkout` over the last hour — show me a sample slow error trace and the logs in that request. Assistant: I'll pick the slowest error root span as the anchor, then pull the spans and logs in one stitched query. ```sql WITH anchor AS ( SELECT trace_id FROM posthog.trace_spans WHERE service_name = 'checkout' AND is_root_span AND status_code = 2 AND timestamp >= now() - INTERVAL 1 HOUR ORDER BY duration_nano DESC LIMIT 1 ) SELECT 'span' AS source, name AS detail, service_name, duration_nano, status_code, NULL AS severity_number, timestamp FROM posthog.trace_spans WHERE trace_id = (SELECT trace_id FROM anchor) AND timestamp >= now() - INTERVAL 1 HOUR UNION ALL SELECT 'log', body, service_name, NULL, NULL, severity_number, timestamp FROM logs WHERE trace_id = (SELECT trace_id FROM anchor) AND timestamp >= now() - INTERVAL 1 HOUR ORDER BY timestamp ``` <reasoning> - Anchoring on `posthog.trace_spans` works today because spans always carry a populated `trace_id`. Once `posthog.metrics` exemplars land, the CTE can be swapped for `argMax(trace_id, value) FROM posthog.metrics WHERE … AND trace_id != ''` to drill from a metric spike instead. - `trace_id` is stored as base64 in both `logs` and `posthog.trace_spans`, so direct equality works — no decoding needed. - `UNION ALL` with a `source` discriminator avoids three separate calls and keeps the timeline interleaved. - Note `logs` is root-level while `posthog.trace_spans` and `posthog.metrics` require the namespace prefix. - The inner `WHERE` clauses repeat the time window so the optimizer keeps both legs of the UNION efficient. </reasoning> </example> ### Example: searching for existing insights <example> User: Do we have any insights tracking revenue or payments? Assistant: I'll search existing insights and dashboards via SQL. 1. Discover columns: `read-data-warehouse-schema` to confirm `system.insights` and `system.dashboards` expose `name`, `description`, `deleted`, `last_modified_at`, and the ID columns I plan to project. Without this step I'd be guessing — column sets differ per system table. 2. Search insights by name (using only confirmed columns): `execute-sql` with `SELECT id, name, short_id, description FROM system.insights WHERE NOT deleted AND (name ILIKE '%revenue%' OR name ILIKE '%payment%') ORDER BY last_modified_at DESC LIMIT 20`. 3. If results are sparse, broaden to dashboards (re-using the same schema lookup — `system.dashboards` has its own column set, e.g. no `short_id`): `execute-sql` with `SELECT id, name, description FROM system.dashboards WHERE NOT deleted AND (name ILIKE '%revenue%' OR name ILIKE '%payment%') ORDER BY last_modified_at DESC LIMIT 20`. 4. Validate promising insights with `insight-retrieve`. 5. Summarize with links. <reasoning> 1. `read-data-warehouse-schema` is mandatory step 1 of the discovery workflow above; `system.*` tables are warehouse tables and their column sets differ per entity (e.g. not every system table has `last_modified_at` or `short_id`). 2. SQL against `system.*` tables is the fastest way to discover existing entities — no `query-*` tool covers entity search. 3. ILIKE with multiple terms catches naming variants ("Monthly Revenue", "MRR", "Payment Events"). 4. `insight-retrieve` confirms the insight's query configuration still matches intent. </reasoning> </example>

Read Data Schema

Use this tool to explore the user's data schema. The user implements PostHog SDKs to collect events, properties, and property values. They are used by users to create insights with visualizations, SQL queries, watch session recordings, filter data, target particular users or groups by traits or behavior, etc. Each event, action, and entity has its own data schema. You must verify that specific combinations exist before using it anywhere else. Events or properties starting from "$" are system properties automatically captured by SDKs. Do not rely on your training data or PostHog defaults for events or properties. Always use this tool to confirm what actually exists in the user's project before referencing any event, property, or property value.

Read Data Warehouse Schema

Use this tool to retrieve the core data warehouse schemas for PostHog tables (events, groups, persons, sessions) and the available data warehouse tables, views, and system tables. Use this to understand the data model before writing HogQL queries.

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.

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.

Workflows Enable

Enable / activate a draft workflow and start processing events. Confirm with the user before invoking.

Workflows Disable

Disable / deactivate a live workflow and stop processing events. Confirm with the user before invoking.

Workflows Archive

Archive a draft or disabled workflow.

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.

Llma Clustering Job Get

Retrieve a specific clustering job configuration by ID. Returns the job name, analysis level (trace or generation), event filters, enabled status, and timestamps.

Llma Clustering Job List

List all clustering job configurations for the current team (max 5 per team). Each job defines an analysis level (trace or generation) and event filters that scope which traces are included in clustering runs. Cluster results are stored as $ai_trace_clusters and $ai_generation_clusters events — use docs-search or execute-sql to query them.

Llma Evaluation Config Get

Retrieve the team's evaluation configuration, including the active LLM provider key used to run llm_judge evaluations and remaining trial credits. Call this before creating an llm_judge evaluation to verify the team has either trial credits available or an active provider key configured — without one, llm_judge runs will fail. Returns trial limits, the active provider key (or null if on trial credits), and timestamps.

Llma Evaluation Config Set Active Key

Assign the LLM provider key used to run llm_judge evaluations team-wide. Pass key_id (UUID of an existing provider key whose state is 'ok'). Switching the active key affects every llm_judge evaluation that doesn't pin its own key. The key must already be in the 'ok' state — if it isn't, ask the user to validate it from the PostHog UI before retrying.

Llma Evaluation Create

Create a new LLM evaluation. For 'llm_judge' type, provide evaluation_config.prompt and model_configuration (provider + model). For 'hog' type, provide evaluation_config.source (Hog code returning a boolean). When enabled, the evaluation runs automatically on new $ai_generation events. Results appear as '$ai_evaluation' events.

Llma Evaluation Delete

Soft-delete an LLM evaluation. The evaluation stops running and is hidden from list views. Historical evaluation results ($ai_evaluation events) are preserved.

Llma Evaluation Get

Get a specific LLM evaluation by its UUID. Returns the full evaluation configuration including type, config, output type, enabled status, and model configuration.

Llma Evaluation Judge Models

List the provider+model combinations supported for llm_judge evaluations. Pass a `provider` query parameter (one of openai, anthropic, gemini, openrouter, fireworks, azure_openai) and optionally `key_id` to scope the list to deployments reachable with a specific provider key (mainly relevant for azure_openai). Each entry returns the model id and whether it is available on PostHog trial credits. Call this before creating an llm_judge evaluation when the user has not specified a model, so a valid provider+model combination is chosen.

Llma Evaluation List

List all LLM evaluations for the current project. Optionally filter by name/description search or enabled status. Evaluations automatically score $ai_generation events for quality, relevance, safety, and other criteria. Two types are supported: 'llm_judge' (LLM scores outputs against a prompt) and 'hog' (deterministic Hog code). Results are stored as '$ai_evaluation' events.

Llma Evaluation Report Create

Create an evaluation report configuration. Reports summarize recent evaluation runs (using AI) and are delivered to email or Slack targets. `frequency` selects the trigger mode and defaults to 'every_n' if omitted: - 'every_n' (count-based): a report fires once `trigger_threshold` new evaluation results have accumulated, but no more often than `cooldown_minutes` apart and capped by `daily_run_cap` per UTC day. `trigger_threshold` is required in this mode (10–10000); `cooldown_minutes` (60–1440) and `daily_run_cap` are optional. - 'scheduled' (time-based): reports fire on the cadence defined by `rrule` (RFC 5545, e.g. 'FREQ=WEEKLY;BYDAY=MO') anchored at `starts_at` and expanded in `timezone_name` so local clock times survive DST transitions. `rrule` and `starts_at` are required in this mode; `timezone_name` defaults to 'UTC'. `delivery_targets` is a list of {type: 'email', value: '<addr>'} or {type: 'slack', integration_id: <int>, channel: '<channel>'} entries. Slack integrations must belong to the same team. Use `report_prompt_guidance` to steer the AI report's focus.

Llma Evaluation Report Delete

Soft-delete an evaluation report configuration. The report stops firing and is hidden from list views; historical report runs are preserved. Equivalent to calling llma-evaluation-report-update with deleted=true — that update path is the canonical way to soft-delete and is the only option when you also want to change other fields in the same call.

Llma Evaluation Report Generate

Immediately trigger an AI-generated evaluation report for this report config. Enqueues a Temporal workflow that analyzes recent evaluation runs and delivers the report to configured targets (email or Slack). Returns 202 on success. Duplicate requests within the same minute are coalesced — only one report is generated. Rate-limited by daily_run_cap.

Llma Evaluation Report Get

Get a specific evaluation report configuration by UUID. Returns the full config including frequency, delivery targets, trigger thresholds, and schedule settings.

Llma Evaluation Report List

List all evaluation report configurations for the current project. Optionally filter by evaluation UUID using the 'evaluation' query param. Each report config controls how and when evaluation summary reports are generated and delivered (email or Slack).

Llma Evaluation Report Run List

List the run history for a specific evaluation report config. Each run record includes the generated report content, the evaluation period covered, delivery status ('pending', 'delivered', 'failed'), and any delivery error details.

Llma Evaluation Report Update

Partially update an evaluation report configuration. Toggle enabled/disabled, update delivery targets (email or Slack), or switch frequency between 'every_n' and 'scheduled'. For 'every_n' mode set trigger_threshold (10–10000) and optionally cooldown_minutes (60–1440); for 'scheduled' mode set rrule and starts_at. Set deleted=true to soft-delete the config.

Llma Evaluation Run

Manually trigger an evaluation run for a specific $ai_generation event. Enqueues a Temporal workflow that asynchronously executes the evaluation and stores the result as a '$ai_evaluation' event. Returns a workflow_id and status "started". Pair with execute-sql to query results: SELECT * FROM events WHERE event = '$ai_evaluation'.

Llma Evaluation Summary Create

Generate an AI-powered summary of LLM evaluation results for a given evaluation config. Pass an evaluation_id and an optional filter ("all", "pass", "fail", or "na") to scope which runs are analyzed. Returns an overall assessment, pattern groups for passing, failing, and N/A runs (each with title, description, frequency, and example generation IDs), actionable recommendations, and run statistics. Optionally pass generation_ids to restrict the analysis to specific runs. Results are cached for one hour — use force_refresh to recompute. Rate-limited; requires AI data processing approval for the organization.

Llma Evaluation Test Hog

Test Hog evaluation source code against a sample of recent $ai_generation events without saving. Returns per-event results (pass/fail/N/A), reasoning, and input/output previews. Use this to validate Hog code before creating or updating a 'hog' type evaluation.

Llma Evaluation Update

Update an existing LLM evaluation (partial update). Toggle enabled/disabled, update the evaluation config (prompt or Hog source), or change the model configuration.

Llma Personal Spend

Retrieve the current user's personal LLM spend analysis across PostHog products over the last N days (default 30, max 90). Returns a summary plus breakdowns by product, tool, model, and top traces. The `product` query param is required and scopes the tool / model / trace breakdowns to a single product; currently only `posthog_code` is supported. `by_product` always returns the cross-product view. Pass `refresh=true` to bypass the 5-minute cache.

Llma Prompt Create

Create a new LLM prompt for the current team. Requires a unique name and prompt content (string or JSON object).

Llma Prompt Duplicate

Duplicate an existing LLM prompt under a new name. Copies the latest version's content to create a new prompt at version 1. Useful for forking a prompt or as a way to rename since names are immutable after creation.

Llma Prompt Get

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.

Llma Prompt List

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.

Llma Prompt Update

Publish a new version of an existing LLM prompt by name. Name is immutable after creation. You can either provide the full prompt content via 'prompt', or use 'edits' for incremental find/replace updates. Each edit must have 'old' (text to find, must match exactly once) and 'new' (replacement text). Edits are applied sequentially. Only one of 'prompt' or 'edits' may be provided.

Llma Review Queue Create

Create a review queue for routing traces that still need review. Queue names must be unique among active queues in the current project.

Llma Review Queue Delete

Delete a review queue by ID. This soft-deletes the queue and soft-deletes all active pending assignments that still belong to it.

Llma Review Queue Get

Retrieve a review queue by ID. Returns its name, current pending_item_count, creator, and timestamps.

Llma Review Queue Item Create

Add a trace to a review queue as a pending trace review assignment. Requires queue_id and trace_id. Fails if the trace already has an active review or is already pending in any review queue.

Llma Review Queue Item Delete

Remove a pending trace review assignment from review queues. This soft-deletes the queue item so the trace can be queued again later if needed.

Llma Review Queue Item Get

Retrieve a single pending trace review assignment by ID. Returns the owning queue, trace_id, creator, and timestamps for the pending review task.

Llma Review Queue Item List

List pending trace review assignments across review queues. Supports filtering by queue_id, trace_id, trace_id__in, search, and ordering so agents can find traces that are still queued for review.

Llma Review Queue Item Update

Move a pending trace review assignment to a different review queue by updating queue_id. Fails if the trace has already been reviewed and can no longer stay queued.

Llma Review Queue List

List review queues used for trace reviews. Returns queue names, pending_item_count, creator info, and timestamps. Supports queue-name search and ordering.

Llma Review Queue Update

Rename an existing review queue. The updated name must stay unique among active queues in the project.

Llma Score Definition Create

Create a new scorer (a.k.a. score definition) used by trace reviews. Pass `name`, `kind` (`categorical`, `numeric`, or `boolean`), and `config` matching the kind. `kind` is immutable after creation. Categorical scorers need an `options` array with unique keys and optional `selection_mode`/`min_selections`/`max_selections` (for `multiple`). Numeric scorers can set `min`, `max`, `step`. Boolean scorers can override `true_label`/`false_label`. Scorers always start active (not archived) and at version 1.

Llma Score Definition Get

Retrieve a scorer by ID, including its current immutable `config` payload, `current_version` number, kind, archived state, and timestamps.

Llma Score Definition List

List active scorers for the current project. By default only active rows are returned — pass `archived=true` to see only archived scorers. Other filters: `kind` (`categorical`, `numeric`, `boolean`) and `search` over name/description. Returns metadata plus the current config snapshot.

Llma Score Definition New Version

Publish a new immutable `config` version for an existing scorer. Use this whenever the scoring rules change (add/remove categorical options, tweak numeric bounds, rename boolean labels). Existing trace reviews keep their snapshot of the previous version, so historical scores remain stable. The `config` shape must match the scorer's `kind`. Each call increments `current_version` by one. Pass `base_version` (the version number you observed before bumping) for optimistic concurrency — the request returns 409 if another writer already advanced the scorer.

Llma Score Definition Update

Update a scorer's metadata: rename via `name`, edit `description`, or toggle `archived` to hide (`true`) or restore (`false`). Archiving is reversible — there is no destroy endpoint. To change the scoring rules instead, call `llma-score-definition-new-version`. `kind` cannot be changed.

Llma Sentiment Create

Classify sentiment of LLM trace or generation user messages as positive, neutral, or negative. Pass a list of trace or generation IDs and an analysis_level ("trace" or "generation"). Returns per-ID sentiment labels with confidence scores and per-message breakdowns. Results are cached — use force_refresh to recompute. Rate-limited.

Llma Skill Archive

Archive every active version of an agent skill by name. This hides the skill from default lists and cannot be undone. Use llma-skill-get first if you need to inspect the skill before archiving it.

Llma Skill Create

Create a new agent skill. Requires a unique kebab-case name (lowercase letters, numbers, hyphens), a description explaining when to use it, and the skill body (SKILL.md instruction content as markdown). Optionally include license, compatibility, allowed_tools, metadata, and bundled files.

Llma Skill Duplicate

Duplicate an existing agent skill under a new name. Copies the latest version's content, metadata, and bundled files to create a new skill at version 1.

Llma Skill File Create

Add a new bundled file to an agent skill. Fails with 409 if a file at the given path already exists — use llma-skill-update with files to replace, or llma-skill-file-delete followed by llma-skill-file-create to overwrite. Publishes a new skill version and returns the updated skill (read its 'version' field to chain further edits via base_version). Supply base_version for optimistic concurrency.

Llma Skill File Delete

Remove a bundled file from an agent skill by path. Fails with 404 if the file is not in the latest version. Publishes a new skill version and returns 200 with the updated skill body (not 204) — read its 'version' field to chain further edits via base_version. Supply base_version for optimistic concurrency.

Llma Skill File Get

Fetch a single bundled file from an agent skill by its path. Use the file manifest from llma-skill-get to discover available files. Supports progressive disclosure — only load files when needed rather than fetching all content upfront.

Llma Skill File Rename

Rename a bundled file within an agent skill. Fails with 404 if old_path is not in the latest version, and with 409 if new_path already exists. Use this to move a file without rewriting its content. Publishes a new skill version and returns the updated skill (read its 'version' field to chain further edits via base_version). Supply base_version for optimistic concurrency.

Llma Skill Get

Get a specific agent skill by name, including its full body content, metadata, and file manifest. Follows the Agent Skills specification (agentskills.io).

Llma Skill List

List all agent skills stored for the current team. Returns skill names and descriptions for discovery — use descriptions to determine which skill to fetch for a given task. Does not return skill body content (use llma-skill-get to fetch full content).

Llma Skill Update

Publish a new version of an existing agent skill by name. Any field not provided is carried forward from the current latest version. Requires base_version for optimistic concurrency. For the body, you can either provide the full content via 'body', or use 'edits' for incremental find/replace updates. Each edit must have 'old' (text to find, must match exactly once) and 'new' (replacement text). Edits are applied sequentially. Only one of 'body' or 'edits' may be provided. For file changes, prefer the per-file tools rather than passing a 'files' list: llma-skill-file-create / llma-skill-file-delete / llma-skill-file-rename handle add/remove/rename one file at a time and return the updated skill (including the bumped version) so callers can chain further edits via base_version. For per-file content updates, use 'file_edits' to apply find/replace updates to individual files without resending the full file set — each entry targets one existing file by path. Non-targeted files carry forward unchanged. 'file_edits' cannot add, remove, or rename files; use the per-file tools or 'files' (replace-all) for that. 'files' and 'file_edits' are mutually exclusive. Passing a 'files' list here replaces ALL files and risks data loss if any file is omitted — use it only when you intentionally want to replace the entire bundle.

Llma Summarization Create

Generate an AI-powered summary of an LLM trace or generation. Pass a trace_id or generation_id with a date_from — the backend fetches the data and returns a structured summary with title, flow diagram, summary bullets, and interesting notes. Results are cached. Use mode "minimal" (default) for 3-5 points or "detailed" for 5-10 points. Rate-limited; requires AI data processing approval for the organization.

Llma Tagger Create

Create an AI observability tagger that automatically adds custom tags to $ai_generation events. For tagger_type "llm", provide tagger_config.prompt plus tagger_config.tags (each with name and optional description); optionally set min_tags and max_tags. For tagger_type "hog", provide tagger_config.source Hog code that returns a tag name string, a list of tag name strings, or null; optionally provide tagger_config.tags as a whitelist. Use enabled=false while drafting, then update the tagger from the UI.

Llma Tagger List

List AI observability taggers for the current project. Supports filtering by enabled status, id__in, search, and ordering. Returns each tagger's name, description, enabled state, type, configuration, conditions, model configuration, creator, and timestamps.

Llma Tagger Test Hog

Test Hog tagger source code against recent $ai_generation events without saving a tagger. The source should return a tag name string, a list of tag name strings, or null. Optionally pass tags as a whitelist; returned tags outside the whitelist are filtered out. Results include input/output previews, selected tags, stdout reasoning, and any execution error for each sampled event.

Llma Trace Review Create

Save a trace review. Supports an optional comment, an optional scores array, and an optional queue_id to clear a matching pending review-queue item after the review is saved.

Llma Trace Review Delete

Delete a trace review by ID. This soft-deletes the review so the same trace can be reviewed again later if needed.

Llma Trace Review Get

Retrieve a saved trace review by ID. Returns the trace_id, comment, scores, creator, reviewer, and timestamps.

Llma Trace Review List

List saved trace reviews. Supports filtering by trace_id, definition_id, search, and ordering. Returns comments, scores, reviewers, and timestamps.

Llma Trace Review Update

Update a trace review. Pass comment and/or the full desired scores array. You can also pass queue_id to clear only a matching pending queue item after the review is saved.

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.

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.

File Download Batch Exports Cancel Create

Cancel a running or starting on-demand file download export. When the status is not Starting or Running calling this will fail. Returns the status of the export after cancelling, which is always Cancelled.

File Download Batch Exports Create

Start an on-demand batch export that prepares downloadable files for events, persons, or sessions. Provide data_interval_start and data_interval_end as ISO 8601 datetimes; the interval must be at most one week. For events, include and exclude filter event names. Use file-download-batch-exports-retrieve with the returned id to poll until status is Completed, then follow the downloading-batch-export-files skill to download the files through the existing REST download endpoint.

File Download Batch Exports Retrieve

Get the status of an on-demand file download export. Returns Starting or Running while the export is in progress, Completed with file IDs when files are ready, or a failed status with an error message. When status is Completed, use the downloading-batch-export-files skill to download each file through the existing REST download endpoint; the generated MCP download operation is intentionally not enabled because it is a redirect to the file body.

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.

Cdp Functions Metrics Retrieve

Retrieve execution metrics for a specific CDP function by ID. Returns time-series data showing success and failure counts over a configurable interval (hour, day, or week). Use to understand function health, identify failure spikes, and monitor delivery reliability. Supports breakdown by metric kind (success/failure) or name, and time range filtering.

Cdp Functions Partial Update

Partially update a function. Can enable/disable the function, change its name, description, source code, inputs, filters, mappings, or masking config. The 'type' field cannot be changed after creation. To delete a function, use the cdp-functions-delete tool instead.

Cdp Functions Rearrange Partial Update

Update the execution order of transformation functions. Send an 'orders' object mapping function UUIDs to their new execution_order integer values. Only applies to functions with type=transformation. Returns the updated list of transformations.

Cdp Functions Retrieve

Get a specific function by ID. Returns the full configuration including source code, inputs schema, input values (secrets are masked), filters, mappings, masking config, and runtime status.

Cohorts Add Persons To Static Cohort Partial Update

Add persons to a static cohort by their UUIDs. Only works for static cohorts (is_static: true).

Cohorts Create

Create a new cohort. For dynamic cohorts, provide 'filters' with AND/OR groups of property conditions (person properties, behavioral filters, or cohort references). For static cohorts, set 'is_static: true' then use the 'cohorts-add-persons-to-static-cohort-partial-update' tool to add person UUIDs.

Cohorts List

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.

Cohorts Partial Update

Update an existing cohort's name, description, or filters. Changing filters on a dynamic cohort triggers recalculation. To soft-delete a cohort, set 'deleted: true'.

Cohorts Retrieve

Get a specific cohort by ID. Returns the cohort name, description, filters (for dynamic cohorts), count of matching users, and calculation status.

Cohorts Rm Person From Static Cohort Partial Update

Remove a person from a static cohort by their UUID. Only works for static cohorts (is_static: true). The person must exist in the project. Idempotent: removing a person who exists but is not a member of the cohort succeeds silently.

Conversations Tickets List

List support tickets in the project. Supports filtering by status (new, open, pending, on_hold, resolved), priority (low, medium, high), channel_source (widget, email, slack), assignee, date range, and search. Results are paginated and ordered by updated_at descending by default. Returns ticket metadata including status, priority, message counts, and timestamps.

Conversations Tickets Retrieve

Get a specific support ticket by ID or ticket number. Returns full ticket details including status, priority, assignee, message count, channel info, person data, and session context.

Conversations Tickets Update

Update a support ticket. Can change status (new, open, pending, on_hold, resolved), priority (low, medium, high), assignee, SLA deadline, escalation reason, and tags. Assignee should be an object with type ('user' or 'role') and id, or null to unassign.

Project Get

Retrieve a project and its settings. Pass `@current` as the ID to fetch the caller's active project.

Project Settings Update

Update a project's settings using PATCH semantics — only the fields included in the request body are changed. Use `project-get` first to inspect current settings. Always confirm changes with the user before applying.

Subscriptions Create

Create a new subscription to receive scheduled deliveries of an insight or dashboard. Requires either an insight ID or dashboard ID. Set target_type to email, slack, or webhook and target_value to the recipient(s). For email: comma-separated addresses. For slack: requires an integration_id for a connected Slack workspace plus a channel name in target_value. For webhook: a URL. Set frequency (daily, weekly, monthly, yearly) and optionally interval, byweekday, start_date, and until_date. Dashboard subscriptions also require dashboard_export_insights (list of insight IDs from that dashboard, max 6).

Subscriptions Deliveries List

List delivery history for a subscription — one row per send attempt. Each entry includes status (starting, completed, failed, skipped), trigger_type (scheduled, manual, target_change), and timestamps (created_at, finished_at). Filter with status=failed to quickly surface failed deliveries. Results are cursor-paginated newest first. content_snapshot, recipient_results, and error are excluded to match what the web UI exposes and to avoid leaking recipient identifiers or upstream response bodies that may contain tokens / PII.

Subscriptions Deliveries Retrieve

Fetch a single subscription delivery attempt by id. Returns status, trigger_type, target_type, target_value, timestamps, workflow/idempotency metadata, and exported_asset_ids. content_snapshot (the frozen dashboard/insight state at send time) is not returned — use the insight/dashboard tools for current state. recipient_results and error are also excluded to match what the web UI exposes and to avoid leaking recipient identifiers or upstream response bodies that may contain tokens / PII.

Subscriptions List

List subscriptions for the project. Returns scheduled email, Slack, or webhook deliveries of insight or dashboard snapshots. Each subscription includes its schedule (frequency, interval, byweekday), next_delivery_date, and a human-readable summary.

Subscriptions Partial Update

Update an existing subscription by ID. Can change target_type, target_value, frequency, interval, byweekday, start_date, until_date, title, or deleted status. Set deleted to true to deactivate a subscription (subscriptions are soft-deleted). Changing target_value triggers notifications to new recipients.

Subscriptions Retrieve

Get a specific subscription by ID. Returns the full subscription configuration including target type and value, schedule details, next delivery date, and associated insight or dashboard.

Subscriptions Test Delivery Create

Trigger an immediate test delivery of a subscription to its configured target(s) (email, Slack, or webhook). Runs the same pipeline as a scheduled delivery but with trigger_type=manual, producing a real delivery record you can inspect via subscriptions-deliveries-list / subscriptions-deliveries-retrieve. Returns 202 Accepted once the delivery workflow is queued; poll subscriptions-deliveries-list (newest first) or subscriptions-deliveries-retrieve for the outcome. Returns 409 if a test delivery for the same subscription is already in flight.

User Get

Retrieve a user's profile and settings. Pass `@me` as the UUID to fetch the authenticated user — non-staff callers may only access their own account.

User Settings Update

Update the authenticated user's profile and settings using PATCH semantics — only the fields included in the request body are changed. Pass `@me` as the UUID; non-staff callers may only update their own account. Use `user-get` first to inspect current settings. `notification_settings` merges key-by-key; changing `email` triggers a verification flow; changing `password` also requires `current_password`. Always confirm changes with the user before applying.

Usage Metrics Create

Create a new usage metric for the project. The metric surfaces on both group and person Customer Analytics profile pages — usage metrics are not scoped to a specific group type. `filters` accepts two shapes: (1) Events (default) — HogFunction filter shape with an `events` array. (2) Data warehouse — set `source: "data_warehouse"` plus `table_name`, `timestamp_field`, `key_field`. Call `external-data-schemas-list` first to discover synced tables, and `execute-sql` (`SELECT * FROM <table> LIMIT 1`) to inspect column names. DW metrics currently render only on group profiles. When `math` is `sum`, `math_property` is required; when `math` is `count`, `math_property` must be empty. For DW SUM metrics, `math_property` is the column name (or HogQL expression) to sum on the table. Pass `group_type_index: 0`.

Usage Metrics Destroy

Permanently delete a usage metric by id. Pass `group_type_index: 0` — usage metrics apply to both groups and persons regardless of this value.

Usage Metrics List

List usage metrics defined for the project. Usage metrics apply to both groups and persons on Customer Analytics profile pages — they are NOT scoped to a specific group type despite the legacy URL shape. Returns each metric's id, name, format, interval (days), display mode, math aggregation, and filter definition. Pass `group_type_index: 0`.

Usage Metrics Partial Update

Update fields on an existing usage metric. Accepts a subset of fields; unspecified fields are left unchanged. `filters` accepts the events shape (default) or the data warehouse shape (`source: "data_warehouse"` plus `table_name`, `timestamp_field`, `key_field`). When switching to DW, call `external-data-schemas-list` to discover synced tables. Changing `math` to `sum` requires `math_property`; changing to `count` requires clearing `math_property`. For DW SUM metrics, `math_property` is the column name to sum. DW metrics currently render only on group profiles. Pass `group_type_index: 0` — usage metrics apply to both groups and persons regardless of this value.

Usage Metrics Retrieve

Fetch a single usage metric by id. Pass `group_type_index: 0` — usage metrics apply to both groups and persons regardless of this value.

Dashboard Create

Create a new dashboard. Provide a name and optional description, tags, and pinned status. Can also create from a template or duplicate an existing dashboard. The returned tiles omit insight results to save context — use dashboard-insights-run to fetch the actual data for each insight.

Dashboard Create Text Tile

Add a markdown text tile to a dashboard. Text tiles render as markdown blocks — useful as section headings, dividers, or annotations between insight tiles to give a dashboard structure. The desktop grid is 12 columns wide; a typical heading uses a thin full-width banner (e.g. `layouts.sm = {x: 0, y: 0, w: 12, h: 1}`). If `layouts` is omitted, the tile is placed using the default layout — use dashboard-reorder-tiles afterwards if you need precise placement.

Dashboard Delete

Delete a dashboard by ID. The dashboard will be soft-deleted and no longer appear in lists.

Dashboard Delete Tile

Soft-delete a single tile (text, insight, or button) from a dashboard. Behaves the same as the delete button in the UI — the underlying Insight, Text, or ButtonTile object is preserved (so an insight that lives on multiple dashboards stays on the others), and the remaining tiles are automatically compacted upward to fill the gap left by the deleted tile (matching the dashboard grid's layout). Pass the DashboardTile id as `tile_id` (use dashboard-get to look up tile IDs). To remove the whole dashboard instead, use dashboard-delete.

Dashboard Get

Get a specific dashboard by ID. Returns the full dashboard including all tiles with their insights and layout information. Insight results, filters, and query metadata are omitted to save context — use dashboard-insights-run to fetch the actual data for every insight on the dashboard in one call, or insight-query for a single insight. Supports variables_override and filters_override query params; on this endpoint they affect only the merged `filters` and `variables` fields in the response (preview). To execute insights with the same overrides, pass the same query params to dashboard-insights-run.

Dashboard Insights Run

Run all insights on a dashboard and return their results. Uses cached results by default (may be stale); set refresh to 'blocking' for fresh results. Set format to 'optimized' (default) for LLM-friendly text tables or 'json' for raw query results. Supports variables_override and filters_override query params to run insights with one-off overrides without persisting; see the parameter descriptions for the exact JSON shape required.

Dashboard Reorder Tiles

Reorder tiles on a dashboard by providing an array of tile IDs in the desired display order. First, use dashboard-get to see current tile IDs. By default existing tile widths and heights are preserved; see the layout parameter to force a 2-column or full-width grid instead.

Dashboard Update

Update an existing dashboard by ID. Can update name, description, pinned status, tags, filters, and restriction level. The returned tiles omit insight results to save context — use dashboard-insights-run to fetch the actual data for each insight.

Dashboard Update Text Tile

Update the markdown body, layout, or color of an existing text tile on a dashboard. Pass the DashboardTile id as `tile_id` (use dashboard-get to look up tile IDs). Only the fields you provide are updated; omitted fields are left unchanged.

Dashboards Get All

List dashboards in the project. The optional `search` parameter runs a fuzzy match against name and description using Postgres trigram word similarity (handles typos, transpositions, and prefix-as-you-type) and returns results ranked by relevance — use it to find a specific dashboard by name rather than paging through every dashboard. `search` is capped at 200 characters; longer queries return a 400 error. Optional filters by tag and pinned status are also supported. Returns name, description, pinned status, tags, and creation metadata. Tiles and insights are not included — use dashboard-get to fetch a dashboard's tiles, then dashboard-insights-run to fetch the actual data for each insight.

Data Warehouse Data Health Issues Retrieve

Return all failed or degraded items across the data pipeline: materialized saved queries that failed, external data schemas in Failed or BillingLimitReached state, sources in Error state, failed batch exports, and disabled/degraded transformations. Each entry includes id, name, type (materialized_view, external_data_sync, source, destination, transformation), status, error message, failed_at, and url. Use this for a one-shot audit of what's broken in a project's data warehouse.

External Data Schemas Cancel

Cancel a currently running sync job for a specific table schema. If no sync is running, returns an error. Use 'external-data-schemas-list' to check which schemas have status 'Running' before calling this.

External Data Schemas Delete Data

Delete the synced table data from PostHog but keep the schema entry. The schema remains visible in the source and can be re-synced. Use this to clear stale or corrupt data before triggering a fresh sync.

External Data Schemas Incremental Fields Create

Re-inspect the source for a single table schema and return the currently available incremental fields, detected primary keys, column list, and which sync methods (incremental/append/cdc/webhook) are available. Use this when the source schema has changed, an incremental field has been dropped, or the user wants to switch to a different incremental_field/sync_type on an existing schema. The operation_id is external_data_schemas_incremental_fields_create but semantically this is a read-only refresh.

External Data Schemas List

List all table schemas across all data warehouse sources. Each schema represents one table being synced from an external source. Returns the schema name, sync status, sync frequency, incremental field configuration, and latest error. Use this to see which tables are actively syncing and their health.

External Data Schemas Partial Update

Update a table schema's sync configuration. Can change sync type, sync frequency, incremental field, primary key columns, CDC table mode, and enable/disable the schema.

External Data Schemas Reload

Trigger a sync for a single table schema using its configured sync method (incremental, full refresh, append, or CDC). Use this to manually sync a specific table without triggering all tables in the source.

External Data Schemas Resync

Trigger a full resync for a table schema, discarding all previously synced data and re-importing from the source. This cancels any running sync first, then resets the pipeline state. Use this when data is corrupt or out of sync.

External Data Schemas Retrieve

Get a single table schema by ID. Returns full details including sync status, sync frequency, incremental field, latest error, and the associated source and table metadata.

External Data Sources Check Cdc Prerequisites Create

Validate that a live Postgres database meets Change Data Capture prerequisites — logical replication enabled (wal_level=logical), replication slot available, publication present, and required permissions. Postgres-only. Returns {valid, errors[]}. Use this before configuring a schema with sync_type=cdc, or to diagnose why an existing CDC sync has started failing.

External Data Sources Connections List

List external data sources that can be used as a connectionId when running execute-sql against an external source (direct-query Postgres connections). Returns a lightweight id, prefix, and engine for each — unlike external-data-sources-list, it does not include warehouse import sources or table schemas. Use this to discover valid connectionId values.

External Data Sources Create

Create a new external data source connection. Before calling this, use 'external-data-sources-wizard' to discover source types and 'external-data-sources-db-schema' to validate credentials and discover available tables. Present the db-schema results to the user showing each table's available sync methods, incremental fields, detected primary keys, and columns so they can configure before creation. The payload must include a 'schemas' array where each entry has: name, should_sync (bool), sync_type (incremental/full_refresh/append), and optionally incremental_field, incremental_field_type, and primary_key_columns from the db-schema response.

External Data Sources Create Webhook Create

For sources that support real-time webhook ingestion (currently Stripe), create the HogFunction handler and register the webhook URL with the external service using the source's stored credentials. Requires at least one schema on the source with sync_type='webhook' and should_sync=true. Returns the webhook_url, success flag, and any error. NOT idempotent — each successful call registers a new endpoint on the external service, so retrying after a network error or calling twice can create duplicate webhook endpoints (e.g. duplicate Stripe webhook endpoints delivering the same events twice). Always check webhook-info-retrieve first and only re-call if `exists: false`. For Stripe the signing_secret is auto-captured from the Stripe API response and stored securely; if auto-registration fails (e.g. the API key lacks webhook permissions), the user must create the webhook manually in Stripe and submit the signing_secret via update-webhook-inputs.

External Data Sources Delete Webhook Create

Unregister the webhook with the external service and delete the PostHog HogFunction that was handling it. Any webhook-type schemas under the source will stop receiving real-time events. The source and its schemas are preserved — only the webhook is removed. After deletion, schemas can be switched to a polling sync_type (incremental/full_refresh) via external-data-schemas-partial-update, or a new webhook can be created with create-webhook.

External Data Sources Destroy

Delete a data warehouse source and all its table schemas, synced tables, and sync schedules. This is a soft delete. Any running syncs are cancelled first. This cannot be undone — the source must be recreated to resume syncing.

External Data Sources List

List all configured data warehouse import sources in the project. Returns each source's type (Postgres, Stripe, Hubspot, etc.), connection status, prefix, schemas, latest error, and last sync timestamp. Use this to discover what external data sources are connected.

External Data Sources Partial Update

Update an existing data warehouse source. Can change the prefix (table name prefix in HogQL), description, or connection credentials via job_inputs. Cannot change the source_type or access_method after creation.

External Data Sources Refresh Schemas

Fetch the latest table list from the remote database and create schema entries for any new tables found. Does not trigger a data sync. Use this after adding new tables to a source database to make them available for syncing.

External Data Sources Reload

Trigger a sync for all enabled table schemas in the source using each table's configured sync method. If the source uses direct query mode, this refreshes the schema metadata instead.

External Data Sources Retrieve

Get a single data warehouse source by ID. Returns full details including source type, connection status, prefix, all table schemas with their sync statuses, latest error, and last sync timestamp.

External Data Sources Update Webhook Inputs Create

Update the webhook-specific inputs on an already-created webhook — for example when a signing secret has been rotated on the source side, or when the webhook was registered manually and the signing_secret needs to be supplied. Only accepts keys defined in the source type's webhookFields (e.g. Stripe's signing_secret). Fails if no webhook has been created for this source yet — call create-webhook first.

External Data Sources Webhook Info Retrieve

Return webhook state for a source: supports_webhooks (is this source type webhook-capable), exists (has a webhook been created), webhook_url (the PostHog endpoint the external service should POST to), schema_mapping (external event type → PostHog schema id), and external_status (what the remote service reports about the webhook — enabled_events, status, created_at, error). Use this to check whether a webhook is healthy and whether the external registration is still valid.

External Data Sources Wizard

Return the configuration metadata for all supported data warehouse source types. Each entry describes the required fields (host, port, database, credentials, etc.), field types, and OAuth flows. Use this to discover what source types are available and what parameters are needed to create a new source.

Sql Variables Create

Create a reusable SQL variable for HogQL queries. Provide a human-readable name and type. The code_name is generated from the name and is referenced in SQL as {variables.code_name}. For List variables, provide values as the allowed options.

Sql Variables Delete

Delete a SQL variable by ID. Queries that reference this variable by code_name may stop working after deletion.

Sql Variables Update

Update an existing SQL variable by ID. You can change the name, type, default_value, or allowed values for List variables. If the name changes, check the response for the current code_name before writing queries that reference it.

View Create

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.

View Delete

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.

View Get

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.

View List

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.

View Materialize

Enable materialization for a saved query. This creates a physical table from the view's query and sets up a 24-hour sync schedule to keep it refreshed. Materialized views are faster to query but use storage. Use 'view-unmaterialize' to undo. Rate limited.

View Run

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.

View Run History

Get the 5 most recent materialization run statuses for a saved query. Each entry includes the run status and timestamp. Use this to monitor whether materialization is running successfully.

View Unmaterialize

Undo materialization for a saved query. Deletes the materialized table and removes the sync schedule, reverting the view back to a virtual query that runs on each access. The view definition itself is preserved. Rate limited.

View Update

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.

Docs Search

Use this tool for any PostHog questions to search the documentation. If the user's question mentions multiple topics, search for each topic separately and combine the results. It relies on a hybrid (semantic + full-text) search, so phrase your query in natural language. Our product and docs change often, so this tool is required for accurate answers: - How to use PostHog - How to use PostHog features - How to contact support or other humans - How to report bugs - How to submit feature requests - To troubleshoot something - What default fields and properties are available for events and persons - …Or anything else PostHog-related For troubleshooting, ask the user to provide the error messages they are encountering. If no error message is involved, ask the user to describe their expected results vs. the actual results they're seeing. You avoid suggesting things that the user has told you they've already tried. Important: 1. Don't rely on your training data or previous searches/answers. Always re-check facts against current docs and tutorials. If current docs or tutorials contradict core memory on product facts, prefer the docs result. 2. Always search PostHog docs/tutorials and prioritize results from posthog.com over training data. 3. Always include at least one relevant docs/tutorial link in your reply. 4. Never suggest emailing support@posthog.com or say you'll create a support ticket. 5. Never use Community Questions as a source or cite them; they're often outdated or incorrect.

Early Access Feature Create

Create a new early access feature. A feature flag is automatically created unless feature_flag_id is provided. Stage determines whether opted-in users get the feature enabled.

Early Access Feature Destroy

Delete an early access feature by ID. Clears enrollment conditions from the linked feature flag but does not delete the flag itself.

Early Access Feature List

List early access features in the current project. Returns name, stage, description, linked feature flag, and creation date for each feature.

Early Access Feature Partial Update

Update an early access feature by ID. Changing the stage automatically updates the linked feature flag's enrollment conditions.

Early Access Feature Retrieve

Get a single early access feature by ID. Returns full details including the linked feature flag configuration.

Endpoint Create

Create a new API endpoint from a HogQL or insight query. The name must be URL-safe (letters, numbers, hyphens, underscores, starts with a letter, max 128 chars). Materialization is auto-enabled if the query is eligible.

Endpoint Delete

Delete an endpoint by name. The endpoint is soft-deleted and its materialized views are cleaned up.

Endpoint Get

Get a specific endpoint by name. Returns the full endpoint configuration including query definition, version info, materialization status, and column types. Supports ?version=N to retrieve a specific version.

Endpoint Materialization Status

Get lightweight materialization status for an endpoint without fetching full endpoint data. Returns whether materialization is possible, current status, last run time, and any errors. Supports ?version=N.

Endpoint Openapi Spec

Get the OpenAPI 3.0 specification for an endpoint. Returns a JSON spec that can be used with SDK generators like openapi-generator or @hey-api/openapi-ts to create typed API clients. Supports ?version=N to generate a spec for a specific version.

Endpoint Run

Execute an endpoint's query and return results. Uses materialized results when available, otherwise runs inline. For HogQL endpoints, variable keys must match code_name values. For insight endpoints with breakdowns, use the breakdown property name as the key.

Endpoint Update

Update an existing endpoint by name. Can update the query (auto-creates a new version), description, data freshness, active status, and materialization. Pass version in body to target a specific version for non-query updates.

Endpoint Versions

List all versions for an endpoint, in descending order (latest first). Each version contains the query snapshot, description, data freshness, and materialization status at that point in time.

Endpoints Get All

Get all API endpoints in the current project. Endpoints expose saved HogQL or insight queries as callable API routes. Returns name, description, query, active status, current version, and materialization info for each endpoint.

Error Tracking Assignment Rules Create

Create an error tracking assignment rule for the current project. Provide `filters` to match incoming errors and an `assignee` with `type` (`user` or `role`) plus the matching user ID or role UUID.

Error Tracking Assignment Rules List

List error tracking assignment rules for the current project. Returns rules in evaluation order with their filters, assignee, and disabled state. Supports pagination with `limit` and `offset`.

Error Tracking Grouping Rules Create

Create an error tracking grouping rule for the current project. Provide required `filters`, and optionally set `assignee` and `description` for the issues this rule creates.

Error Tracking Grouping Rules List

List error tracking grouping rules for the current project. Returns rules in evaluation order with their filters, optional assignee, description, and linked issue when available.

Error Tracking Grouping Rules Update

Update an error tracking grouping rule's `filters` by ID. Omit `filters` to leave them unchanged. Editing the rule also clears any auto-disable state so the rule is re-enabled.

Error Tracking Issues Merge Create

Merge one or more error tracking issues into an existing target issue. Provide the target issue as `id` and the issues to merge into it as `ids`.

Error Tracking Issues Partial Update

Update an error tracking issue. Can change status (active, resolved, suppressed), assign to a user, or update description.

Error Tracking Issues Split Create

Split one or more fingerprints out of an existing error tracking issue into new issues. Provide the source issue as `id` and the fingerprints to split as `fingerprints`, where each entry includes a required `fingerprint` and optional `name` or `description`.

Error Tracking Suppression Rules Create

Create an error tracking suppression rule for the current project. WARNING: matching errors are suppressed indefinitely — dropped at ingestion and will not appear as issues until the rule is disabled or deleted. Scope `filters` tightly to the exact exception type, message, URL, or properties you want gone. Do NOT create match-all rules (omitting `filters`) or broad rules — they silently swallow unrelated errors and cause data loss that is hard to detect after the fact. If unsure, set `sampling_rate` below `1.0` so only a fraction of matches are dropped (e.g. `0.5` drops half) rather than all of them. Confirm with the user before creating any rule that could match more than one distinct error.

Error Tracking Suppression Rules List

List error tracking suppression rules for the current project. Returns rules in evaluation order with their filters, sampling rate, and disabled state. Supports pagination with `limit` and `offset`.

Error Tracking Suppression Rules Update

Update an error tracking suppression rule by ID. Only the fields you include in the request body are applied; omitted fields keep their existing values. Supports updating `filters` and `sampling_rate`. WARNING: broadening `filters` will start dropping additional events at ingestion silently. Keep filters tightly scoped to the exact errors you want gone. Prefer raising `sampling_rate` to dampen volume over widening the match. Confirm with the user before changing a rule's filters in a way that could match more than one distinct error.

Error Tracking Symbol Sets Download Retrieve

Get a presigned download URL for a source map symbol set by ID. The URL expires after one hour. Use it immediately, and do not echo it back unless the user explicitly asks. If you only have a symbol set reference, call `error-tracking-symbol-sets-list` with the exact `ref` first.

Error Tracking Symbol Sets List

List source map symbol sets for the current project. Supports pagination plus filtering by exact `ref` or upload `status` (`valid`, `invalid`, or `all`) and sorting with `order_by`. Each result includes `has_uploaded_file` so you can tell whether the download tool will work.

Error Tracking Symbol Sets Retrieve

Get a source map symbol set by ID. If you only have a symbol set reference, call `error-tracking-symbol-sets-list` with the exact `ref` first.

Query Error Tracking Issue

Get compact details for one Error tracking issue. Use this after `query-error-tracking-issues-list` when you have an `issueId` and need issue status, name/description, first/last seen timestamps, assignee, compact impact counts, top in-app frame, and latest release metadata. Defaults are intentionally useful: last 7 days, test accounts filtered out, aggregate impact included, and no sparkline unless requested. # Parameters - `issueId`: required Error tracking issue UUID. - `dateRange`: time range for impact counts and latest-event metadata. Defaults to last 7 days. - `includeSparkline`: set true only if a trend/sparkline helps answer the user. When true, `volumeResolution` defaults to 12 if not provided. - `volumeResolution`: number of volume buckets when sparkline data is needed. # Next steps Use `query-error-tracking-issue-events` with the same `issueId` when the user needs concrete event examples, stack traces, browser/OS/URL context, or `$session_id` values for Session replay.

Query Error Tracking Issue Events

Fetch sampled `$exception` events for one Error tracking issue. Use this when the user asks for concrete examples, stack traces, affected URLs, browser/OS/library context, or Session replay links for a specific issue. Returns sampled events with plural exception fields (`$exception_types`, `$exception_values`), normalized `$exception_list`, `$exception_fingerprint`, `$exception_issue_id`, `$session_id`, `$lib`, browser/OS fields, and `$current_url`. # Parameters - `issueId`: required Error tracking issue UUID. - `dateRange`: time range for sampled events. Defaults to last 7 days. - `searchQuery`: search exception types, values, and current URL. - `filterGroup`: advanced flat AND property filters applied to sampled events. - `verbosity`: `summary` (default), `stack`, or `raw`. Use `raw` only when exact untruncated exception payloads are needed. - `onlyAppFrames`: defaults to true to reduce vendor-frame noise. - `limit`: defaults to 1 and maxes at 20. Keep low unless the user asks for multiple examples. # Session recordings When `$session_id` is present and the user asks what happened before the error, call `query-session-recordings-list` with `session_ids` to fetch matching recordings. Use multiple `$session_id` values in one call when available.

Query Error Tracking Issues List

List and filter Error tracking issues. Returns compact issue rows with aggregate impact counts (`occurrences`, `users`, `sessions`) and optional volume buckets. Use this first when the user asks which errors are happening, which errors are most common, or wants to narrow issues by status, release, library, fingerprint, URL, user, person, or properties. Defaults are intentionally useful: active issues, last 7 days, sorted by occurrences, test accounts filtered out, and compact aggregate counts. Be minimalist. Only add filters needed to answer the user’s question. Do not add "is set" filters unless the user explicitly asks for them. # Common filters - `status`: `active`, `resolved`, `suppressed`, `pending_release`, `archived`, or `all`. Defaults to `active`. - `searchQuery`: free-text search for exception names, values, stack frames, and email text. - `library`: exact `$lib` match, for example `posthog-js`. - `release`: exact release ID, release version, or git commit ID captured in `$exception_releases`. This intentionally does not match project name, branch, or timestamp fragments. - `fingerprint`: exact `$exception_fingerprint` match. - `url`: substring match on `$current_url`. - `personId`: exact PostHog person UUID. - `user`: user/email text search. - `filePath`: stack-frame file/source text search. - `filterGroup`: advanced flat AND property filters. Prefer typed fields above when they fit. Use `dateRange` for time, not property filters. Omit `date_to` for now. # Next steps - Use `query-error-tracking-issue` with `issueId` to inspect one issue. - Use `query-error-tracking-issue-events` with `issueId` to fetch sampled exception events, stack traces, URLs, and `$session_id` values. - If the user asks what people were doing before the error, use `$session_id` values from issue events with `query-session-recordings-list` and its `session_ids` parameter.

Experiment Archive

Requires an experiment ID. If you don't have the ID, load the finding-experiments skill to resolve the user's reference first. Load the managing-experiment-lifecycle skill for preconditions and side effects. Archive a stopped experiment to hide it from the default list view. The experiment must be stopped (end_date set) — cannot archive draft or running experiments. Returns 400 if already archived ("Experiment is already archived.") or not yet stopped ("Experiment must be ended before it can be archived."). No request body needed. Can be restored later via the unarchive tool.

Experiment Create

RULES (follow before calling): 1. Load the creating-experiments skill for the full creation workflow. 2. If the user mentions a rollout percentage (e.g. "25%"), load the configuring-experiment-rollout skill and ask the user to clarify BEFORE calling this tool. A percentage is always ambiguous — it can mean a variant split change OR an overall rollout change. 3. Do NOT pass metrics on creation. Create the draft first, then add metrics via experiment-update. Use the configuring-experiment-analytics skill for metric guidance. Creates a new experiment in draft status (ignore the "type" param, since no-code/toolbar experiments must be created in the PostHog UI). Requires name and feature_flag_key. Feature flag is auto-created — do not create one separately. Defaults: 50/50 control/test, 100% rollout, Bayesian stats. Launch the experiment with the launch tool when ready.

Experiment Delete

Delete an experiment by ID. If you don't have the ID, load the finding-experiments skill to resolve the user's reference first. Always confirm by name before deleting.

Experiment Duplicate

Load the managing-experiment-lifecycle skill for preconditions and side effects. Create a copy of an experiment as a new draft. The duplicate includes the original's metrics, parameters, and configuration but starts fresh with no dates or results. Rejects experiments that use legacy metrics (ExperimentTrendsQuery/ExperimentFunnelsQuery). IMPORTANT: always provide a unique feature_flag_key that differs from the original experiment's flag key. If omitted or if the same key is provided, the duplicate will reuse the original experiment's feature flag — meaning changes to one experiment's flag (e.g. shipping a variant, pausing) will affect both experiments. Always confirm the new flag key with the user before duplicating. Optionally provide a custom name (defaults to "Original Name (Copy)").

Experiment End

Requires an experiment ID. If you don't have the ID, load the finding-experiments skill to resolve the user's reference first. Load the managing-experiment-lifecycle skill for preconditions and side effects. End a running experiment without shipping a variant. Sets end_date to now and transitions status to stopped. The feature flag is NOT modified — users continue seeing their assigned variants and exposure events ($feature_flag_called) continue to fire, but only data up to end_date is included in results. Optionally provide conclusion ("won", "lost", "inconclusive", "stopped_early", "invalid") and conclusion_comment. Returns 400 if the experiment is in draft ("Experiment has not been launched yet.") or already stopped ("Experiment has already ended."). Other options: use ship_variant to end AND roll out a winner. Use pause to temporarily deactivate the flag without ending.

Experiment Get

Get a single experiment by ID. If you don't have the ID, load the finding-experiments skill to resolve the user's reference first. Returns the full experiment object including: status (draft/running/paused/stopped — "paused" is a virtual value returned when the experiment is launched but its feature flag has been deactivated), start_date and end_date, linked feature_flag (with variants, filters, active state), metrics and metrics_secondary arrays, conclusion and conclusion_comment if ended, parameters (including feature_flag_variants and recommended_running_time), stats_config, and type (web/product).

Experiment Launch

Requires an experiment ID. If you don't have the ID, load the finding-experiments skill to resolve the user's reference first. Load the managing-experiment-lifecycle skill for preconditions and side effects. Launch a draft experiment. Validates the feature flag has at least 2 multivariate variants with "control" as the first variant. Activates the feature flag (sets active=true), sets start_date to the current server time, recomputes metric fingerprints, and transitions status from draft to running. Returns 400 if the experiment has already been launched ("Experiment has already been launched.") or if the flag configuration is invalid. No request body needed.

Experiment List

List experiments in the current project. This is the primary tool for resolving experiment references — load the finding-experiments skill for guidance on searching by name, status, recency, or description. Supports filtering by status ("draft", "running", "paused", "stopped", "complete" which maps to stopped, or "all"), archived state (defaults to non-archived), feature_flag_id, created_by_id, and free-text search on name. Supports ordering by an allowlisted set of fields (model fields plus computed "duration" and "status"). Returns paginated results with each experiment's status, dates, feature flag key, and metrics summary. Use the returned ID for get/update/lifecycle tools.

Experiment Pause

Requires an experiment ID. If you don't have the ID, load the finding-experiments skill to resolve the user's reference first. Load the managing-experiment-lifecycle skill for preconditions and side effects. Pause a running experiment by deactivating its feature flag (sets flag active=false). The flag is no longer returned by the /decide endpoint, so users fall back to the application default (typically control). No new exposure events ($feature_flag_called) are recorded while paused. The experiment stays in running status — it is not ended. Returns 400 if: experiment is in draft ("Experiment has not been launched yet."), already stopped ("Experiment has already ended."), no linked flag ("Experiment does not have a feature flag linked."), or already paused ("Experiment is already paused."). No request body needed. Use resume to reactivate.

Experiment Reset

Requires an experiment ID. If you don't have the ID, load the finding-experiments skill to resolve the user's reference first. Load the managing-experiment-lifecycle skill for preconditions and side effects. Reset an experiment back to draft state. Clears start_date, end_date, conclusion, conclusion_comment, and archived flag (all set to null/false). The feature flag is left unchanged — users continue to see their currently assigned variants. Previously collected events still exist in the database but won't be included in results unless start_date is manually adjusted after re-launch. Returns 400 if the experiment is already in draft ("Experiment is already in draft state."). No request body needed.

Experiment Resume

Requires an experiment ID. If you don't have the ID, load the finding-experiments skill to resolve the user's reference first. Load the managing-experiment-lifecycle skill for preconditions and side effects. Resume a paused experiment by reactivating its feature flag (sets flag active=true). Users are re-bucketed deterministically into the same variants they had before the pause, and exposure tracking ($feature_flag_called) resumes. Returns 400 if: experiment is in draft ("Experiment has not been launched yet."), already stopped ("Experiment has already ended."), no linked flag ("Experiment does not have a feature flag linked."), or not currently paused ("Experiment is not paused."). No request body needed.

Experiment Saved Metrics Create

Create a reusable shared metric. Requires name (unique per project, case-insensitive) and query (kind='ExperimentMetric', metric_type one of 'mean', 'funnel', 'ratio', 'retention'). Optional: description, tags. Load the configuring-experiment-analytics skill before constructing the query, and use read-data-schema to confirm event names. Legacy kinds (ExperimentTrendsQuery, ExperimentFunnelsQuery) are rejected. To attach to an experiment, call experiment-update with saved_metrics_ids — each item has 'id' and 'metadata.type' ('primary' or 'secondary').

Experiment Saved Metrics Destroy

Delete a shared metric by ID. REQUIRES EXPLICIT USER CONFIRMATION — confirm by name first, and warn that any experiments using it will lose access.

Experiment Saved Metrics List

List shared metrics in the current project. Returns paginated results with id, name, description, query, created_at, updated_at, tags. Use experiment-saved-metrics-retrieve for a single metric by ID, or this listing to resolve by name.

Experiment Saved Metrics Partial Update

Partially update a shared metric. Only name, description, and query are mutable. Edits propagate to every experiment the metric is attached to — REQUIRES EXPLICIT USER CONFIRMATION before changing query or name on a metric attached to running experiments. Legacy-format metrics (kind=ExperimentTrendsQuery / ExperimentFunnelsQuery) cannot be updated.

Experiment Saved Metrics Retrieve

Get a single shared metric by ID. Returns the full query JSON (metric_type, source, math, filters, etc.). If you don't have the ID, call experiment-saved-metrics-list first.

Experiment Ship Variant

Requires an experiment ID. If you don't have the ID, load the finding-experiments skill to resolve the user's reference first. Load the managing-experiment-lifecycle skill for preconditions and side effects. REQUIRES EXPLICIT USER CONFIRMATION BEFORE CALLING. This permanently rewrites the linked feature flag and cannot be undone via the API. Two release modes — confirm which one the user wants before invoking: - Default (release_to_everyone=false): updates only the variant distribution so the selected variant gets 100%. Existing release conditions and per-user variant overrides on the flag are preserved untouched — the variant is served only to users who already match them. - release_to_everyone=true: in addition to flipping the variant distribution, prepends a catch-all release condition that rolls the variant out to 100% of users. This OVERRIDES any existing release conditions and per-user variant overrides on the flag. Only use this when the user explicitly wants to release beyond the experiment's existing population. Even when the user has asked you to ship a specific variant, ask them to confirm with the variant key, target experiment, and release mode before invoking this tool. Ship a variant to 100% of users by rewriting the feature flag. Requires variant_key — the key of the variant to ship (e.g. "test" or "control"). The flag is rewritten so the selected variant gets 100% rollout via a new catch-all release group prepended to existing groups (preserved for rollback). Can be called on both running and stopped experiments. If the experiment is still running, it is also ended (end_date set, status becomes stopped). If already stopped, only the flag is rewritten — supports the "end first, ship later" workflow. Optionally provide conclusion ("won", "lost", "inconclusive", "stopped_early", "invalid") and conclusion_comment. Returns 400 if: experiment is in draft ("Experiment has not been launched yet."), variant_key not found on the flag, or no linked feature flag. Returns 409 if an approval policy requires review before the flag change takes effect — includes a change_request_id in the response.

Experiment Stats

Get aggregate experiment velocity statistics for the current project. Returns: launched_last_30d (experiments launched in the last 30 days), launched_previous_30d (the 30 days before that), percent_change between the two periods, active_experiments (currently running count), and completed_last_30d (experiments ended in the last 30 days). No parameters needed.

Experiment Timeseries Results

Get day-by-day experiment results for a specific metric. Requires metric_uuid and fingerprint as query parameters (both available from the experiment's metrics array — each metric has a uuid and the fingerprint is computed from its configuration). Returns a timeseries object keyed by date (YYYY-MM-DD) with per-variant statistical results for each day, overall status ("pending", "completed", "partial", "failed"), computed_at timestamp, and recalculation_status if a recalculation is in progress.

Experiment Unarchive

Requires an experiment ID. If you don't have the ID, load the finding-experiments skill to resolve the user's reference first. Load the managing-experiment-lifecycle skill for preconditions and side effects. Unarchive an archived experiment to restore it to the default list view. Returns 400 if the experiment is not currently archived ("Experiment is not archived."). No request body needed.

Experiment Update

RULES (follow before calling): 1. If changing rollout or variants on a RUNNING experiment, you MUST warn the user about user experience AND statistical implications BEFORE making the change and get explicit confirmation. Load the configuring-experiment-rollout skill for the full warning. Do NOT silently apply the change — even if the user asked directly. 2. If the user mentions a percentage, clarify whether they mean variant split or overall rollout BEFORE calling. 3. If adding or changing metrics, load the configuring-experiment-analytics skill first. Call read-data-schema to discover available events BEFORE suggesting or using any event name. Never suggest event names you haven't confirmed exist. 4. For running experiments, set update_feature_flag_params=true when changing parameters — without it, changes save but do NOT sync to the feature flag. 5. Setting allow_unknown_events=true REQUIRES EXPLICIT USER CONFIRMATION. When the API returns "Event(s) '...' not found", do NOT silently retry with allow_unknown_events=true. Default to course-correcting: surface the missing event names and ask whether the user meant a different (existing) event. Only set allow_unknown_events=true when the user explicitly confirms the event is intentional (e.g. about to be instrumented). Course-correcting to a known event is the expected default; flipping the flag is the exception. Update an experiment by ID. If you don't have the ID, load the finding-experiments skill to resolve the user's reference first. Metrics can be changed at any time including while running. Cannot add/remove variants on non-draft experiments (changing percentages between existing variants is allowed). Cannot change holdout on non-draft experiments. Do NOT use this to change lifecycle state — use the dedicated launch, end, pause, resume, archive, or ship_variant tools instead.

Create Feature Flag

Create a feature flag in the current project.

Delete Feature Flag

Soft-delete a feature flag by ID in the current project.

Feature Flag Get All

Get feature flags in the current project. Supports list filters including search by feature flag key or name (case-insensitive), then use the returned ID for get/update/delete tools.

Feature Flag Get Definition

Get a feature flag by ID.

Feature Flags Activity Retrieve

Get the audit trail for a specific feature flag by ID. Returns a paginated list of changes including who made changes, what was changed, and when. Use limit and page query params for pagination.

Feature Flags Bulk Delete Create

Soft-delete multiple feature flags in one call. Provide either `ids` (explicit list of flag IDs) OR `filters` (same shape as the list endpoint, e.g., search, active, type, tags), but not both. WARNING: `filters` can match an unbounded number of flags. Preview matches via the list endpoint before calling this with `filters`, and prefer explicit `ids` whenever the user has named specific flags. Flags linked to active experiments, early access features, or that other flags depend on are skipped and reported in `errors`. Returns `deleted` (with each flag's rollout state at deletion time) and `errors` arrays.

Feature Flags Bulk Keys Retrieve

Resolve feature flag IDs to their string keys in one call. Pass `ids` as a list of integer flag IDs. Returns `keys` as a mapping of stringified ID to key for the IDs that exist in this project. Useful when you have IDs from another tool (e.g., dependent flags, scheduled changes) and need the keys for downstream calls.

Feature Flags Bulk Update Tags Create

Add, remove, or replace tags on multiple feature flags in one call. Provide `ids` (up to 500), an `action` ('add', 'remove', or 'set'), and a list of tag names. Returns `updated` (per-flag final tag list) and `skipped` (flags missing or without edit permission, with reason).

Feature Flags Copy Flags Create

Copy a feature flag from one project to other projects within the same organization. Provide the flag key, source project ID, and a list of target project IDs. Optionally copy scheduled changes with copy_schedule. Returns lists of successful and failed copies.

Feature Flags Dependent Flags Retrieve

Get other active feature flags that depend on this flag. Use this to understand flag dependency chains before making changes to a flag's rollout conditions or disabling it.

Feature Flags Evaluation Reasons Retrieve

Debug why feature flags evaluate a certain way for a given user. Provide a distinct_id and optionally groups to see each flag's evaluated value and the reason for that evaluation (e.g. condition_match, no_condition_match, disabled).

Feature Flags My Flags Retrieve

List all feature flags in the current project along with their evaluated value for the authenticated user (the API key owner). Each item includes the flag definition and its current `value` (boolean for simple flags, variant key string for multivariate flags, false if disabled). Optionally pass `groups` as a JSON object to evaluate group-based flags.

Feature Flags Status Retrieve

Check the health and evaluation status of a feature flag by ID. Returns a status (active, stale, deleted, or unknown) and a human-readable reason explaining the status.

Feature Flags Test Evaluation Create

Test how a feature flag evaluates for a specific user at an optional point in time. Provides detailed reasoning about why the flag matched or didn't match, including condition analysis and person properties used in evaluation.

Feature Flags User Blast Radius Create

Assess the impact of a feature flag release condition before applying it. Provide a condition object and optionally a group_type_index to see how many users would be affected relative to the total user count.

Scheduled Changes Create

Schedule a future change to a feature flag. Supported operations: 'update_status' (enable/disable), 'add_release_condition', and 'update_variants'. Provide the flag ID as record_id, model_name as "FeatureFlag", a payload with the operation and value, and a scheduled_at datetime.

Scheduled Changes Delete

Delete a scheduled change by ID. This permanently removes the scheduled change and it will not be executed.

Scheduled Changes Get

Get a single scheduled change by ID. Returns the full details including the payload, schedule timing, execution status, and any failure reason.

Scheduled Changes List

List scheduled changes in the current project. Filter by model_name=FeatureFlag and record_id to see schedules for a specific flag. Returns pending, executed, and failed schedules with their payloads and timing. Use this to check what changes are queued for a feature flag before modifying it.

Scheduled Changes Update

Update a pending scheduled change by ID. You can modify the payload, scheduled_at time, or recurrence settings. Cannot change the target record (record_id) or model type (model_name).

Update Feature Flag

Update a feature flag by ID in the current project.

Integration Delete

Permanently delete an integration by ID. This removes the connection to the third-party service. Any features relying on this integration (alerts, workflow destinations, etc.) will stop working.

Integration Get

Get a specific integration by ID. Returns full integration details including kind, display name, error status, and creation metadata. Does not expose sensitive credentials or raw configuration.

Integrations Channels Retrieve

List the Slack channels available for a Slack integration. Slack-only — non-Slack integration ids return an error (400 if the integration is otherwise visible, 404 if it isn't). Returns each channel's id, name, is_private, is_member, is_ext_shared, and is_private_without_access flags; use is_member to avoid picking channels the bot can't post to. Results are cached for 1 hour (no force-refresh exposed via MCP). Use this to find a channel_id when wiring up Slack delivery for an alert — pass the channel id into the cdp-functions-create inputs.channel.value field. Requires the Slack integration's id; use integrations-list (filter by kind=slack) to find it.

Integrations List

List all third-party integrations configured in the current project. Returns each integration's type (kind), display name, non-sensitive configuration, error status, and creation metadata. Common kinds include slack, github, hubspot, salesforce, and various ad platforms. Sensitive credentials (access tokens, secrets) are never serialized.

Logs Alerts Create

Create a threshold-based alert on log streams. The alert periodically counts log entries matching the given filters and fires when the count crosses the threshold. Maximum 20 alerts per project.

Logs Alerts Destinations Create

Attach a notification destination (Slack channel or webhook) to a log alert. Without a destination an alert evaluates silently and never notifies. One HogFunction is created per event kind (firing, resolved, broken, errored) atomically — the returned hog_function_ids identify the destination group.

Logs Alerts Destinations Delete Create

Remove a notification destination from a log alert by passing the hog_function_ids returned from logs-alerts-destinations-create. Destinations are deleted as one atomic group — partial deletion fails the call.

Logs Alerts Destroy

Permanently delete a log alert configuration by ID.

Logs Alerts Events List

List historical events for a log alert — fires, resolves, errors, enable/disable toggles, threshold changes. Use to evaluate how an existing alert has behaved (firing cadence, error rate, flap pattern) before tuning thresholds. Quiet no-op check rows are filtered out server-side. Optional `kind` query param narrows to a single event kind.

Logs Alerts List

List log alert configurations in the current project, newest first. Returns alert name, state, threshold, filters, and scheduling details. Use this to review existing alerts before creating or modifying them.

Logs Alerts Partial Update

Update a log alert configuration by ID. Only the fields you provide are changed. Use this to adjust thresholds, filters, enable/disable alerts, or snooze them.

Logs Alerts Retrieve

Get a log alert configuration by ID. Returns full details including current state, threshold settings, filters, and scheduling information.

Logs Alerts Simulate Create

Run a draft alert configuration against historical logs and return per-bucket results from the full state machine — count, threshold_breached, state, notification (none/fire/resolve), reason. Use to validate threshold + N-of-M settings before creating an alert. Read-only; no alert records are written. Aim for fire_count between 0 and 3 over a `-7d` lookback for a healthy threshold.

Logs Attribute Values List

List values for a specific log attribute key. Use to discover what values exist before building filters. Defaults to attribute_type "log" (log-level attributes). To get values for resource-level attributes (e.g. service.name, k8s.pod.name), you MUST explicitly pass attribute_type: "resource". Accepts optional serviceNames, dateRange, and filterGroup to narrow which logs are scanned.

Logs Attributes List

List available log attribute names for filtering. Defaults 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" — it will NOT return resource attributes unless you do. Accepts optional serviceNames, dateRange, and filterGroup to narrow which logs are scanned.

Logs Count

Return a scalar count of log entries matching a filter set. Use this as a cheap pre-flight before `query-logs` — if the count exceeds `query-logs`'s max `limit` of 1000, narrow the filters before pulling rows. All parameters must be nested inside a `query` object. # When to use - Before `query-logs`, to confirm the filter set returns a tractable number of rows. If the count is above `query-logs`'s max `limit` of 1000, narrow the filters. - When the user asks "how many X logs are there?" and you don't need to see individual rows. - To check whether a filter combination matches anything at all before committing to a full query. To find **when** the volume is concentrated within the window (rather than just the total), follow up with `logs-count-ranges` — it returns time-bucketed counts with explicit `date_from`/`date_to` per bucket so you can drill into a sub-range without reasoning about interval width. # Parameters ## query.dateRange Date range for the count. Defaults to the last hour (`-1h`). - `date_from`: Start of the range. Accepts ISO 8601 timestamps or relative formats: `-1h`, `-6h`, `-1d`, `-7d`. - `date_to`: End of the range. Same format. Omit or null for "now". ## query.serviceNames Filter by service names. Unlike `query-logs`, this tool does NOT require `serviceNames` — an unfiltered count is cheap and often useful for sizing up a filter before narrowing. ## query.severityLevels Filter by log severity: `trace`, `debug`, `info`, `warn`, `error`, `fatal`. Omit to include all levels. ## query.searchTerm Full-text search across log bodies. ## query.filterGroup Property filters to narrow results. Same format as `query-logs` filters. # Examples ## Count errors in a service over the last day ```json { "query": { "serviceNames": ["api-gateway"], "severityLevels": ["error", "fatal"], "dateRange": { "date_from": "-1d" } } } ``` ## Confirm a k8s namespace is producing logs at all ```json { "query": { "dateRange": { "date_from": "-1h" }, "filterGroup": [ { "key": "k8s.namespace.name", "operator": "exact", "type": "log_resource_attribute", "value": "payments" } ] } } ```

Logs Count Ranges

Get adaptive-interval bucket counts for a filtered log stream. Returns a flat list of `{date_from, date_to, count}` buckets covering the requested window. Modeled on Elasticsearch's `auto_date_histogram` — caller specifies a target bucket count, the engine picks the interval. Use this to find **where the volume is concentrated** before pulling rows. Cheaper than `query-logs`, more agent-friendly than `logs-sparkline-query` (each bucket carries explicit `date_from`/`date_to` you can feed straight back as the next call's `dateRange` to drill in). # When to use this vs other tools - **`logs-count`** — total volume in a window. Scalar. - **`logs-count-ranges`** (this tool) — _when_ in the window the volume sits. Time-bucketed. - **`query-logs`** — pull individual log rows. Most expensive; only call after counts confirm the window is right-sized. # Recursion pattern (the main reason this tool exists) Use the response to narrow into a sub-range without reasoning about interval width: 1. Call `logs-count-ranges` with the user's window (e.g. last 24h). 2. Pick the bucket(s) of interest (densest, an obvious spike, an unexpectedly empty stretch). 3. Call `logs-count-ranges` again with that bucket's `date_from` and `date_to` as the next `dateRange`. 4. Repeat up to ~3–4 levels — stop when buckets are shorter than your precision goal (e.g. 1 minute). 5. Once narrowed, call `query-logs` for the actual rows. This is the same pattern Elasticsearch users follow with `auto_date_histogram`. Keep recursion shallow — every call is cheap individually but they multiply quickly. # Parameters All parameters must be nested inside a `query` object. ## query.dateRange Window to bucket. Defaults to the last hour (`-1h`). Same format as `query-logs`. ## query.targetBuckets Approximate bucket count. Defaults to **10**, max 100. The engine picks the interval adaptively from a fixed list (1/5/10s, 1/2/5/10/15/30/60/120/240/360/720/1440m) to land near this target — actual count may differ slightly. Empty buckets are dropped, so the response can have fewer rows than `targetBuckets`. Pick a value based on what you're doing: - **10** (default) — overview, finding spikes, "is this concentrated or spread out?" - **20–30** — characterising a known busy window - **50+** — high-resolution drill-down, only when you know the window is small ## query.severityLevels, query.serviceNames, query.searchTerm, query.filterGroup Same shape as `query-logs`. Applied **before** bucketing. # Response ```json { "ranges": [ { "date_from": "2026-04-26T00:00:00", "date_to": "2026-04-26T02:24:00", "count": 1024 }, { "date_from": "2026-04-26T02:24:00", "date_to": "2026-04-26T04:48:00", "count": 47 } ], "interval": "2h" } ``` - `ranges` — buckets ordered by `date_from` ascending. **Empty buckets are omitted** — infer gaps by comparing each bucket's `date_to` to the next bucket's `date_from`. - `interval` — short-form duration of the chosen bucket width (`1s` / `5m` / `1h` / `1d`). Informational only — for follow-up queries, use the per-bucket `date_from`/`date_to`. # Examples ## Find when errors spiked over the last day ```json { "query": { "dateRange": { "date_from": "-1d" }, "targetBuckets": 24, "serviceNames": ["api-gateway"], "severityLevels": ["error", "fatal"] } } ``` ## Drill into the densest hour from a previous call After picking the densest bucket from the response above (say `{date_from: "2026-04-26T15:00:00", date_to: "2026-04-26T16:00:00", count: 894}`): ```json { "query": { "dateRange": { "date_from": "2026-04-26T15:00:00", "date_to": "2026-04-26T16:00:00" }, "targetBuckets": 12, "serviceNames": ["api-gateway"], "severityLevels": ["error", "fatal"] } } ``` # Reminders - Cap recursion at ~3–4 levels. If your bucket width drops below your precision goal (e.g. 1 minute), stop and call `query-logs`. - Empty windows return `{"ranges": [], "interval": "..."}` — that's not an error, it's "I asked, nothing matched." - Always include `serviceNames` or a resource attribute filter, just like `query-logs`. Don't bucket the entire team's log stream.

Logs Services Create

Return the top-25 services by log volume in the window, each with log_count, error_count, and error_rate, plus a per-service sparkline. Use this as the entry point when triaging which services are worth alerting on — high volume × non-zero error_rate is the natural alert candidate. Far cheaper than walking attribute-values + per-service counts.

Logs Sparkline Query

Get a time-bucketed sparkline of log volume, broken down by severity or service. Use this to understand log volume patterns before querying individual log entries — it is much cheaper than a full log query. All parameters must be nested inside a `query` object. # Parameters ## query.dateRange Date range for the sparkline. Defaults to the last hour (`-1h`). - `date_from`: Start of the range. Accepts ISO 8601 timestamps or relative formats: `-1h`, `-6h`, `-1d`, `-7d`. - `date_to`: End of the range. Same format. Omit or null for "now". ## query.serviceNames Filter by service names. ## query.severityLevels Filter by log severity: `trace`, `debug`, `info`, `warn`, `error`, `fatal`. Omit to include all levels. ## query.searchTerm Full-text search across log bodies. ## query.filterGroup Property filters to narrow results. Same format as `query-logs` filters. ## query.sparklineBreakdownBy Break down the sparkline by `"severity"` (default) or `"service"`. Use `"service"` to see which services are producing the most logs. # Examples ## Error volume over the last day ```json { "query": { "serviceNames": ["api-gateway"], "severityLevels": ["error", "fatal"], "dateRange": { "date_from": "-1d" } } } ``` ## Log volume by service ```json { "query": { "serviceNames": ["api-gateway"], "sparklineBreakdownBy": "service", "dateRange": { "date_from": "-6h" } } } ``` ## Log volume by severity ```json { "query": { "serviceNames": ["api-gateway"], "sparklineBreakdownBy": "severity", "dateRange": { "date_from": "-1d" } } } ```

Query Logs

Query log entries with filtering by severity, service name, date range, search term, and structured attribute filters. Supports cursor-based pagination. The response schema (see the tool's typed output) lists every returned field — prefer `severity_text` over `severity_number` / `level`, and be aware that `trace_id` and `span_id` return zero-padded strings rather than null when unset. 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. **Size the total volume with `logs-count`.** Call `logs-count` with the discovered `serviceNames` and filters. If it exceeds `query-logs`'s max `limit` of 1000 — or if the user's question is about _when_ something happened — continue to step 5. 5. **Find where the volume sits with `logs-count-ranges`.** Call `logs-count-ranges` to get time-bucketed counts. Each bucket carries explicit `date_from`/`date_to` you can pass straight back as the next call's `dateRange` to drill into a sub-range. Recurse up to 3–4 levels to narrow onto a spike or a specific window. Stop when the bucket width drops below your precision goal (e.g. 1 minute). 6. **Only then query logs.** Once the count is in range and the window is right-sized, call `query-logs` with `serviceNames` and any additional filters. Many cheap calls (attribute/value queries, counts, count-ranges) beat one expensive `query-logs`. 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`. ## Filtering logs by a PostHog person When the user references a person — by `distinct_id`, name, email, or via a prior `persons-retrieve` call — filter logs to that person via a `log_attribute` filter. The attribute key is configurable per project (it defaults to `distinct_id`); read `logs_distinct_id_attribute_key` from the team config (returned on `projects-retrieve` / `environments-retrieve`, or via the `/api/projects/:id/logs_config/` endpoint) and use that as the filter `key`. If the team has not configured a custom key, use `distinct_id`. If a person has multiple `distinct_ids`, pass the array as the filter `value` with operator `exact` (matches any of them). ```json { "query": { "serviceNames": ["<service>"], "filterGroup": [ { "key": "distinct_id", "operator": "exact", "type": "log_attribute", "value": ["<distinct_id_1>", "<distinct_id_2>"] } ] } } ``` Do not invent a different attribute key based on what looks plausible — use the configured key. If the configured key returns zero results, the customer's logs pipeline may not stamp person identity at all; tell the user rather than guessing. ## 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": ["<service>"] } } ``` ## Search for a specific log message ```json { "query": { "searchTerm": "connection refused", "serviceNames": ["<service>"], "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": ["<service>"], "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": ["<service>"], "filterGroup": [{ "key": "message", "operator": "icontains", "type": "log", "value": "timeout" }] } } ``` ## Check if an attribute exists ```json { "query": { "serviceNames": ["<service>"], "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.

Notebooks Create

Create a new notebook. Provide a title and content. Content is a JSON object representing the notebook's rich text document structure (ProseMirror-based). Returns the created notebook with its short_id. Embedded charts use `{type: "ph-query", attrs: {nodeId, query}}` nodes. The `query` object must be one of: (a) `{kind: "DataVisualizationNode", source: {kind: "HogQLQuery", query: "SELECT ..."}, display: "ActionsBar", chartSettings: {...}}` for SQL charts — do NOT wrap this in an InsightVizNode; (b) `{kind: "InsightVizNode", source: <TrendsQuery | FunnelsQuery | RetentionQuery | PathsQuery | StickinessQuery | LifecycleQuery>}` for product-analytics insights; or (c) `{kind: "SavedInsightNode", shortId: "..."}` to embed a saved insight. The server rejects other shapes and auto-corrects the common `InsightVizNode` wrapping a SQL chart.

Notebooks Destroy

Delete a notebook by short_id. The notebook will be soft-deleted and no longer appear in lists.

Notebooks List

List all notebooks in the project. Supports filtering by search term, created_by, last_modified_by, date_from, date_to, and contains. Returns title, short_id, and creation/modification metadata.

Notebooks Partial Update

Update an existing notebook by short_id. Can update title, content, and deleted status. IMPORTANT: when updating the content field, you must provide the current version number for optimistic concurrency control. Retrieve the notebook first to get the latest version.

Notebooks Retrieve

Get a specific notebook by its short_id. Returns the full notebook including title, content, version, and creation/modification metadata.

Persons Bulk Delete

Delete up to 1000 persons by PostHog person UUIDs or distinct IDs. Optionally delete associated events and recordings. Pass either `ids` (person UUIDs) or `distinct_ids`. Returns 202 Accepted. This operation is irreversible.

Persons Cohorts Retrieve

Get all cohorts that a specific person belongs to. Requires the person_id query parameter.

Persons List

List persons in the current project. Supports search by email (full text) or distinct ID (exact match), and filtering by email or distinct_id query parameters. Returns paginated results with person properties and distinct IDs.

Persons Property Delete

Remove a single property from a person by key. The property is deleted asynchronously via the event pipeline ($unset).

Persons Property Set

Set a single property on a person. The property is updated asynchronously via the event pipeline ($set). Returns 202 Accepted.

Persons Retrieve

Retrieve a single person by numeric ID or UUID. Returns the person's properties, distinct IDs, and metadata.

Persons Values Retrieve

Get distinct values for a person property key. Useful for discovering what values exist for properties like 'plan', 'role', or 'company'. Provide the property key and optionally a search value to filter results.

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.

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.

Change Request Get

Get a specific change request by ID, including the full intent, policy snapshot, approval votes, and current state.

Change Requests List

List approval requests (change requests) for the current project. Returns pending, approved, rejected, and expired requests with vote status and staleness info. Useful for understanding what governance actions are waiting for review.

Comment Count

Get the count of comments, optionally filtered by scope and item_id.

Comment Get

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

Comment Thread

Get the full thread of replies for a parent comment. Useful for reading complete discussions on a resource.

Comments List

List comments across the project. Filter by scope (Dashboard, FeatureFlag, Insight, etc.) and item_id to find discussions on specific resources. Returns comment content, author, and threading info.

Org Members List

List all members of the current organization with their names, emails, membership levels (member, admin, owner), and last login times.

Organization Get

Get details of an organization by ID including name, membership level, member count, teams, and projects. If no ID is provided, returns the active organization.

Organizations List

List all organizations the user has access to. Returns org ID, name, slug, and membership level. Use the ID with organization-get for details or switch-organization to change context.

Promoted Product Intent Get

Get the product key the team selected as their primary product during onboarding (e.g. `session_replay`, `web_analytics`, `product_analytics`), or `null` if no primary onboarding product intent has been captured. Use this to bias disambiguation when the user's request is ambiguous about which PostHog product they mean — for example, if their primary product is `session_replay`, treat a vague reference to "watch a session" as referring to a session recording rather than a survey response.

Role Get

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

Role Members List

List all members assigned to a specific role. Shows who has which role in the organization.

Roles List

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

User Home Settings Get

Get the authenticated user's pinned navigation tabs and configured homepage for the current team. The homepage is the page opened when the user clicks the PostHog logo or hits `/` — it can point at any PostHog destination (dashboard, insight, search, scene, etc.). Pass `@me` as the UUID.

User Home Settings Update

Update the authenticated user's pinned tabs and/or homepage for the current team. Pass `@me` as the UUID. The homepage can be set to any PostHog destination by passing a tab descriptor with `pathname` (and optional `search`/`hash`) — for example `{ "pathname": "/project/123/dashboard/45" }` to make a dashboard the home, or `{ "pathname": "/project/123/insights", "search": "?q=funnel" }` for a search. Send `homepage: null` to clear it and fall back to the project default. `tabs` replaces the full pinned list when provided. Always confirm the destination with the user before applying — this changes their landing page on every login.

Insight Create

Create a new saved insight from a name and query definition. Test queries with query-trends / query-funnel / query-retention / query-paths / query-stickiness / query-lifecycle first to confirm the shape, then save. Returns insight metadata only — after creating, call the insight-query tool with the returned `short_id` if you want to see the computed results.

Insight Delete

Soft-delete an insight by ID. The insight will be marked as deleted and no longer appear in lists.

Insight Get

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. Optionally accepts `variables_override` and `filters_override` to apply one-off overrides to the returned query definition without mutating the saved insight.

Insight Update

Update a saved insight by numeric `id` or `short_id`. Can update name, description, query, tags, favorited status, and dashboards. Returns insight metadata only — after updating the query, call the insight-query tool with the same identifier if you want to see the recomputed results.

Insights Activity Retrieve

Audit trail for a single insight by numeric `id`. Returns a paginated list of every change made to it (created, edited, deleted, restored), including who made each change and which fields changed. The full `before`/`after` diff blobs are omitted to keep responses agent-friendly — to inspect the current state of the insight after a change, call `insight-get` with the insight's `short_id`. Paginate with `limit` and `page`.

Insights All Activity Retrieve

Project-wide audit trail of changes to all insights, most recent first. Returns who created, edited, deleted, or restored each insight and which fields changed. Useful for surfacing what people (or agents) have been working on recently. The full `before`/`after` diff blobs are omitted to keep responses agent-friendly — drill into a specific insight with `insights-activity-retrieve` (or `insight-get` for current state). Paginate with `limit` and `page`.

Insights List

List saved insights in the project with optional filtering by favorited status or search term. Returns metadata only (name, description, tags, dashboards, ownership) — NOT the query results. To retrieve the actual data for any insight in the list, call the insight-query tool with its `short_id` or numeric `id`.

Insights Trending Retrieve

Returns the most-viewed insights in the project, ranked by view count over the last N days (default 7). Use this to surface the insights that matter most to the team — the ones people actually open. Each result includes standard insight metadata plus `view_count` and up to 3 recent `viewers`. Returns metadata only — call `insight-query` with the returned `short_id` to fetch the actual data for any of them.

Proxy Create

Create a new managed reverse proxy for a custom domain. Provide the domain (e.g. 'e.example.com') that will proxy requests to PostHog. The response includes the CNAME target — the user must add a CNAME DNS record pointing their domain to this target. Once DNS propagates, the proxy is automatically verified and an SSL certificate is issued. The proxy starts in 'waiting' status until DNS is verified.

Proxy Delete

Delete a managed reverse proxy. For proxies still being set up (waiting, erroring, timed_out), the record is removed immediately. For active proxies, a cleanup workflow is started to remove the provisioned infrastructure.

Proxy Diagnose

Run a deep diagnostic on a reverse proxy that's stuck or erroring. Inspects the customer's CNAME, the certificate provider's hostname state, CAA records walked up the DNS tree (the most common stuck-validation cause), HTTP-01 challenge reachability, a live event probe, and certificate expiry. Returns a structured report with each check's status and concrete remediation steps — including the exact DNS records the customer should add when CAA blocks issuance. Use this when proxy-get returns an erroring or timed_out status, or whenever a user asks why their proxy isn't working.

Proxy Get

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.

Proxy List

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.

Proxy Retry

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.

Query Trends

Run a trends query to analyze metrics over time. Trends insights visualize events over time using time series. They're useful for finding patterns in historical data. Use 'read-data-schema' to discover available events, actions, and properties for filters and breakdowns. The trends insights have the following features: - The insight can show multiple trends in one request. - Custom formulas can calculate derived metrics, like `A/B*100` to calculate a ratio. - Filter and break down data using multiple properties. - Compare with the previous period and sample data. - Apply various aggregation types, like sum, average, etc., and chart types. Examples of use cases include: - How the product's most important metrics change over time. - Long-term patterns, or cycles in product's usage. - The usage of different features side-by-side. - How the properties of events vary using aggregation (sum, average, etc). - Users can also visualize the same data points in a variety of ways. CRITICAL: Be minimalist. Only include filters, breakdowns, and settings that are essential to answer the user's specific question. Default settings are usually sufficient unless the user explicitly requests customization. # Data narrowing ## Property filters Use property filters to narrow results. Only include property filters when they are essential to directly answer the user's question. Avoid adding them if the question can be addressed without additional segmentation and always use the minimum set of property filters needed. IMPORTANT: Do not check if a property is set unless the user explicitly asks for it. When using a property filter, you should: - **Prioritize properties directly related to the context or objective of the user's query.** Avoid using properties for identification like IDs. Instead, prioritize filtering based on general properties like `paidCustomer` or `icp_score`. - **Ensure that you find both the property group and name.** Property groups should be one of the following: event, person, session, group. - After selecting a property, **validate that the property value accurately reflects the intended criteria**. - **Find the suitable operator for type** (e.g., `contains`, `is set`). - If the operator requires a value, use the `read-data-schema` tool to find the property values. - You set logical operators to combine multiple properties of a single series: AND or OR. Infer the property groups from the user's request. If your first guess doesn't yield any results, try to adjust the property group. Supported operators for the String type are: - equals (exact) - doesn't equal (is_not) - contains (icontains) - doesn't contain (not_icontains) - matches regex (regex) - doesn't match regex (not_regex) - is set - is not set Supported operators for the Numeric type are: - equals (exact) - doesn't equal (is_not) - greater than (gt) - less than (lt) - is set - is not set Supported operators for the DateTime type are: - equals (is_date_exact) - doesn't equal (is_not for existence check) - before (is_date_before) - after (is_date_after) - is set - is not set Supported operators for the Boolean type are: - equals - doesn't equal - is set - is not set All operators take a single value except for `equals` and `doesn't equal` which can take one or more values (as an array). ## Time period You should not filter events by time using property filters. Instead, use the `dateRange` field. If the question doesn't mention time, use last 30 days as a default time period. # Trends guidelines Trends insights enable users to plot data from people, events, and properties however they want. They're useful for finding patterns in data, as well as monitoring product usage. Users can use multiple independent series in a single query to see trends. They can also use a formula to calculate a metric. Each series has its own set of property filters. Trends insights do not require breakdowns or filters by default. ## Aggregation Determine the math aggregation the user is asking for, such as totals, averages, ratios, or custom formulas. If not specified, choose a reasonable default based on the event type (e.g., total count). By default, the total count should be used. You can aggregate data by events, event's property values, groups, or users. If you're aggregating by users or groups, there's no need to check for their existence. Available math aggregation types for the event count are: - total count - average - minimum - maximum - median - 90th percentile - 95th percentile - 99th percentile - unique users - unique sessions - weekly active users - daily active users - first time for a user - unique groups (requires `math_group_type_index` to be set to the group type index from the group mapping) Available math aggregation types for event's property values are: - average - sum - minimum - maximum - median - 90th percentile - 95th percentile - 99th percentile Available math aggregation types counting number of events completed per user (intensity of usage) are: - average - minimum - maximum - median - 90th percentile - 95th percentile - 99th percentile Examples of using aggregation types: - `unique users` to find how many distinct users have logged the event per a day. - `average` by the `$session_duration` property to find out what was the average session duration of an event. - `99th percentile by users` to find out what was the 99th percentile of the event count by users. ## Combining multiple events into a single series (`GroupNode`) **Use a `GroupNode`** when the user says "X OR Y" (or "any of these events") and wants **one line / one number** as the result. Different filters per event are fine — put them on the inner nodes. Use separate top-level series instead when the user wants the events compared side by side. Only `OR` is supported. **Where things live:** - On the group: `math` / `math_property` / `math_property_type` / `math_multiplier` / `math_group_type_index` / `math_hogql`, plus `name`. The engine reads aggregation from here. - On each inner node: `event` (or action `id`), `properties`, `name` — all respected normally; `properties` applies only to that node. Mirror the group's `math*` values on each inner node for UI round-trip, but they're ignored at execution time. ### Example — different filter per event "Pageviews on Safari OR pageleaves on Chrome, as one line." Each inner node carries its own `properties`; the group ORs them and aggregates as one series. ```json { "kind": "TrendsQuery", "series": [ { "kind": "GroupNode", "operator": "OR", "name": "Pageviews on Safari, Pageleaves on Chrome", "math": "total", "nodes": [ { "kind": "EventsNode", "event": "$pageview", "name": "Pageview", "math": "total", "properties": [{ "key": "$browser", "operator": "exact", "type": "event", "value": ["Safari"] }] }, { "kind": "EventsNode", "event": "$pageleave", "name": "Pageleave", "math": "total", "properties": [{ "key": "$browser", "operator": "exact", "type": "event", "value": ["Chrome"] }] } ] } ], "dateRange": { "date_from": "-30d" }, "interval": "day" } ``` ## Math formulas If the math aggregation is more complex or not listed above, use custom formulas to perform mathematical operations like calculating percentages or metrics. If you use a formula, you should use the following syntax: `A/B`, where `A` and `B` are the names of the series. You can combine math aggregations and formulas. When using a formula, you should: - Identify and specify **all** events and actions needed to solve the formula. - Carefully review the list of available events and actions to find appropriate entities for each part of the formula. - Ensure that you find events and actions corresponding to both the numerator and denominator in ratio calculations. Examples of using math formulas: - If you want to calculate the percentage of users who have completed onboarding, you need to find and use events or actions similar to `$identify` and `onboarding complete`, so the formula will be `A / B * 100`, where `A` is `onboarding complete` (unique users) and `B` is `$identify` (unique users). - To calculate conversion rate: `A / B * 100` where A is conversions and B is total events. - To calculate average value: `A / B` where A is sum of property and B is count. ## Time interval Specify the time interval (group by time) using the `interval` field. Available intervals are: `hour`, `day`, `week`, `month`. Unless the user has specified otherwise, use the following default interval: - If the time period is less than two days, use the `hour` interval. - If the time period is less than a month, use the `day` interval. - If the time period is less than three months, use the `week` interval. - Otherwise, use the `month` interval. ## Breakdowns Breakdowns are used to segment data by property values of maximum three properties. They divide all defined trends series into multiple subseries based on the values of the property. Include breakdowns **only when they are essential to directly answer the user's question**. You should not add breakdowns if the question can be addressed without additional segmentation. Always use the minimum set of breakdowns needed. When using breakdowns, you should: - **Identify the property group** and name for each breakdown. - **Provide the property name** for each breakdown. - **Validate that the property value accurately reflects the intended criteria**. Examples of using breakdowns: - page views trend by country: you need to find a property such as `$geoip_country_code` and set it as a breakdown. - number of users who have completed onboarding by an organization: you need to find a property such as `organization name` and set it as a breakdown. # Examples ## How many users signed up? ```json { "kind": "TrendsQuery", "series": [{ "kind": "EventsNode", "event": "user signed up", "math": "total" }], "dateRange": { "date_from": "-30d" }, "interval": "month", "trendsFilter": { "display": "BoldNumber" } } ``` ## Page views by referring domain for the last month ```json { "kind": "TrendsQuery", "series": [{ "kind": "EventsNode", "event": "$pageview", "math": "total" }], "dateRange": { "date_from": "-30d" }, "interval": "day", "breakdownFilter": { "breakdowns": [{ "property": "$referring_domain", "type": "event" }] } } ``` ## DAU to MAU ratio for users from the US, compared to the previous period ```json { "kind": "TrendsQuery", "series": [ { "kind": "EventsNode", "event": "$pageview", "math": "dau" }, { "kind": "EventsNode", "event": "$pageview", "math": "monthly_active" } ], "dateRange": { "date_from": "-7d" }, "interval": "day", "properties": { "type": "AND", "values": [ { "type": "AND", "values": [{ "key": "$geoip_country_name", "operator": "exact", "type": "event", "value": ["United States"] }] } ] }, "compareFilter": { "compare": true }, "trendsFilter": { "display": "ActionsLineGraph", "formula": "A/B", "aggregationAxisFormat": "percentage_scaled" } } ``` ## Unique users and first-time users for "insight created" over the last 12 months ```json { "kind": "TrendsQuery", "series": [ { "kind": "EventsNode", "event": "insight created", "math": "dau" }, { "kind": "EventsNode", "event": "insight created", "math": "first_time_for_user" } ], "dateRange": { "date_from": "-12m" }, "interval": "month", "filterTestAccounts": true, "trendsFilter": { "display": "ActionsLineGraph" } } ``` ## P99, P95, and median of a "refreshAge" property on "viewed dashboard" events ```json { "kind": "TrendsQuery", "series": [ { "kind": "EventsNode", "event": "viewed dashboard", "math": "p99", "math_property": "refreshAge" }, { "kind": "EventsNode", "event": "viewed dashboard", "math": "p95", "math_property": "refreshAge" }, { "kind": "EventsNode", "event": "viewed dashboard", "math": "median", "math_property": "refreshAge" } ], "dateRange": { "date_from": "yStart" }, "interval": "month", "filterTestAccounts": true, "trendsFilter": { "display": "ActionsLineGraph", "aggregationAxisFormat": "duration" } } ``` ## Organizations that signed up from Google in the last 30 days (group aggregation) ```json { "kind": "TrendsQuery", "series": [ { "kind": "EventsNode", "event": "user signed up", "math": "unique_group", "math_group_type_index": 0, "properties": [{ "key": "is_organization_first_user", "operator": "exact", "type": "person", "value": ["true"] }] } ], "dateRange": { "date_from": "-30d" }, "interval": "day", "properties": { "type": "AND", "values": [ { "type": "OR", "values": [{ "key": "$initial_utm_source", "operator": "exact", "type": "person", "value": ["google"] }] } ] }, "trendsFilter": { "display": "ActionsLineGraph" } } ``` # Reminders - Ensure that any properties included are directly relevant to the context and objectives of the user's question. Avoid unnecessary or unrelated details. - Avoid overcomplicating the response with excessive property filters. Focus on the simplest solution. - When using group aggregations (unique groups), always set `math_group_type_index` to the appropriate group type index from the group mapping. - Visualization settings (display type, axis format, etc.) should only be specified when explicitly requested or when they significantly improve the answer.

Query Funnel

Run a funnel query to analyze conversion rates through a sequence of steps. Funnel insights help understand user behavior as users navigate through a product. A funnel consists of a sequence of at least two events or actions, where some users progress to the next step while others drop off. Funnels use percentages as the primary aggregation type. Use 'read-data-schema' to discover available events, actions, and properties for filters and breakdowns. IMPORTANT: Funnels REQUIRE AT LEAST TWO series (events or actions). The funnel insights have the following features: - Various visualization types (steps, time-to-convert, historical trends). - Filter data and apply exclusion steps (events only, not actions). - Break down data using a single property. - Specify conversion windows (default 14 days), step order (strict/ordered/unordered), and attribution settings. - Aggregate by users, sessions, or specific group types. - Track first-time conversions with special math aggregations. Examples of use cases include: - Conversion rates between steps. - Drop off steps (which step loses most users). - Steps with the highest friction and time to convert. - If product changes are improving their funnel over time. - Average/median/histogram of time to convert. - Conversion trends over time (using trends visualization type). - First-time user conversions (using first_time_for_user math). CRITICAL: Be minimalist. Only include filters, breakdowns, and settings that are essential to answer the user's specific question. Default settings are usually sufficient unless the user explicitly requests customization. # Data narrowing ## Property filters Use property filters to narrow results. Only include property filters when they are essential to directly answer the user's question. Avoid adding them if the question can be addressed without additional segmentation and always use the minimum set of property filters needed. IMPORTANT: Do not check if a property is set unless the user explicitly asks for it. When using a property filter, you should: - **Prioritize properties directly related to the context or objective of the user's query.** Avoid using properties for identification like IDs. Instead, prioritize filtering based on general properties like `paidCustomer` or `icp_score`. - **Ensure that you find both the property group and name.** Property groups should be one of the following: event, person, session, group. - After selecting a property, **validate that the property value accurately reflects the intended criteria**. - **Find the suitable operator for type** (e.g., `contains`, `is set`). - If the operator requires a value, use the `read-data-schema` tool to find the property values. - You set logical operators to combine multiple properties of a single series: AND or OR. Infer the property groups from the user's request. If your first guess doesn't yield any results, try to adjust the property group. Supported operators for the String type are: - equals (exact) - doesn't equal (is_not) - contains (icontains) - doesn't contain (not_icontains) - matches regex (regex) - doesn't match regex (not_regex) - is set - is not set Supported operators for the Numeric type are: - equals (exact) - doesn't equal (is_not) - greater than (gt) - less than (lt) - is set - is not set Supported operators for the DateTime type are: - equals (is_date_exact) - doesn't equal (is_not for existence check) - before (is_date_before) - after (is_date_after) - is set - is not set Supported operators for the Boolean type are: - equals - doesn't equal - is set - is not set All operators take a single value except for `equals` and `doesn't equal` which can take one or more values (as an array). ## Time period You should not filter events by time using property filters. Instead, use the `dateRange` field. If the question doesn't mention time, use last 30 days as a default time period. # Funnel guidelines ## Exclusion steps Users may want to use exclusion events to filter out conversions in which a particular event occurred between specific steps. These events should not be included in the main sequence. You should include start and end indexes (0-based) for each exclusion where the minimum `funnelFromStep` is 0 (first step) and the maximum `funnelToStep` is the number of steps minus one. Exclusion events cannot be actions, only events. IMPORTANT: Exclusion steps filter out conversions where the exclusion event occurred BETWEEN the specified steps. This does NOT exclude users who completed the event before the funnel started or after it ended. For example, there is a sequence with three steps: sign up (step 0), finish onboarding (step 1), purchase (step 2). If the user wants to exclude all conversions in which users navigated away between sign up and finishing onboarding, the exclusion step will be `$pageleave` with `funnelFromStep: 0` and `funnelToStep: 1`. ## Breakdown A breakdown is used to segment data by a single property value. They divide all defined funnel series into multiple subseries based on the values of the property. Include a breakdown **only when it is essential to directly answer the user's question**. You should not add a breakdown if the question can be addressed without additional segmentation. When using breakdowns, you should: - **Identify the property group** and name for a breakdown. - **Provide the property name** for a breakdown. - **Validate that the property value accurately reflects the intended criteria**. Examples of using a breakdown: - page views to sign up funnel by country: you need to find a property such as `$geoip_country_code` and set it as a breakdown. - conversion rate of users who have completed onboarding after signing up by an organization: you need to find a property such as `organization name` and set it as a breakdown. ## Combining multiple events into a single step (`GroupNode`) **Use a `GroupNode`** when the user wants a single funnel step to match any of several events — e.g. "Pageview OR Pageleave counts as one step", or "the user signed up via any of these channels". Different filters per event are fine — put them on the inner nodes. Use separate steps instead when the user wants the events to occur in sequence. Only `OR` is supported. Funnel math (`first_time_for_user` etc.), `optionalInFunnel`, and step-wide property filters are not supported on a grouped step — filters must live on the inner nodes, and any math / optional handling must use a regular non-grouped step. **Where things live:** - On the group: only `name` (display label). - On each inner node: `event` (or action `id`), `properties`, `name` — all respected normally; per-node `properties` apply only to that node. ### Example — funnel with a grouped step A 3-step funnel where the middle step matches either `$pageview` on Safari or `$pageleave` on Chrome: ```json { "kind": "FunnelsQuery", "series": [ { "kind": "EventsNode", "event": "sign up" }, { "kind": "GroupNode", "operator": "OR", "name": "Pageview on Safari, Pageleave on Chrome", "nodes": [ { "kind": "EventsNode", "event": "$pageview", "name": "Pageview", "properties": [{ "key": "$browser", "operator": "exact", "type": "event", "value": ["Safari"] }] }, { "kind": "EventsNode", "event": "$pageleave", "name": "Pageleave", "properties": [{ "key": "$browser", "operator": "exact", "type": "event", "value": ["Chrome"] }] } ] }, { "kind": "EventsNode", "event": "purchase" } ], "dateRange": { "date_from": "-30d" } } ``` # Examples ## Conversion from first event ingested to insight saved for organizations over 6 months ```json { "kind": "FunnelsQuery", "series": [ { "kind": "EventsNode", "event": "first team event ingested" }, { "kind": "EventsNode", "event": "insight saved" } ], "dateRange": { "date_from": "-6m" }, "interval": "month", "aggregation_group_type_index": 0, "funnelsFilter": { "funnelOrderType": "ordered", "funnelVizType": "trends", "funnelWindowInterval": 14, "funnelWindowIntervalUnit": "day" }, "filterTestAccounts": true } ``` ## Signup page CTA click rate within one hour, excluding page leaves, broken down by OS ```json { "kind": "FunnelsQuery", "series": [ { "kind": "EventsNode", "event": "$pageview", "properties": [{ "key": "$current_url", "type": "event", "value": "signup", "operator": "icontains" }] }, { "kind": "EventsNode", "event": "click subscribe button", "properties": [{ "key": "$current_url", "type": "event", "value": "signup", "operator": "icontains" }] } ], "dateRange": { "date_from": "-180d" }, "interval": "week", "funnelsFilter": { "funnelWindowInterval": 1, "funnelWindowIntervalUnit": "hour", "funnelOrderType": "ordered", "exclusions": [{ "kind": "EventsNode", "event": "$pageleave", "funnelFromStep": 0, "funnelToStep": 1 }] }, "breakdownFilter": { "breakdown_type": "event", "breakdown": "$os" }, "filterTestAccounts": true } ``` ## Credit card purchase rate from viewing a product with strict ordering (no events in between) ```json { "kind": "FunnelsQuery", "series": [ { "kind": "EventsNode", "event": "view product" }, { "kind": "EventsNode", "event": "purchase", "properties": [{ "key": "paymentMethod", "type": "event", "value": "credit_card", "operator": "exact" }] } ], "dateRange": { "date_from": "-30d" }, "funnelsFilter": { "funnelOrderType": "strict", "funnelWindowInterval": 14, "funnelWindowIntervalUnit": "day" }, "filterTestAccounts": true } ``` ## View product to buy button to purchase, using actions and events ```json { "kind": "FunnelsQuery", "series": [ { "kind": "ActionsNode", "id": 8882, "name": "view product" }, { "kind": "EventsNode", "event": "click buy button" }, { "kind": "ActionsNode", "id": 573, "name": "purchase", "properties": [ { "key": "shipping_method", "value": "express_delivery", "operator": "icontains", "type": "event" } ] } ], "funnelsFilter": { "funnelVizType": "steps" }, "filterTestAccounts": true } ``` # Reminders - You MUST ALWAYS use AT LEAST TWO series (events or actions) in the funnel. - Ensure that any properties included are directly relevant to the context and objectives of the user's question. Avoid unnecessary or unrelated details. - Avoid overcomplicating the response with excessive property filters. Focus on the simplest solution. - The default funnel step order is `ordered` (events in sequence but with other events allowed in between). Use `strict` when events should happen consecutively with no events in between. Use `unordered` when order doesn't matter. - Exclusion events in funnels only exclude conversions where the event happened between the specified steps, not before or after the funnel.

Query Retention

Run a retention query to analyze how many users return over time after performing an initial action. Retention insights show you how many users return during subsequent periods. They're useful for understanding user engagement and stickiness. Use 'read-data-schema' to discover available events, actions, and properties for filters. Examples of use cases include: - Are new sign ups coming back to use your product after trying it? - Have recent changes improved retention? - How many users come back and perform an action after their first visit. - How many users come back to perform action X after performing action Y. - How often users return to use a specific feature. 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. # Data narrowing ## Property filters Use property filters to narrow results. Only include property filters when they are essential to directly answer the user's question. Avoid adding them if the question can be addressed without additional segmentation and always use the minimum set of property filters needed. IMPORTANT: Do not check if a property is set unless the user explicitly asks for it. When using a property filter, you should: - **Prioritize properties directly related to the context or objective of the user's query.** Avoid using properties for identification like IDs. Instead, prioritize filtering based on general properties like `paidCustomer` or `icp_score`. - **Ensure that you find both the property group and name.** Property groups should be one of the following: event, person, session, group. - After selecting a property, **validate that the property value accurately reflects the intended criteria**. - **Find the suitable operator for type** (e.g., `contains`, `is set`). - If the operator requires a value, use the `read-data-schema` tool to find the property values. - You set logical operators to combine multiple properties of a single series: AND or OR. Infer the property groups from the user's request. If your first guess doesn't yield any results, try to adjust the property group. Supported operators for the String type are: - equals (exact) - doesn't equal (is_not) - contains (icontains) - doesn't contain (not_icontains) - matches regex (regex) - doesn't match regex (not_regex) - is set - is not set Supported operators for the Numeric type are: - equals (exact) - doesn't equal (is_not) - greater than (gt) - less than (lt) - is set - is not set Supported operators for the DateTime type are: - equals (is_date_exact) - doesn't equal (is_not for existence check) - before (is_date_before) - after (is_date_after) - is set - is not set Supported operators for the Boolean type are: - equals - doesn't equal - is set - is not set All operators take a single value except for `equals` and `doesn't equal` which can take one or more values (as an array). ## Time period You should not filter events by time using property filters. Instead, use the `dateRange` field. If the question doesn't mention time, use last 30 days as a default time period. # Retention guidelines Retention insights always require two entities: - The activation event (targetEntity) – determines if the user is a part of a cohort (when they "start"). - The retention event (returningEntity) – determines whether a user has been retained (when they "return"). For activation and retention events, use the `$pageview` event by default or the equivalent for mobile apps `$screen`. Avoid infrequent or inconsistent events like `signed in` unless asked explicitly, as they skew the data. The activation and retention events can be the same (e.g., both `$pageview` to see if users who viewed pages come back to view pages again) or different (e.g., activation is `signed up` and retention is `completed purchase` to see if sign-ups convert to purchases over time). # Examples ## Weekly retention of users who created an insight ```json { "kind": "RetentionQuery", "retentionFilter": { "period": "Week", "totalIntervals": 9, "targetEntity": { "id": "insight created", "name": "insight created", "type": "events" }, "returningEntity": { "id": "insight created", "name": "insight created", "type": "events" }, "retentionType": "retention_first_time", "retentionReference": "total", "cumulative": false }, "filterTestAccounts": true } ``` ## Do users who sign up come back to view pages? ```json { "kind": "RetentionQuery", "retentionFilter": { "period": "Week", "totalIntervals": 8, "targetEntity": { "id": "user signed up", "name": "user signed up", "type": "events" }, "returningEntity": { "id": "$pageview", "name": "$pageview", "type": "events" }, "retentionType": "retention_first_time", "retentionReference": "total", "cumulative": false }, "dateRange": { "date_from": "-60d" }, "filterTestAccounts": true } ``` ## Daily retention of pageviews for mobile users only ```json { "kind": "RetentionQuery", "retentionFilter": { "period": "Day", "totalIntervals": 14, "targetEntity": { "id": "$pageview", "name": "$pageview", "type": "events" }, "returningEntity": { "id": "$pageview", "name": "$pageview", "type": "events" }, "retentionType": "retention_first_time", "retentionReference": "total", "cumulative": false }, "properties": [{ "key": "$os", "operator": "exact", "type": "event", "value": ["iOS", "Android"] }], "dateRange": { "date_from": "-30d" }, "filterTestAccounts": true } ``` # Reminders - Ensure that any properties included are directly relevant to the context and objectives of the user's question. Avoid unnecessary or unrelated details. - Avoid overcomplicating the response with excessive property filters. Focus on the simplest solution.

Query Stickiness

Run a stickiness query to measure how many intervals (e.g. days) within a date range users performed an event. Stickiness insights show user engagement intensity — the X-axis shows the number of intervals (1, 2, 3, ...) and the Y-axis shows how many users performed the event on exactly that many intervals. They're useful for understanding how deeply users engage with a feature. Use 'read-data-schema' to discover available events, actions, and properties for filters. Examples of use cases include: - How many days per week do users use a feature? - What percentage of users are power users (using the product every day)? - How engaged are users with a specific feature over the past month? - Compare stickiness of different features to find the most engaging one. - Has a product change improved user engagement frequency? 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. # Data narrowing ## Property filters Use property filters to narrow results. Only include property filters when they are essential to directly answer the user's question. Avoid adding them if the question can be addressed without additional segmentation and always use the minimum set of property filters needed. IMPORTANT: Do not check if a property is set unless the user explicitly asks for it. When using a property filter, you should: - **Prioritize properties directly related to the context or objective of the user's query.** Avoid using properties for identification like IDs. Instead, prioritize filtering based on general properties like `paidCustomer` or `icp_score`. - **Ensure that you find both the property group and name.** Property groups should be one of the following: event, person, session, group. - After selecting a property, **validate that the property value accurately reflects the intended criteria**. - **Find the suitable operator for type** (e.g., `contains`, `is set`). - If the operator requires a value, use the `read-data-schema` tool to find the property values. - You set logical operators to combine multiple properties of a single series: AND or OR. Infer the property groups from the user's request. If your first guess doesn't yield any results, try to adjust the property group. Supported operators for the String type are: - equals (exact) - doesn't equal (is_not) - contains (icontains) - doesn't contain (not_icontains) - matches regex (regex) - doesn't match regex (not_regex) - is set - is not set Supported operators for the Numeric type are: - equals (exact) - doesn't equal (is_not) - greater than (gt) - less than (lt) - is set - is not set Supported operators for the DateTime type are: - equals (is_date_exact) - doesn't equal (is_not for existence check) - before (is_date_before) - after (is_date_after) - is set - is not set Supported operators for the Boolean type are: - equals - doesn't equal - is set - is not set All operators take a single value except for `equals` and `doesn't equal` which can take one or more values (as an array). ## Time period You should not filter events by time using property filters. Instead, use the `dateRange` field. If the question doesn't mention time, use last 30 days as a default time period. # Stickiness guidelines Stickiness insights measure engagement intensity — how many intervals (days, weeks, etc.) within a date range each user performed an event. Unlike trends which show event counts over time, stickiness shows the distribution of user engagement frequency. Key concepts: - The `interval` field determines what counts as one period. With `day` interval over a 30-day range, the chart shows how many users performed the event on 1 day, 2 days, 3 days, etc., up to 30 days. - When `math` is omitted on a series, stickiness counts unique persons by default. - Multiple series can be included to compare stickiness of different events side by side. - Stickiness does NOT support breakdowns. ## Aggregation The default aggregation for stickiness is unique persons. You can change how users are identified using the `math` field on each series: - `dau` or omit math — count unique persons (default behavior; both resolve to person_id aggregation) - `unique_group` — count unique groups (requires `math_group_type_index` to be set to the group type index from the group mapping) - `hogql` — custom HogQL expression (requires `math_hogql` to be set to a valid HogQL aggregation expression, e.g. `count(distinct properties.$session_id)`) ## Stickiness criteria Use `stickinessFilter.stickinessCriteria` to filter which intervals count based on event frequency within each interval. This applies a HAVING clause to the inner aggregation. - `operator` — one of `gte` (greater than or equal), `lte` (less than or equal), `exact` (exactly equal) - `value` — the threshold count For example, to only count intervals where the user performed the event at least 3 times, set `stickinessCriteria: { "operator": "gte", "value": 3 }`. ## Cumulative mode Use `stickinessFilter.computedAs` to change how stickiness is computed: - `non_cumulative` (default) — each bar shows users active on **exactly** N intervals - `cumulative` — each bar shows users active on **N or more** intervals ## Time interval Specify the time interval using the `interval` field. Available intervals are: `hour`, `day`, `week`, `month`. Unless the user has specified otherwise, use `day` as the default interval. Use `intervalCount` to group multiple base intervals into a single period. For example, `interval: "day"` with `intervalCount: 7` groups by 7-day periods. Defaults to 1. ## Compare Use `compareFilter` with `compare: true` to show the current and previous period side by side. # Examples ## How many days per week do users use pageview? ```json { "kind": "StickinessQuery", "series": [{ "kind": "EventsNode", "event": "$pageview" }], "dateRange": { "date_from": "-30d" }, "interval": "day", "filterTestAccounts": true } ``` ## Compare stickiness of two features ```json { "kind": "StickinessQuery", "series": [ { "kind": "EventsNode", "event": "insight created" }, { "kind": "EventsNode", "event": "dashboard viewed" } ], "dateRange": { "date_from": "-30d" }, "interval": "day", "filterTestAccounts": true } ``` ## Weekly stickiness for paid users, compared to previous period ```json { "kind": "StickinessQuery", "series": [{ "kind": "EventsNode", "event": "$pageview" }], "dateRange": { "date_from": "-90d" }, "interval": "week", "properties": [{ "key": "paidCustomer", "operator": "exact", "type": "person", "value": ["true"] }], "compareFilter": { "compare": true }, "filterTestAccounts": true } ``` ## Stickiness with criteria: only count days with 3+ events ```json { "kind": "StickinessQuery", "series": [{ "kind": "EventsNode", "event": "$pageview" }], "dateRange": { "date_from": "-30d" }, "interval": "day", "filterTestAccounts": true, "stickinessFilter": { "stickinessCriteria": { "operator": "gte", "value": 3 } } } ``` ## Cumulative stickiness: users active on N or more days ```json { "kind": "StickinessQuery", "series": [{ "kind": "EventsNode", "event": "feature used" }], "dateRange": { "date_from": "-30d" }, "interval": "day", "filterTestAccounts": true, "stickinessFilter": { "computedAs": "cumulative" } } ``` ## Organization-level stickiness for a feature ```json { "kind": "StickinessQuery", "series": [ { "kind": "EventsNode", "event": "feature used", "math": "unique_group", "math_group_type_index": 0 } ], "dateRange": { "date_from": "-30d" }, "interval": "day", "filterTestAccounts": true, "stickinessFilter": { "display": "ActionsBar" } } ``` # Reminders - Ensure that any properties included are directly relevant to the context and objectives of the user's question. Avoid unnecessary or unrelated details. - Avoid overcomplicating the response with excessive property filters. Focus on the simplest solution. - Stickiness does NOT support breakdowns — do not include a `breakdownFilter`. - When using group aggregations (unique groups), always set `math_group_type_index` to the appropriate group type index from the group mapping. - The default interval is `day` and the default math is unique persons — omit these unless the user asks for something different.

Query Paths

Run a paths query to analyze the most common sequences of events or pages that users navigate through. Paths insights visualize user flows as a directed graph, showing how users move between steps and where they drop off. Use 'read-data-schema' to discover available events, actions, and properties for filters. Examples of use cases include: - What do users do after signing up? - What pages do users visit before making a purchase? - What are the most common navigation flows on your website? - Where do users drop off in a particular flow? - What custom events lead to a conversion? 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. # Data narrowing ## Property filters Use property filters to narrow results. Only include property filters when they are essential to directly answer the user's question. Avoid adding them if the question can be addressed without additional segmentation and always use the minimum set of property filters needed. IMPORTANT: Do not check if a property is set unless the user explicitly asks for it. When using a property filter, you should: - **Prioritize properties directly related to the context or objective of the user's query.** Avoid using properties for identification like IDs. Instead, prioritize filtering based on general properties like `paidCustomer` or `icp_score`. - **Ensure that you find both the property group and name.** Property groups should be one of the following: event, person, session, group. - After selecting a property, **validate that the property value accurately reflects the intended criteria**. - **Find the suitable operator for type** (e.g., `contains`, `is set`). - If the operator requires a value, use the `read-data-schema` tool to find the property values. - You set logical operators to combine multiple properties of a single series: AND or OR. Infer the property groups from the user's request. If your first guess doesn't yield any results, try to adjust the property group. Supported operators for the String type are: - equals (exact) - doesn't equal (is_not) - contains (icontains) - doesn't contain (not_icontains) - matches regex (regex) - doesn't match regex (not_regex) - is set - is not set Supported operators for the Numeric type are: - equals (exact) - doesn't equal (is_not) - greater than (gt) - less than (lt) - is set - is not set Supported operators for the DateTime type are: - equals (is_date_exact) - doesn't equal (is_not for existence check) - before (is_date_before) - after (is_date_after) - is set - is not set Supported operators for the Boolean type are: - equals - doesn't equal - is set - is not set All operators take a single value except for `equals` and `doesn't equal` which can take one or more values (as an array). ## Time period You should not filter events by time using property filters. Instead, use the `dateRange` field. If the question doesn't mention time, use last 30 days as a default time period. # Paths guidelines ## Event types Paths analyze sequences of events. Specify which event types to include using `includeEventTypes`. If omitted, all events are included without type filtering. - `$pageview` - web page views. Path values come from `$current_url`, with trailing slashes stripped, so they must match your stored URL format. This is often a path like `/login`, but may also be a full URL like `https://example.com/login`. Best for analyzing website navigation flows. This is the most common choice. - `$screen` - mobile screen views. Path values are screen names (from `$screen_name`). Use for mobile app navigation analysis. - `custom_event` - custom events (any event whose name does not start with `$`). Path values are event names. Use for analyzing flows of custom-tracked events like button clicks, form submissions, or feature usage. - `hogql` - custom HogQL expression. Use with `pathsHogQLExpression` for advanced path definitions. You can combine multiple types. For example, include both `$pageview` and `custom_event` to see how page views and custom events interleave. ## Start and end points Use `startPoint` to filter paths that begin at a specific step, or `endPoint` to filter paths that end at a specific step. The value format depends on the event type: - For `$pageview`: use the same URL format as your `$current_url` values, often paths like `/login`, `/dashboard`, `/settings`, but sometimes full URLs - For `$screen`: use screen names - For `custom_event`: use event names like `user signed up`, `purchase completed` ## Path cleaning Use `localPathCleaningFilters` to normalize dynamic URLs. Each filter has a `regex` pattern (ClickHouse regex syntax) and an `alias` replacement. Filters are applied in sequence using `replaceRegexpAll(path, regex, alias)`. For example, to normalize product URLs: `{ "regex": "\\/product\\/\\d+", "alias": "/product/:id" }`. Use `pathGroupings` for simpler glob-like grouping of paths into single nodes. Use `*` as a wildcard — the patterns are auto-escaped so only `*` has special meaning. For example, `/product/*` groups all product sub-pages into one node. ## Exclusions Use `excludeEvents` to remove specific path items that clutter the visualization. The values must match path item values, not event types: for `$pageview` paths these must match your stored `$current_url` format (e.g., `/health-check` or `https://example.com/health-check`), for `custom_event` paths these are event names (e.g., `heartbeat`). To control which event types are included, use `includeEventTypes` instead. # Examples ## What pages do users visit after the homepage? ```json { "kind": "PathsQuery", "pathsFilter": { "includeEventTypes": ["$pageview"], "startPoint": "/", "stepLimit": 5 }, "dateRange": { "date_from": "-30d" }, "filterTestAccounts": true } ``` ## What do users do after signing up? ```json { "kind": "PathsQuery", "pathsFilter": { "includeEventTypes": ["custom_event"], "startPoint": "user signed up", "stepLimit": 5 }, "dateRange": { "date_from": "-30d" }, "filterTestAccounts": true } ``` ## Navigation paths excluding noisy URLs ```json { "kind": "PathsQuery", "pathsFilter": { "includeEventTypes": ["$pageview"], "excludeEvents": ["/health-check", "/ping"], "stepLimit": 5, "edgeLimit": 30 }, "dateRange": { "date_from": "-14d" }, "filterTestAccounts": true } ``` ## Custom event paths excluding noisy events ```json { "kind": "PathsQuery", "pathsFilter": { "includeEventTypes": ["custom_event"], "excludeEvents": ["heartbeat"], "stepLimit": 5 }, "dateRange": { "date_from": "-14d" }, "filterTestAccounts": true } ``` ## Paths with URL cleaning for dynamic segments ```json { "kind": "PathsQuery", "pathsFilter": { "includeEventTypes": ["$pageview"], "stepLimit": 5, "localPathCleaningFilters": [ { "regex": "\\/user\\/\\d+", "alias": "/user/:id" }, { "regex": "\\/project\\/[a-f0-9-]+", "alias": "/project/:id" } ] }, "dateRange": { "date_from": "-30d" }, "filterTestAccounts": true } ``` ## What paths lead to the pricing page for mobile users? ```json { "kind": "PathsQuery", "pathsFilter": { "includeEventTypes": ["$pageview"], "endPoint": "/pricing", "stepLimit": 5 }, "properties": [{ "key": "$os", "operator": "exact", "type": "event", "value": ["iOS", "Android"] }], "dateRange": { "date_from": "-30d" }, "filterTestAccounts": true } ``` # Reminders - Ensure that any properties included are directly relevant to the context and objectives of the user's question. Avoid unnecessary or unrelated details. - Avoid overcomplicating the response with excessive property filters. Focus on the simplest solution. - Always specify `includeEventTypes` to scope the analysis to relevant event types. If omitted, all events are included which may produce noisy results. - Use `$pageview` as the default event type for web navigation questions. - Path cleaning filters (`localPathCleaningFilters`) use ClickHouse regex and are only needed when dynamic URL segments would fragment the visualization. Path groupings (`pathGroupings`) use glob-like patterns with `*` wildcards for simpler cases. - Paths group events into sessions with a 30-minute inactivity threshold — events more than 30 minutes apart start a new path session.

Query Lifecycle

Run a lifecycle query to categorize users into lifecycle stages based on their activity pattern relative to a single event or action. Lifecycle insights break users into four mutually exclusive groups for each time period: new, returning, resurrecting, and dormant. They're useful for understanding the composition of your active users and diagnosing growth or churn patterns. Use 'read-data-schema' to discover available events, actions, and properties for filters. Examples of use cases include: - What is the composition of my active users over time? - Are we gaining new users faster than we're losing dormant ones? - How many users resurrected (came back after being inactive) last week? - Is the returning user base growing or shrinking? - How does user engagement change after a product launch? 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. # Data narrowing ## Property filters Use property filters to narrow results. Only include property filters when they are essential to directly answer the user's question. Avoid adding them if the question can be addressed without additional segmentation and always use the minimum set of property filters needed. IMPORTANT: Do not check if a property is set unless the user explicitly asks for it. When using a property filter, you should: - **Prioritize properties directly related to the context or objective of the user's query.** Avoid using properties for identification like IDs. Instead, prioritize filtering based on general properties like `paidCustomer` or `icp_score`. - **Ensure that you find both the property group and name.** Property groups should be one of the following: event, person, session, group. - After selecting a property, **validate that the property value accurately reflects the intended criteria**. - **Find the suitable operator for type** (e.g., `contains`, `is set`). - If the operator requires a value, use the `read-data-schema` tool to find the property values. - You set logical operators to combine multiple properties of a single series: AND or OR. Infer the property groups from the user's request. If your first guess doesn't yield any results, try to adjust the property group. Supported operators for the String type are: - equals (exact) - doesn't equal (is_not) - contains (icontains) - doesn't contain (not_icontains) - matches regex (regex) - doesn't match regex (not_regex) - is set - is not set Supported operators for the Numeric type are: - equals (exact) - doesn't equal (is_not) - greater than (gt) - less than (lt) - is set - is not set Supported operators for the DateTime type are: - equals (is_date_exact) - doesn't equal (is_not for existence check) - before (is_date_before) - after (is_date_after) - is set - is not set Supported operators for the Boolean type are: - equals - doesn't equal - is set - is not set All operators take a single value except for `equals` and `doesn't equal` which can take one or more values (as an array). ## Time period You should not filter events by time using property filters. Instead, use the `dateRange` field. If the question doesn't mention time, use last 30 days as a default time period. # Lifecycle guidelines Lifecycle insights analyze a **single event or action** over time. The `series` array must contain exactly one item. If the user mentions multiple events, pick the most relevant one or clarify. ## Lifecycle statuses Each user is categorized into one of four statuses for each time period: - **New** – the user performed the event for the first time ever during this period. - **Returning** – the user was active in the previous period and is active again in the current period. - **Resurrecting** – the user was inactive for one or more periods and became active again. - **Dormant** – the user was active in the previous period but did not perform the event in the current period. Dormant counts are shown as negative values. ## Time interval Specify the time interval using the `interval` field. Available intervals are: `hour`, `day`, `week`, `month`. The default is `day`. Unless the user has specified otherwise, use the following default interval: - If the time period is less than two days, use the `hour` interval. - If the time period is less than a month, use the `day` interval. - If the time period is less than three months, use the `week` interval. - Otherwise, use the `month` interval. ## Toggled lifecycles Use `toggledLifecycles` in `lifecycleFilter` to control which lifecycle statuses are displayed. By default, all four statuses are shown. Only set this when the user wants to focus on specific statuses (e.g., only new and dormant users). ## Math aggregation Lifecycle insights do **not** support math aggregation types. Do not set `math` on the series node. # Examples ## Daily lifecycle of pageviews over the last 30 days ```json { "kind": "LifecycleQuery", "series": [{ "kind": "EventsNode", "event": "$pageview" }], "dateRange": { "date_from": "-30d" }, "interval": "day" } ``` ## Weekly lifecycle of sign ups, excluding test accounts ```json { "kind": "LifecycleQuery", "series": [{ "kind": "EventsNode", "event": "user signed up" }], "dateRange": { "date_from": "-90d" }, "interval": "week", "filterTestAccounts": true } ``` ## Monthly lifecycle of "insight created" showing only new and dormant users ```json { "kind": "LifecycleQuery", "series": [{ "kind": "EventsNode", "event": "insight created" }], "dateRange": { "date_from": "-12m" }, "interval": "month", "lifecycleFilter": { "toggledLifecycles": ["new", "dormant"] }, "filterTestAccounts": true } ``` ## Lifecycle of purchases by mobile users ```json { "kind": "LifecycleQuery", "series": [{ "kind": "EventsNode", "event": "purchase completed" }], "dateRange": { "date_from": "-30d" }, "interval": "day", "properties": [{ "key": "$os", "operator": "exact", "type": "event", "value": ["iOS", "Android"] }] } ``` # Reminders - Lifecycle insights support only **one** series — do not add multiple events or actions. - Do not set `math` on the series node — lifecycle does not support math aggregation. - Ensure that any properties included are directly relevant to the context and objectives of the user's question. Avoid unnecessary or unrelated details. - Avoid overcomplicating the response with excessive property filters. Focus on the simplest solution.

Query Llm Traces List

List LLM traces to inspect AI/LLM usage across your application. Returns traces with their events, latency, token usage, costs, errors, and other metadata. Use this tool for AI observability — debugging slow generations, investigating errors, analyzing token spend, and auditing LLM behavior. Use 'read-data-schema' to discover available event properties for filtering (e.g. `$ai_model`, `$ai_provider`). Examples of use cases include: - How much are we spending on LLM tokens per day? - Which LLM generations are the slowest? - Are there any traces with errors in the last 24 hours? - What models are being used and how do their costs compare? - Show me traces for a specific user to debug their experience. - Are there any traces with unusually high token usage? 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. # Data narrowing ## Property filters Use property filters to narrow results. Only include property filters when they are essential to directly answer the user's question. Avoid adding them if the question can be addressed without additional segmentation and always use the minimum set of property filters needed. IMPORTANT: Do not check if a property is set unless the user explicitly asks for it. When using a property filter, you should: - **Prioritize properties directly related to the context or objective of the user's query.** Common AI properties include `$ai_model`, `$ai_provider`, `$ai_trace_id`, `$ai_session_id`, `$ai_latency`, `$ai_input_tokens`, `$ai_output_tokens`, `$ai_total_cost_usd`, `$ai_is_error`, `$ai_http_status`, `$ai_span_name`. - **Note:** `$ai_is_error` and `$ai_error` are valid filter properties but may not appear via `read-data-schema`. Use `$ai_is_error` with operator `exact` and value `["true"]` to find error traces, or use `$ai_error` with `is set` to find traces with error messages. - **Ensure that you find both the property group and name.** Property groups should be one of the following: event, person, session, group. - After selecting a property, **validate that the property value accurately reflects the intended criteria**. - **Find the suitable operator for type** (e.g., `contains`, `is set`). - If the operator requires a value, use the `read-data-schema` tool to find the property values. Infer the property groups from the user's request. If your first guess doesn't yield any results, try to adjust the property group. Supported operators for the String type are: - equals (exact) - doesn't equal (is_not) - contains (icontains) - doesn't contain (not_icontains) - matches regex (regex) - doesn't match regex (not_regex) - is set - is not set Supported operators for the Numeric type are: - equals (exact) - doesn't equal (is_not) - greater than (gt) - less than (lt) - is set - is not set Supported operators for the DateTime type are: - equals (is_date_exact) - doesn't equal (is_not for existence check) - before (is_date_before) - after (is_date_after) - is set - is not set Supported operators for the Boolean type are: - equals - doesn't equal - is set - is not set All operators take a single value except for `equals` and `doesn't equal` which can take one or more values (as an array). ## Time period You should not filter events by time using property filters. Instead, use the `dateRange` field. If the question doesn't mention time, use last 7 days as a default time period. # Traces guidelines This is a listing tool, not a visualization/insight tool. It returns a paginated list of LLM traces — it does NOT support series, breakdowns, math aggregations, or chart types. ## Response shape Each trace in the results contains: - `id` — unique trace ID - `traceName` — name of the trace (if set via SDK) - `createdAt` — timestamp of the first event in the trace - `distinctId` — the person's distinct ID - `aiSessionId` — session ID grouping related traces (e.g., a conversation) - `totalLatency` — total latency in seconds - `inputTokens` / `outputTokens` — token counts across all generations in the trace - `inputCost` / `outputCost` / `totalCost` — costs in USD - `inputState` / `outputState` — JSON input/output state of the trace (e.g., conversation messages), from the `$ai_trace` event - `errorCount` — number of errors in the trace - `isSupportTrace` — whether the trace was from a support impersonation session - `tools` — list of tool names called during the trace - `events` — list of direct child events (generations, metrics, feedback). Each event's `properties` contains the full event data — see "Event types and their properties" below. ## Event types and their properties Each event in `events` has an `event` field indicating its type. The key properties vary by type: - **`$ai_generation`** / **`$ai_embedding`** — an LLM or embedding API call. Properties include `$ai_input` (input prompt JSON), `$ai_output_choices` (output message JSON), `$ai_model`, `$ai_provider`, `$ai_latency`, `$ai_input_tokens`, `$ai_output_tokens`, `$ai_input_cost_usd`, `$ai_output_cost_usd`, `$ai_total_cost_usd`, `$ai_tools_called`, `$ai_is_error`, `$ai_error`. - **`$ai_span`** — a unit of work within a trace (e.g., a retrieval step, a tool execution). Properties include `$ai_input_state`, `$ai_output_state`, `$ai_latency`, `$ai_span_name`, `$ai_parent_id`. - **`$ai_trace`** — the root trace event. Properties include `$ai_input_state` (e.g., conversation messages sent), `$ai_output_state` (e.g., final response), `$ai_span_name`. - **`$ai_metric`** — a named evaluation metric. Properties include `$ai_metric_name`, `$ai_metric_value`. - **`$ai_feedback`** — user-provided feedback. Properties include `$ai_feedback_text`. All event types share `$ai_trace_id`, `$ai_span_id`, and `$ai_parent_id` for tree structure (see below). ## Tree structure (IDs and parent-child relationships) Events in a trace form a tree. Each event carries three IDs that define its position: - `$ai_trace_id` — present on every event, identifies which trace it belongs to (same as the trace's `id`) - `$ai_span_id` (or `$ai_generation_id` for generations) — the event's own unique identifier - `$ai_parent_id` — points to the parent event's `$ai_span_id` To reconstruct the tree: 1. Events where `$ai_parent_id` equals `$ai_trace_id` are **root-level children** of the trace 2. Other events are children of the event whose `$ai_span_id` matches their `$ai_parent_id` 3. Group events by `$ai_parent_id` and walk from root children downward Generations (`$ai_generation`) and embeddings (`$ai_embedding`) are always leaf nodes. Spans (`$ai_span`) can have children. **Important:** This list tool only returns **direct children** of the trace (events where `$ai_parent_id` = trace ID) plus all `$ai_metric` and `$ai_feedback` events — NOT deeply nested events. For the full event tree with all nested children, use `query-llm-trace` with the trace's `id`. ## Pagination Use `limit` and `offset` for pagination. The default limit is 100. The response includes a `hasMore` field indicating whether more results are available. ## Filtering - `filterTestAccounts` — exclude internal/test users - `filterSupportTraces` — exclude support impersonation traces - `personId` — filter by a specific person UUID - `groupKey` + `groupTypeIndex` — filter by a specific group - `randomOrder` — use random ordering instead of newest-first (useful for representative sampling) # Examples ## Recent traces with errors ```json { "kind": "TracesQuery", "dateRange": { "date_from": "-7d" }, "filterTestAccounts": true, "properties": [{ "key": "$ai_is_error", "operator": "exact", "type": "event", "value": ["true"] }], "limit": 50 } ``` ## Traces for a specific model ```json { "kind": "TracesQuery", "dateRange": { "date_from": "-7d" }, "filterTestAccounts": true, "properties": [{ "key": "$ai_model", "operator": "exact", "type": "event", "value": ["gpt-4o"] }] } ``` ## Traces for a specific person ```json { "kind": "TracesQuery", "dateRange": { "date_from": "-30d" }, "personId": "01234567-89ab-cdef-0123-456789abcdef", "filterTestAccounts": true } ``` ## Random sample of traces (avoids recency bias) ```json { "kind": "TracesQuery", "dateRange": { "date_from": "-30d" }, "filterTestAccounts": true, "randomOrder": true, "limit": 20 } ``` # Reminders - Ensure that any properties included are directly relevant to the context and objectives of the user's question. Avoid unnecessary or unrelated details. - Avoid overcomplicating the response with excessive property filters. Focus on the simplest solution. - This tool returns raw trace data — it does not aggregate or visualize. For aggregated LLM metrics over time (e.g. total token usage per day), use `query-trends` with AI events like `$ai_generation` instead. - Use `filterTestAccounts: true` by default to exclude internal users unless the user asks otherwise. - The default time range is last 7 days. LLM trace data tends to be recent, so shorter ranges are usually appropriate. - For deep inspection of a single trace (full event tree with all nested children and complete properties), use `query-llm-trace` with the trace's `id`.

Query Llm Trace

Fetch a single LLM trace by its trace ID for deep inspection. Returns the complete trace with all nested events and their full properties — including inputs, outputs, model parameters, costs, and errors. Use after finding a trace via `query-llm-traces-list` to inspect the complete event tree. Use cases: - Inspect the full input/output of each generation in a trace - Debug a specific error trace found in the list - Examine the agent's decision-making flow across spans - Review tool calls and their results within a trace - Analyze token usage and costs per generation CRITICAL: This tool requires a `traceId`. Get the trace ID from `query-llm-traces-list` results first. # Response shape The response contains a single trace in JSON format with: - `id` — the trace ID - `traceName` — name of the trace (if set via SDK) - `createdAt` — timestamp of the first event in the trace - `distinctId` — the person's distinct ID - `aiSessionId` — session ID grouping related traces (e.g., a conversation) - `totalLatency` — total latency in seconds - `inputTokens` / `outputTokens` — token counts across all generations - `inputCost` / `outputCost` / `totalCost` — costs in USD - `inputState` / `outputState` — JSON input/output state from the root `$ai_trace` event (e.g., conversation messages) - `events` — **all** child events in the trace at every nesting depth (not just direct children). Each event has full `properties`. Unlike `query-llm-traces-list`, this tool does NOT return `errorCount`, `isSupportTrace`, or `tools` — those are summary fields on the list tool only. # Event types and their properties Each event in `events` has an `event` field indicating its type. Key properties vary by type: - **`$ai_generation`** / **`$ai_embedding`** — an LLM or embedding API call. Properties include `$ai_input` (input prompt JSON), `$ai_output_choices` (output message JSON), `$ai_model`, `$ai_provider`, `$ai_latency`, `$ai_input_tokens`, `$ai_output_tokens`, `$ai_input_cost_usd`, `$ai_output_cost_usd`, `$ai_total_cost_usd`, `$ai_tools_called`, `$ai_is_error`, `$ai_error`. - **`$ai_span`** — a unit of work within a trace (e.g., a retrieval step, tool execution). Properties include `$ai_input_state`, `$ai_output_state`, `$ai_latency`, `$ai_span_name`, `$ai_parent_id`. - **`$ai_metric`** — a named evaluation metric. Properties include `$ai_metric_name`, `$ai_metric_value`. - **`$ai_feedback`** — user-provided feedback. Properties include `$ai_feedback_text`. Note: `$ai_trace` events are NOT included in the `events` array — their data is surfaced via the trace-level `inputState`, `outputState`, and `traceName` fields. # Tree structure (IDs and parent-child relationships) Events in a trace form a tree. Each event carries three IDs that define its position: - `$ai_trace_id` — present on every event, identifies which trace it belongs to (same as the trace's `id`) - `$ai_span_id` (or `$ai_generation_id` for generations) — the event's own unique identifier - `$ai_parent_id` — points to the parent event's `$ai_span_id` To reconstruct the tree: 1. Events where `$ai_parent_id` equals `$ai_trace_id` are **root-level children** of the trace 2. Other events are children of the event whose `$ai_span_id` matches their `$ai_parent_id` 3. Group events by `$ai_parent_id` and walk from root children downward Generations (`$ai_generation`) and embeddings (`$ai_embedding`) are always leaf nodes. Spans (`$ai_span`) can have children. # Examples ## Fetch a trace by ID ```json { "kind": "TraceQuery", "traceId": "c9222e05-8708-41b8-98ea-d4a21849e761" } ``` ## Fetch with a date range hint If the trace is old, provide a date range to help the query find it efficiently: ```json { "kind": "TraceQuery", "traceId": "c9222e05-8708-41b8-98ea-d4a21849e761", "dateRange": { "date_from": "-30d" } } ``` # Reminders - Always get the `traceId` from `query-llm-traces-list` results — do not guess or fabricate trace IDs. - If no date range is provided, the default lookback window is used. For older traces, provide an explicit `dateRange`. - The `events` array contains ALL events in the trace (including deeply nested ones), making this suitable for full tree reconstruction. - Use `query-llm-traces-list` first to find traces, then this tool to inspect a specific one.

Query Trends Actors

List the persons behind a specific data point in a trends insight. Use this to answer "who were the users that did X on day Y?" or "which users are in this breakdown bucket?". Pair this with `query-trends`: first run the trends query to identify the data point of interest, then call this tool with the same trends query as `source` plus selectors that narrow to one cell. Selectors: - `day` **(required)**: a single bucket date as an ISO date string (YYYY-MM-DD), e.g. `"2024-01-15"`. Must match exactly one data point from the trends result. - `series`: 0-based index of the series to drill into when the trends query has multiple series. Defaults to 0. - `breakdown`: always an array, one value per `breakdownFilter.breakdowns` dimension, in the same order. Single dimension: `breakdown: ["Opera"]`. Multiple dimensions: `breakdown: ["Opera", "en-US"]`. - `compare`: `current` (default) or `previous` when the source has `compareFilter` enabled. - `includeRecordings`: defaults to `true`. Set to `false` to skip fetching matched session recordings (faster if recordings are not needed). Response: Each returned row contains `distinct_id`, `name`, `email`, and `event_count` (number of matching events for that actor). When `includeRecordings` is `true` (the default), a `recordings` column is also returned containing PostHog replay URLs that can be opened in a browser to watch the user's session. Results are limited to the top 100 actors ordered by event count. Guidance: - Keep the `source` trends query minimal - only include the filters/breakdowns needed to identify the cell. - Always pick a specific `day` from the trends result. - For large result sets, tighten the trends query (filters, date range) rather than expecting more rows.

Query Lifecycle Actors

List the persons in a specific bucket of a lifecycle insight. Use this to answer "who are the new / returning / resurrecting / dormant users on day Y?". `source` is the lifecycle query that defines the population (event, date range, filters). Build it directly when the user's request already names a bucket-day, or reuse one you previously ran via `query-lifecycle` when drilling in from a chart. Selectors: - `day` **(required)**: the bucket date as an ISO date string (YYYY-MM-DD), e.g. `"2024-01-15"`. Must align with the source's interval (a day boundary for `interval=day`, the start of the week for `interval=week`, etc.). - `status` **(required)**: which lifecycle bucket to drill into. One of `new`, `returning`, `resurrecting`, `dormant`. - `new` — users performing the event for the first time during the period. - `returning` — users active in the previous period and active in this one. - `resurrecting` — users inactive for one or more periods and active again now. - `dormant` — users active in the previous period but inactive now. Response: Each returned row contains `distinct_id`, `email`, and `name`. Results are limited to the top 100 actors. Matched session recordings are not returned — the lifecycle runner does not project per-actor matching events. Guidance: - Lifecycle insights only support a single series and do not expose `compareFilter`, so there is no `series` or `compare` selector here. - Keep the `source` lifecycle query minimal — only include the filters needed to define the same lifecycle population the user is asking about. - For large buckets, tighten the source query (filters, date range) rather than expecting more rows.

Session Recording Delete

Delete a session recording by ID. This permanently removes the recording data. Use for privacy or compliance workflows.

Session Recording Get

Get a specific session recording by ID. Returns full recording metadata including duration, interaction counts, console log counts, person info, and viewing status. Session recordings are reachable from events, errors, and persons via the `$session_id` property on events. Any `$session_id` value from an event can be passed as the `id` parameter to this tool. Note: a `$session_id` on an event does not guarantee a recording exists — session replay may not be enabled for that project or session. A 404 means no recording was captured. If the user wants to understand what happened without watching the recording, offer to use `session-recording-summarize` (note: very slow, ~5 minutes on average). If a recording is missing (404) or the user asks why recordings aren't being captured, diagnose with `execute-sql`: query `$recording_status`, `$session_recording_start_reason`, `$replay_sample_rate`, and `$sdk_debug_recording_script_not_loaded` from the events table (filter by `$session_id` for a specific session, or sample recent events for project-wide issues).

Session Recording Playlist Create

Create a new session recording playlist. Set type to 'collection' for a manually curated list or 'filters' for a saved filter view. Collections cannot have filters, and filter playlists must include at least one filter criterion.

Session Recording Playlist Get

Get a specific session recording playlist by short_id. Returns full playlist metadata including name, description, filters, type, and recording counts.

Session Recording Playlist Update

Update an existing session recording playlist by short_id. Can update name, description, pinned status, and filters. Set deleted to true to soft-delete. The type field cannot be changed after creation. When updating a filters-type playlist, you must include the existing filters alongside other field changes, otherwise the update will fail.

Session Recording Playlists List

List session recording playlists in the project. Returns both user-created and synthetic (system-generated) playlists with their metadata and recording counts.

Query Session Recordings List

List session recordings in the project. Returns recording metadata including duration, activity counts, console errors, start URL, and interaction metrics. Use this tool to find, filter, and explore session recordings. Use 'read-data-schema' to discover available person, session, and event properties for filtering. Examples of use cases include: - Find recordings with console errors in the last week - Show me recordings from users in a specific country - List the longest recordings from today - Find recordings where users visited a specific page - Show recordings with high activity scores - Find recordings for a specific person CRITICAL: Be minimalist. Only include filters and settings essential to answer the user's question. Default settings are usually sufficient. # Property filters Use property filters to narrow results. Only include filters directly relevant to the user's question. When using a property filter, you should: - **Prioritize properties directly related to the user's query.** - **Ensure the correct filter type.** Types: `person`, `session`, `event`, `recording`, `cohort`. - **Use `read-data-schema` to discover property names and values** before creating filters. ## Common properties **Recording** (type: `recording`): `console_error_count`, `click_count`, `keypress_count`, `mouse_activity_count`, `activity_score`. These are built-in metrics, not events. **Session** (type: `session`): `$session_duration`, `$channel_type`, `$entry_current_url`, `$entry_pathname`, `$is_bounce`, `$pageview_count`. **Person** (type: `person`): `$geoip_country_code`, `$geoip_city_name`, `email`, and custom person properties. **Event** (type: `event`): `$current_url`, `$pathname`, `$browser`, `$os`, `$device_type`, `$screen_width`. **Cohort** (type: `cohort`): scope recordings to persons belonging to a cohort. `key` is always `"id"`, `value` is the cohort ID, operator is `in` (or `not_in` to exclude). Example: `{ "type": "cohort", "key": "id", "value": 42, "operator": "in" }`. Use `cohorts-list` to find cohort IDs. ## Operators **String**: `exact`, `is_not`, `icontains`, `not_icontains`, `regex`, `not_regex`, `is_set`, `is_not_set` **Numeric**: `exact`, `is_not`, `gt`, `gte`, `lt`, `lte`, `is_set`, `is_not_set` **DateTime**: `is_date_exact`, `is_date_before`, `is_date_after`, `is_set`, `is_not_set` **Boolean**: `exact`, `is_not`, `is_set`, `is_not_set` `exact` and `is_not` accept arrays of values. Use `icontains` for URLs, `exact` for enumerated values, `gt`/`lt` for counts. # Ordering Sort recordings by: `start_time` (default), `duration`, `activity_score`, `console_error_count`, `click_count`, `keypress_count`, `mouse_activity_count`, `active_seconds`, `inactive_seconds`. Default direction is `DESC` (newest/highest first). # Date range - `date_from`: Relative (`-7d`, `-24h`) or absolute (`2025-01-15`). Default: `-3d`. - `date_to`: Relative or absolute. Default: now. Do not use property filters for time-based filtering. Use the `date_from`/`date_to` fields instead. # Pagination Use `limit` to control page size and `after` (from the previous response's `next_cursor`) for cursor-based pagination. # Response shape Each recording in results contains: - `id` — session recording ID - `distinct_id` — the person's distinct ID - `start_time` / `end_time` — recording time range (ISO 8601) - `recording_duration` — length in seconds - `active_seconds` / `inactive_seconds` — activity breakdown - `click_count`, `keypress_count`, `mouse_activity_count` — interaction counts - `console_log_count`, `console_warn_count`, `console_error_count` — console output counts - `start_url` — first page URL visited - `activity_score` — engagement score (higher = more active) - `ongoing` — whether the session is still active # Deep links to specific recordings To link a user to a specific recording, build the URL as `{posthog_base_url}/replay/{id}` using the `id` returned in each result row. Do not use `/replay/home?sessionRecordingId={id}` — that path takes the user to the replay list with the default filter applied and does not open the recording. # Examples ## Recent recordings with console errors ```json { "date_from": "-7d", "filter_test_accounts": true, "properties": [{ "key": "console_error_count", "operator": "gt", "type": "recording", "value": 0 }], "order": "console_error_count" } ``` ## Longest recordings today ```json { "date_from": "-1d", "filter_test_accounts": true, "order": "duration", "limit": 10 } ``` ## Recordings for a specific person ```json { "date_from": "-30d", "person_uuid": "01234567-89ab-cdef-0123-456789abcdef", "filter_test_accounts": true } ``` ## Recordings from mobile users ```json { "date_from": "-7d", "filter_test_accounts": true, "properties": [{ "key": "$device_type", "operator": "exact", "type": "event", "value": ["Mobile"] }] } ``` ## Recordings from a cohort of users ```json { "date_from": "-7d", "filter_test_accounts": true, "properties": [{ "key": "id", "operator": "in", "type": "cohort", "value": 42 }] } ``` ## Fetch specific recordings by session ID When you have known `$session_id` values (e.g., from `$exception` events or other event data), use the `session_ids` parameter to fetch those recordings directly: ```json { "session_ids": ["session-id-1", "session-id-2", "session-id-3"] } ``` # Reminders - Use `filter_test_accounts: true` by default to exclude internal users. - Only include property filters directly relevant to the user's question. - Default time range is last 3 days. Adjust based on the user's needs. - Deep-link to a specific recording as `{posthog_base_url}/replay/{id}`, never `/replay/home?sessionRecordingId={id}`. - For detailed analysis of a single recording, use `session-recording-get` with the recording's `id`. - **If no recordings are found** or the user asks why recordings aren't being captured, diagnose with `execute-sql`: query `$recording_status`, `$session_recording_start_reason`, `$replay_sample_rate`, and `$sdk_debug_recording_script_not_loaded` from recent events (no `$session_id` filter needed for project-wide issues). Common causes: sampling excluded sessions, recording disabled in project settings, ad blocker blocked the recorder script, or SDK misconfigured.

Sdk Doctor Get

Returns a pre-digested health report for the PostHog SDKs this project is using. Covers which SDKs are current vs outdated (smart-semver rules with grace periods and traffic-percentage thresholds), per-version breakdowns, and a human-readable reason for each assessment. Use when the user asks about PostHog SDK versions, outdated SDKs, SDK health, version upgrade recommendations, or why events may not be captured due to SDK issues.

Inbox Reports List

List signal reports for the current project. A signal report is a cluster of related observations (signals) that PostHog has aggregated into a single issue or trend. Reports surface in the Inbox. Supports filtering by status (potential, candidate, in_progress, pending_input, ready, failed, suppressed), free-text search across title and summary, source_product (e.g. error_tracking, session_replay), and suggested_reviewers (PostHog user UUIDs). Results are paginated and ordered by '-is_suggested_reviewer,status,-updated_at' by default.

Inbox Reports Retrieve

Get a single signal report by ID. Returns the full report including title, summary, status, priority and actionability judgments, signal_count, total_weight, source products, and the URL of the implementation PR if one has been opened. To inspect the underlying signals or judgment artefacts, follow up with a HogQL query (see the 'signals' skill) — those endpoints are not yet exposed via MCP.

Inbox Reports Set State

Transition a signal report to a new state. Use 'suppressed' to dismiss the report from the inbox (the user has reviewed it and decided no action is needed), or 'potential' to snooze it back into the pipeline for later review. Optionally include a `dismissal_reason` (a short string code owned by the caller, e.g. 'not_a_bug', 'wont_fix', 'duplicate') and a `dismissal_note` (free-form text, up to 4000 chars) — both are persisted as a DISMISSAL artefact on the report so the rationale is preserved even if the report transitions again later. Returns 409 if the transition is not allowed from the report's current status.

Inbox Source Configs List

List the configured signal sources for the current project. A signal source ties a product (e.g. error_tracking, session_replay, github, linear, zendesk) and a source_type to an enabled flag and configuration. The 'status' field reflects the current state of the underlying data import or workflow (running, completed, failed) when applicable.

Inbox Source Configs Retrieve

Get a single signal source config by ID. Returns the full record including source_product, source_type, enabled flag, configuration JSON, and current status of the underlying data import or workflow.

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 Delete

Delete a survey by ID (soft delete - marks as archived).

Survey Get

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

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.

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.

Surveys Get All

Get all surveys in the project with optional filtering. Can filter by search term or use pagination.

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.

Apm Attribute Values List

List values for a specific span or resource attribute key. Use to discover what values exist for a given attribute before building filters.

Apm Attributes List

List available span or resource attribute names. Use attribute_type "span_attribute" for span-level attributes or "span_resource_attribute" for resource-level attributes (e.g. k8s labels). Use this to discover available attribute keys before building filters.

Apm Services List

List distinct service names that have emitted trace spans. Use to discover available services before filtering spans by service name.

Apm Spans Aggregate

Aggregate trace span statistics grouped by `(service_name, name)` over a date window. Returns one row per `(service_name, name)` pair with the following metrics: - `count` — number of spans matched - `total_duration_nano`, `avg_duration_nano`, `p50_duration_nano`, `p95_duration_nano` — duration stats in nanoseconds (1 second = 1,000,000,000 ns) - `error_count` — spans with OTel status code `Error` (status_code = 2) Rows are ordered by `total_duration_nano` DESC and capped at 5000. Use to answer: - "Which services/operations consume the most time?" - "What's the p95 latency of `GET /users`?" - "How many errors did the checkout service emit in the last day?" - "Did `POST /orders` get slower this week vs last week?" (with `compareFilter`) For per-call-tree breakdowns (parent → child relationships), use `apm-spans-tree` instead. All parameters must be nested inside a `query` object. # Comparison window Set `query.compareFilter.compare: true` to also fetch a comparison window. The response then includes a `compare` array of the same shape as `results`. - Omit `compare_to` (or set null) to compare against the immediately previous period of equal length (e.g. `dateRange: -1d` → compares vs the day before). - Set `compare_to: "-7d"` to compare against the window 7 days earlier (same length as the primary window). # Data narrowing ## Property filters Use `query.filterGroup` to narrow results to spans matching specific attributes. Only include filters that are essential to the user's question. Filter `type` values: - `span` — built-in span fields (trace_id, span_id, duration, name, kind, status_code) - `span_attribute` — span-level attributes (e.g. "http.method", "http.status_code") - `span_resource_attribute` — resource-level attributes (e.g. k8s labels, deployment info) Use `apm-attributes-list` and `apm-attribute-values-list` to discover available attribute keys/values before guessing. Supported operators: - String: `exact`, `is_not`, `icontains`, `not_icontains`, `regex`, `not_regex` - Numeric: `exact`, `gt`, `lt` - Existence (no value needed): `is_set`, `is_not_set` ## Time period Use `query.dateRange` to control the time window. Default is the last hour (`-1h`). Examples: `-1h`, `-6h`, `-1d`, `-7d`. # Parameters All parameters go inside `query`. ## query.dateRange Date range for the primary window. Defaults to the last hour. - `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.compareFilter Optional comparison-window configuration. Omit when you only need the primary window. - `compare` (boolean): set to true to enable comparison. - `compare_to` (string, optional): relative offset for the comparison window (e.g. `-1d`, `-7d`). Defaults to the immediately previous period of equal length. ## query.serviceNames List of service names to restrict the aggregation to. Use `apm-services-list` to discover available services. ## query.filterGroup A flat list of property filters applied to both the primary and comparison windows. See the "Property filters" section. # Examples ## Top operations by total time in the last hour ```json { "query": {} } ``` ## p95 latency by operation in the last day ```json { "query": { "dateRange": { "date_from": "-1d" } } } ``` Inspect the `p95_duration_nano` field on each result. ## Compare this hour vs the previous hour ```json { "query": { "compareFilter": { "compare": true } } } ``` Returns `results` for the last hour and `compare` for the hour before. Diff `total_duration_nano`, `avg_duration_nano`, etc. to find regressions. ## Compare today vs same time last week ```json { "query": { "dateRange": { "date_from": "-1d" }, "compareFilter": { "compare": true, "compare_to": "-7d" } } } ``` ## Aggregate only error spans ```json { "query": { "filterGroup": [{ "key": "status_code", "operator": "exact", "type": "span", "value": 2 }], "dateRange": { "date_from": "-6h" } } } ``` ## Aggregate within one service ```json { "query": { "serviceNames": ["api-gateway"], "dateRange": { "date_from": "-1d" } } } ``` # Reminders - Duration values are in nanoseconds. Divide by 1,000,000 for ms, 1,000,000,000 for seconds. - Results are ordered by `total_duration_nano` DESC and capped at 5000 rows. - Use `apm-attributes-list` and `apm-attribute-values-list` to discover attribute keys/values before filtering. - Use `apm-services-list` to discover services before filtering by service name. - For parent → child breakdowns, use `apm-spans-tree` instead.

Apm Spans Tree

Aggregate trace span statistics as a call tree — one row per `(parent_service, parent_name) → (service_name, name)` edge. Requires a `spanName` to bound the matched trace set (the `(trace_id, parent_span_id)` self-join is unsafe at high cardinality without it), and a `serviceName` to scope the returned tree to a single service. All traces that contain at least one span with the given name in the given service are included, and every span in those traces from that service is aggregated against its parent. Returns rows with: - `parent_service`, `parent_name` — the parent span identity (`parent_name` is `"<ROOT>"` for root spans) - `service_name`, `name` — the child span identity - `count` — number of spans matched for this `(parent, child)` edge - `total_duration_nano`, `avg_duration_nano`, `p50_duration_nano`, `p95_duration_nano` — duration stats in nanoseconds - `error_count` — child spans with OTel status code `Error` (status_code = 2) - `avg_start_offset_nano` — average nanoseconds from the parent span's start to this child's start Rows are ordered by `total_duration_nano` DESC and capped at 5000. Use to answer: - "What does the `/checkout` flow actually call downstream?" - "Which child operation under `POST /orders` is the slowest?" - "Where is time spent inside `process_payment` — DB, external API, or something else?" - "Did the call tree under `/api/feed` change between last week and this week?" (with `compareFilter`) For a flat per-operation view (no parent linkage), use `apm-spans-aggregate` instead. All parameters must be nested inside a `query` object. # Comparison window Set `query.compareFilter.compare: true` to also fetch a comparison window. The response then includes a `compare` array of the same shape as `results`. - Omit `compare_to` (or set null) to compare against the immediately previous period of equal length. - Set `compare_to: "-7d"` to compare against the window 7 days earlier (same length as the primary window). # Data narrowing ## Property filters `query.filterGroup` narrows the matched span set. Same filter shape and operators as `apm-spans-aggregate` / `query-apm-spans`: - `span` — built-in span fields (trace_id, span_id, duration, name, kind, status_code) - `span_attribute` — span-level attributes - `span_resource_attribute` — resource-level attributes Use `apm-attributes-list` and `apm-attribute-values-list` to discover available attribute keys/values. ## Time period Use `query.dateRange` to control the time window. Default is the last hour (`-1h`). # Parameters All parameters go inside `query`. ## query.spanName (required) The span name that anchors the matched trace set. Every trace containing at least one span with this name (in the given `serviceName`) is included. Pick a high-level entry-point span (e.g. an HTTP route or job name). Generic names (`HTTP`, `GET`) match too many traces and produce noisy aggregates. Use `query-apm-spans` first if you need to discover concrete span names. ## query.serviceName (required) The service the tree should be scoped to. Applied to the spans CTE so the returned rows only contain spans from this service, even when the matched traces also touch other services. Use `apm-services-list` to discover service names. ## query.dateRange Date range for the primary window. Defaults to the last hour. - `date_from`: Start of the range. ISO 8601 or relative: `-1h`, `-6h`, `-1d`, `-7d`. - `date_to`: End of the range. Same format. Omit or null for "now". ## query.compareFilter Optional comparison-window configuration. Same shape as in `apm-spans-aggregate`. ## query.serviceNames List of service names to filter the matched span set. Use `apm-services-list` to discover services. ## query.filterGroup Property filters applied to both windows. See the "Property filters" section. # Examples ## Call tree under a specific operation in the last hour ```json { "query": { "spanName": "POST /api/orders", "serviceName": "web-server" } } ``` ## Call tree over the last day ```json { "query": { "spanName": "checkout_flow", "serviceName": "web-server", "dateRange": { "date_from": "-1d" } } } ``` ## Compare today's call tree vs last week ```json { "query": { "spanName": "POST /api/orders", "serviceName": "web-server", "dateRange": { "date_from": "-1d" }, "compareFilter": { "compare": true, "compare_to": "-7d" } } } ``` ## Restrict to error-bearing traces ```json { "query": { "spanName": "POST /api/orders", "serviceName": "web-server", "filterGroup": [{ "key": "status_code", "operator": "exact", "type": "span", "value": 2 }] } } ``` # Reminders - `spanName` and `serviceName` are both required. Bound `spanName` to a specific high-level span (avoid generic names like `HTTP`); set `serviceName` to the one service whose call-tree you want. - Root spans have `parent_name = "<ROOT>"` and `avg_start_offset_nano = 0`. - Duration values are in nanoseconds. - Results are ordered by `total_duration_nano` DESC and capped at 5000 rows. - For a flat per-operation aggregate without parent linkage, use `apm-spans-aggregate`. - Use `apm-services-list`, `apm-attributes-list`, `apm-attribute-values-list` to discover values before filtering.

Apm Trace Get

Fetch all spans for a specific trace by its hex trace ID. Returns the full span tree for the trace including parent-child relationships, timing, and status information. Use this to inspect a specific trace in detail after discovering it via the query tool.

Query Apm Spans

Query trace spans with filtering by service name, status code, date range, and structured attribute filters. Supports cursor-based pagination. Returns spans with uuid, trace_id, span_id, parent_span_id, name, kind, service_name, status_code, timestamp, end_time, duration_nano, and is_root_span. Use 'apm-attributes-list' and 'apm-attribute-values-list' to discover available attributes before building filters. Use 'apm-services-list' to discover available services. 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. 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.** Span property types are: - `span` — filters built-in span fields (trace_id, span_id, duration, name, kind, status_code). - `span_attribute` — filters span-level attributes (e.g. "http.method", "http.status_code"). - `span_resource_attribute` — filters resource-level attributes (e.g. k8s labels, deployment info). - **Use `apm-attributes-list` to discover available attribute keys** before building filters. - **Use `apm-attribute-values-list` to discover valid values** for a specific attribute key. - **Find the suitable operator for the value type** (see supported operators below). Supported operators: - String: `exact`, `is_not`, `icontains`, `not_icontains`, `regex`, `not_regex` - Numeric: `exact`, `gt`, `lt` - 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.serviceNames Filter by service names. Use `apm-services-list` to discover available services. ## query.statusCodes Filter by HTTP status codes (list of integers). ## 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` (span/span_attribute/span_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.traceId Filter to a specific trace ID (hex string). Use this when you already know the trace ID. ## query.rootSpans Filter to root spans only. Defaults to true. Set to false to include all spans in the trace tree. ## query.limit Maximum number of results (1-1000). Defaults to 100. ## query.after Cursor for pagination. Use the `nextCursor` value from the previous response. ## query.prefetchSpans Number of child spans to prefetch per trace (1-100). Useful to get a preview of trace structure without fetching the full trace. # Examples ## List recent error spans ```json { "query": { "statusCodes": [500, 503] } } ``` ## Search spans from a specific service ```json { "query": { "serviceNames": ["api-gateway"], "dateRange": { "date_from": "-1d" } } } ``` ## Filter by a span attribute ```json { "query": { "filterGroup": [{ "key": "http.method", "operator": "exact", "type": "span_attribute", "value": "POST" }], "dateRange": { "date_from": "-6h" } } } ``` ## Find slow spans ```json { "query": { "filterGroup": [{ "key": "duration", "operator": "gt", "type": "span", "value": "1000000000" }], "dateRange": { "date_from": "-1d" } } } ``` ## Combine service and attribute filters ```json { "query": { "serviceNames": ["web-server"], "filterGroup": [{ "key": "http.status_code", "operator": "gt", "type": "span_attribute", "value": "399" }], "dateRange": { "date_from": "-12h" } } } ``` ## Check if a resource attribute exists ```json { "query": { "filterGroup": [{ "key": "k8s.pod.name", "operator": "is_set", "type": "span_resource_attribute" }] } } ``` # Reminders - Ensure that any property filters are directly relevant to the user's question. Avoid unnecessary filtering. - Use `apm-attributes-list` and `apm-attribute-values-list` to discover attributes before guessing filter keys/values. - Use `apm-services-list` to discover available services before filtering by service name. - Duration values are in nanoseconds (1 second = 1,000,000,000 nanoseconds).

Web Analytics Weekly Digest

Summarizes a project's web analytics over a lookback window (default 7 days): unique visitors, pageviews, sessions, bounce rate, and average session duration with period-over-period comparisons, plus the top 5 pages, top 5 traffic sources, and goal conversions. Accepts optional `days` (1–90, default 7) and `compare` (bool, default true) query params — pass `days=30` to summarize the last month, or `compare=false` to skip the period-over-period comparison for a faster response. Use this to answer questions like "how are my web analytics?", "how did the site do last week?", or "what's my traffic looking like this month?".

Hog Flows Logs Retrieve

Retrieve execution logs for a specific workflow by ID. Returns log entries with timestamp, level (DEBUG, LOG, INFO, WARN, ERROR), and message. Use to debug why a workflow is failing or not producing expected results. Supports filtering by log level, text search, time range (after/before), and pagination via limit.

Hog Flows Metrics Retrieve

Retrieve execution metrics for a specific workflow by ID. Returns time-series data showing success and failure counts over a configurable interval (hour, day, or week). Use to understand workflow health, identify failure spikes, and monitor execution reliability. Supports breakdown by metric kind (success/failure) or name, and time range filtering.

Workflows Create

Create a workflow. Requires an actions array with exactly one type='trigger' (config sets trigger type: event|webhook|manual|batch|schedule|tracking_pixel). Other action types: function/function_email/function_sms/function_push (CDP template), delay (e.g. '30m'), conditional_branch, wait_until_condition. Connect via edges. Defaults to status='draft'; set 'active' to enable.

Workflows Get

Get a specific workflow by ID. Returns the full workflow definition including trigger, edges, actions, exit condition, and variables.

Workflows List

List all workflows in the project. Returns workflows with their name, description, status (draft/active/archived), version, trigger configuration, and timestamps.

Workflows Run

Test-invoke a saved workflow. Pass test event data via globals (typically {event, person, groups}). Async actions (HTTP/email/SMS) are mocked by default; set mock_async_functions=false to fire real side effects. Optional current_action_id starts from a specific node. Returns the execution trace.

Workflows Update

Update a workflow by ID. Use workflows-enable / workflows-disable / workflows-archive to change status.