Amplitude

Query up to 3 charts concurrently given their IDs. RULES: - Users want to know references for analyses in order to validate the data. - ALWAYS REFERENCE CHARTS TO THE USER BY THEIR LINK WHEN QUERIED AND USED IN ANALYSES. WHEN TO USE: - You want to query multiple charts to get their data efficiently. - Maximum of 3 charts can be queried in a single request. PREREQUISITES (required): - You MUST have at least one concrete `chartIds` or `chartEditIds` entry before calling this tool. Do not call it speculatively. - If you do not already have any, resolve them FIRST via: - `search` with `entityTypes: ["CHART"]` to find saved charts by name. - `get_from_url` when the user has shared Amplitude chart URLs. - `query_dataset` if the user wants an ad-hoc analysis rather than an existing chart. - If the user has not provided chart references and none of the above apply, STOP and ask the user which charts to query. INSTRUCTIONS: - Provide saved charts via `chartIds` and chart edits (links ending in `/chart/new/<edit_id>` or `/chart/<chart_id>/edit/<edit_id>`) via `chartEditIds`. - Chart edit IDs take precedence over chart IDs when both are available for a given chart. - Use this tool to query up to 3 charts + chart edits (combined total). - Results will include data for each successfully queried chart and errors for any failed charts. RESPONSE FORMAT: Returns {isCsvResponse: bool, csvResponse or jsonResponse, definition}. Only ONE response type present. When jsonResponse is present, "seriesNames" (string[]) gives the human-readable name of each timeSeries entry in order — use it instead of the numeric seriesLabels for ungrouped segments. "seriesKeys" (string[], same order) gives each series' customSerieLabels key; use it verbatim to rename a legend. Check the isCsvResponse flag to determine which response format to parse CRITICAL — NON-ADDITIVE METRICS (uniques, pct_dau): - These metrics cannot be summed across intervals. The chart UI plots per-interval values, not a running total. - Additive metrics (totals, sums) CAN be summed across intervals. How to read the JSON response, by metric type: 1. COUNT metrics ("uniques"): - Use "overallSeries" — it is the TRUE deduped unique count across the full date range. - Do NOT sum "timeSeries" values — that overstates the count due to user overlap across intervals. 2. RATIO metrics ("pct_dau" only): - Use "timeSeriesAverage" (mean of per-interval values) — this matches what the chart UI displays. For "current" reporting, also consider the most recent N intervals from "timeSeries". - Do NOT use "overallSeries" for pct_dau over multi-interval ranges. For pct_dau, "overallSeries" is a long-range aggregate (deduped numerator over the full range / deduped denominator over the full range). Over many intervals the denominator dedupes a much larger pool than the numerator, which compresses the ratio — typically reporting roughly half of the per-interval values the chart shows. This is mathematically valid as a long-range aggregate but is NOT what users see in the chart. - Do NOT sum "timeSeries" values — ratios cannot be summed. CSV Response Structure (when isCsvResponse is true): - Header rows: The top rows contain metadata including chart name, description, events, formulas, and other chart configuration details - Data header row: A single row containing column labels for the data points below (typically includes dates or time periods) - Data rows: Each row contains: * Label columns: First few columns contain row labels identifying the data series * Value columns: Numerical data organized under the corresponding date/time columns from the data header row - Parse by: Skip metadata rows, identify the data header row, then extract labels from first columns and values from remaining columns - Cells in the CSV response are delimited by commas and may be prepended with a character Example below measures uniques of custom event "Valuable Tweaking" over 3 days (2025-08-23, 2025-08-24, 2025-08-25) for all users. The data points are 614, 1769, and 4132 for the 3 days respectively. IMPORTANT: The overall unique users is 5642 (NOT 614+1769+4132=6515), because users overlap across days. data: " Example chart name" " Formula"," UNIQUES(A)" " A:"," [Custom] 'Valuable Tweaking'" " Segment"," 2025-08-23"," 2025-08-24"," 2025-08-25" " All Non-Amplitude Users","614","1769","4132" definition: { "app": "APP_ID", "params": { "countGroup": "User", "end": 1756166399, "events": [ { "event_type": "ce:'Valuable Tweaking'", "filters": [], "group_by": [] } ], "groupBy": [], "interval": 1, "metric": "uniques", "segments": [], "start": 1755907200, }, "type": "eventsSegmentation", } JSON Response Structure (when isCsvResponse is false): - Parse using the following structure: - timeSeries: Array of arrays, each containing data points for a given time period with a "value" property and, when present, "setId"/"setIds" identifying the users at that point. For microscope drill-down, call create_cohort_from_set_ids with those set IDs (or use_amplitude_cohorts with action create_from_set_ids when consolidated) — not create_cohort (behavioral definition) or get_users (requires event.event_type) - overallSeries: Array of arrays, each containing the overall data point across the entire range under the "value" property. IMPORTANT — interpretation depends on the metric: * For "uniques" (count): this is the TRUE deduped unique count over the full date range. Use this. * For "pct_dau" (ratio): this is a long-range aggregate ratio (deduped numerator over range / deduped denominator over range). It does NOT match the per-interval values the chart UI plots and is typically much smaller. Do NOT report it as the headline number — use "timeSeriesAverage" instead. - timeSeriesAverage: Present only for "pct_dau". Array of arrays, one per series, each containing a single {value} that is the mean of "timeSeries" values for that series. Use this as the headline ratio when the chart spans multiple intervals — it matches what users see in the chart UI. - seriesMetadata: Array of objects containing metadata for each series - xValuesForTimeSeries: Array of strings representing the x-axis values (dates) for the time series - Use the dataset definition to be able to parse referenced events, properties, and segments. Example below is a JSON response is for the same query as the CSV example above. { "timeSeries": [[{"value": 614}, {"value": 1769}, {"value": 4132}]], "overallSeries": [[{"value": 5642}]], "seriesMetadata": [{"segmentIndex": 0, "formulaIndex": 0, "formula": "UNIQUES(A)"}], "xValuesForTimeSeries": ["2025-08-23T00:00:00", "2025-08-24T00:00:00", "2025-08-25T00:00:00"] } Note: 614+1769+4132=6515, but overallSeries shows 5642. This is because unique users overlap across days. For "uniques", always use overallSeries for the total. Example below is a "pct_dau" query over 3 weeks (a ratio metric): { "timeSeries": [[{"value": 0.1402}, {"value": 0.1421}, {"value": 0.1444}]], "overallSeries": [[{"value": 0.0712}]], "timeSeriesAverage": [[{"value": 0.1422}]], "seriesMetadata": [{"segmentIndex": 0, "formulaIndex": 0, "formula": "PCT_DAU(A)"}], "xValuesForTimeSeries": ["2026-04-06T00:00:00", "2026-04-13T00:00:00", "2026-04-20T00:00:00"] } Note: the chart UI shows ~14% per week. timeSeriesAverage (14.22%) matches that. overallSeries (7.12%) is the deduped 3-week aggregate ratio and would HALVE the reported value if used as the headline — never report it as "the number" for "pct_dau". Always use timeSeriesAverage for "pct_dau". Event Segmentation with Insights (anomaly detection / confidence intervals): - When params.insights.isOn is true, Event Segmentation charts queried via query_charts or query_dataset return jsonResponse with joinable band data. - To also receive chartConfig (Highcharts), explicitly pass includeAdditionalInfo: ["chartConfig"]. - jsonResponse.seriesIntervals maps stringified seriesMetadata keys to { low, high, yhat } arrays (parallel to xValuesForTimeSeries). Use seriesMetadata + xValuesForTimeSeries to join bands to series. - Metric Explorer charts with Insights return seriesIntervals inside each data[] entry instead.

query_charts

Run analytics queries to answer data questions about users, events, funnels, and retention. Chart definitions are validated inline before querying. When validation fails, the response includes chartTypeSchema (parameter schema, valid enums, working example, coercion rules) so you can fix the definition and retry. Optional: call verify_chart_definition first for a dry-run validation without executing a query. # WHEN TO USE - Answer questions like: - "How many active users did we have last week?" - "Show me a funnel from sign up to purchase" - "What is the retention rate for new users?" - "How many users completed checkout yesterday?" - Any question asking for metrics, counts, trends, funnels, or retention analysis # DO NOT USE FOR: - Heatmaps and zoning for a page URL (click map, scroll depth, zone metrics such as click rate or rage clicks per zone) → use 'run_amp' (`heatmaps click-map`, `heatmaps scroll-map`, `zoning zone-metrics`). Dataset queries cannot serve them. - Listing or checking which properties exist on an event (e.g. "what/which properties are on the checkout event?") → use 'get_properties' (propertyType="event", pass eventType). Do NOT run queries to discover a schema. - Finding existing charts/dashboards → use 'search' instead - Getting valid chart definition structure → use 'get_chart_definition_params' (or fix from chartTypeSchema in a validation-error response) - If you need more information about existing charts in the project as an example → use 'get_charts' instead - Project settings (timezone, currency) → use 'get_project_context' instead # STRATEGIES 1. Use 'get_events' to discover the exact event name, then query directly. Do not page the project-wide property catalogue unless the requested analysis needs a property. 2. Use 'get_chart_definition_params' when you need the full schema before building a definition (optional — validation errors also return chartTypeSchema). 3. Use the 'get_charts' tool to find examples of existing charts in the project to understand the events, properties, and dataset schema generally. 4. Optionally use the 'search' tool again to find additional events, user properties, etc. needed for the query. 5. Optionally use the 'get_properties' tool (propertyType="event", pass eventType) to get properties on individual events. 6. Use this tool to query the ad hoc analysis — definitions are validated and auto-corrected inline. # GENERAL GUIDELINES - Read saved metric definitions with get_metrics or use_amplitude_metrics action="get_metrics" before building a chart from them. - Don't assume or guess properties, events, or schema. Use the tools provided to you to understand the data before running a dataset query. - When running into query failures, try searching for existing charts to understand the data taxonomy and dataset schema. - When you receive a validation error, use the returned chartTypeSchema to fix the definition. - ALWAYS include a descriptive "name" field in the definition object. This name will be displayed as the chart title. Examples: "Active Users Last 7 Days", "Sign Up to Purchase Funnel", "New User Retention". # AMPLITUDE WIDE META EVENTS TYPES Special system events available for analysis. Events are passed in the "event_type" field: - "_active": Any active event useful for tracking 'active users' like DAU, MAU(events not marked as inactive) - "_all": Any event being tracked in Amplitude - "_new": Events triggered by new users within the time interval. Useful for tracking 'new users'. - "_any_revenue_event": Any revenue-generating event. Useful for tracking 'revenue'. - "$popularEvents": Top events by volume (dynamically computed). Useful for more meta taxonomy analyses like 'what are the most common events'. # PROPERTY TYPES: - Amplitude core properties are built-in and use standard names like "country", "platform", "device_id", "user_id" - Custom properties are organization-defined and are typically prefixed with "gp:" - Derived/formula properties (from TMS) must use prop_type and group_by.type of "derivedV2" in segments and group_by — not "user" or legacy "derived". Use get_properties with propertyType "derived" to list them. - Hidden properties are intentionally excluded from get_properties; do not use them. Prefer derived replacements named in project context. - If you are unsure which properties exist, use get_properties (propertyType="event", pass eventType) first — this is the direct way to list an event's properties. search/get_charts are fallbacks for discovering related events or example charts. Supported chart types: eventsSegmentation, funnels, metricExplorer, retention, revenueLtv, sessions, stickiness RESPONSE FORMAT: Returns {isCsvResponse: bool, csvResponse or jsonResponse, definition}. Only ONE response type present. When jsonResponse is present, "seriesNames" (string[]) gives the human-readable name of each timeSeries entry in order — use it instead of the numeric seriesLabels for ungrouped segments. "seriesKeys" (string[], same order) gives each series' customSerieLabels key; use it verbatim to rename a legend. Check the isCsvResponse flag to determine which response format to parse CRITICAL — NON-ADDITIVE METRICS (uniques, pct_dau): - These metrics cannot be summed across intervals. The chart UI plots per-interval values, not a running total. - Additive metrics (totals, sums) CAN be summed across intervals. How to read the JSON response, by metric type: 1. COUNT metrics ("uniques"): - Use "overallSeries" — it is the TRUE deduped unique count across the full date range. - Do NOT sum "timeSeries" values — that overstates the count due to user overlap across intervals. 2. RATIO metrics ("pct_dau" only): - Use "timeSeriesAverage" (mean of per-interval values) — this matches what the chart UI displays. For "current" reporting, also consider the most recent N intervals from "timeSeries". - Do NOT use "overallSeries" for pct_dau over multi-interval ranges. For pct_dau, "overallSeries" is a long-range aggregate (deduped numerator over the full range / deduped denominator over the full range). Over many intervals the denominator dedupes a much larger pool than the numerator, which compresses the ratio — typically reporting roughly half of the per-interval values the chart shows. This is mathematically valid as a long-range aggregate but is NOT what users see in the chart. - Do NOT sum "timeSeries" values — ratios cannot be summed. CSV Response Structure (when isCsvResponse is true): - Header rows: The top rows contain metadata including chart name, description, events, formulas, and other chart configuration details - Data header row: A single row containing column labels for the data points below (typically includes dates or time periods) - Data rows: Each row contains: * Label columns: First few columns contain row labels identifying the data series * Value columns: Numerical data organized under the corresponding date/time columns from the data header row - Parse by: Skip metadata rows, identify the data header row, then extract labels from first columns and values from remaining columns - Cells in the CSV response are delimited by commas and may be prepended with a character Example below measures uniques of custom event "Valuable Tweaking" over 3 days (2025-08-23, 2025-08-24, 2025-08-25) for all users. The data points are 614, 1769, and 4132 for the 3 days respectively. IMPORTANT: The overall unique users is 5642 (NOT 614+1769+4132=6515), because users overlap across days. data: " Example chart name" " Formula"," UNIQUES(A)" " A:"," [Custom] 'Valuable Tweaking'" " Segment"," 2025-08-23"," 2025-08-24"," 2025-08-25" " All Non-Amplitude Users","614","1769","4132" definition: { "app": "APP_ID", "params": { "countGroup": "User", "end": 1756166399, "events": [ { "event_type": "ce:'Valuable Tweaking'", "filters": [], "group_by": [] } ], "groupBy": [], "interval": 1, "metric": "uniques", "segments": [], "start": 1755907200, }, "type": "eventsSegmentation", } JSON Response Structure (when isCsvResponse is false): - Parse using the following structure: - timeSeries: Array of arrays, each containing data points for a given time period with a "value" property and, when present, "setId"/"setIds" identifying the users at that point. For microscope drill-down, call create_cohort_from_set_ids with those set IDs (or use_amplitude_cohorts with action create_from_set_ids when consolidated) — not create_cohort (behavioral definition) or get_users (requires event.event_type) - overallSeries: Array of arrays, each containing the overall data point across the entire range under the "value" property. IMPORTANT — interpretation depends on the metric: * For "uniques" (count): this is the TRUE deduped unique count over the full date range. Use this. * For "pct_dau" (ratio): this is a long-range aggregate ratio (deduped numerator over range / deduped denominator over range). It does NOT match the per-interval values the chart UI plots and is typically much smaller. Do NOT report it as the headline number — use "timeSeriesAverage" instead. - timeSeriesAverage: Present only for "pct_dau". Array of arrays, one per series, each containing a single {value} that is the mean of "timeSeries" values for that series. Use this as the headline ratio when the chart spans multiple intervals — it matches what users see in the chart UI. - seriesMetadata: Array of objects containing metadata for each series - xValuesForTimeSeries: Array of strings representing the x-axis values (dates) for the time series - Use the dataset definition to be able to parse referenced events, properties, and segments. Example below is a JSON response is for the same query as the CSV example above. { "timeSeries": [[{"value": 614}, {"value": 1769}, {"value": 4132}]], "overallSeries": [[{"value": 5642}]], "seriesMetadata": [{"segmentIndex": 0, "formulaIndex": 0, "formula": "UNIQUES(A)"}], "xValuesForTimeSeries": ["2025-08-23T00:00:00", "2025-08-24T00:00:00", "2025-08-25T00:00:00"] } Note: 614+1769+4132=6515, but overallSeries shows 5642. This is because unique users overlap across days. For "uniques", always use overallSeries for the total. Example below is a "pct_dau" query over 3 weeks (a ratio metric): { "timeSeries": [[{"value": 0.1402}, {"value": 0.1421}, {"value": 0.1444}]], "overallSeries": [[{"value": 0.0712}]], "timeSeriesAverage": [[{"value": 0.1422}]], "seriesMetadata": [{"segmentIndex": 0, "formulaIndex": 0, "formula": "PCT_DAU(A)"}], "xValuesForTimeSeries": ["2026-04-06T00:00:00", "2026-04-13T00:00:00", "2026-04-20T00:00:00"] } Note: the chart UI shows ~14% per week. timeSeriesAverage (14.22%) matches that. overallSeries (7.12%) is the deduped 3-week aggregate ratio and would HALVE the reported value if used as the headline — never report it as "the number" for "pct_dau". Always use timeSeriesAverage for "pct_dau". Event Segmentation with Insights (anomaly detection / confidence intervals): - When params.insights.isOn is true, Event Segmentation charts queried via query_charts or query_dataset return jsonResponse with joinable band data. - To also receive chartConfig (Highcharts), explicitly pass includeAdditionalInfo: ["chartConfig"]. - jsonResponse.seriesIntervals maps stringified seriesMetadata keys to { low, high, yhat } arrays (parallel to xValuesForTimeSeries). Use seriesMetadata + xValuesForTimeSeries to join bands to series. - Metric Explorer charts with Insights return seriesIntervals inside each data[] entry instead.

query_dataset_chatgpt

Query an experiment analysis. CRITICAL: Do NOT pass metricIds unless user explicitly requests specific metrics or requests analysis on secondary metrics. Omit metricIds for primary metric only (cleaner, focused results). RULES: - Users want to know references for analyses in order to validate the data. - ALWAYS REFERENCE EXPERIMENTS TO THE USER BY THEIR LINK WHEN QUERIED AND USED IN ANALYSES. WHEN TO USE: - You want to query a experiment for analysis. INSTRUCTIONS: - Use the search tool to find the ID of the experiment you want to query. - You may want to use the get_experiments tool to get more context about the experiment (i.e. state, variants, etc.) - Use this tool to query the experiment analysis. EXAMPLE: groupBy: [{"type": "user", "value": "device type", "group_type": "User"}]

query_experiment

Query metric data using the dataset endpoint with metric references RULES: - Users want to know references for analyses in order to validate the data. - ALWAYS REFERENCE METRICS TO THE USER BY THEIR LINK WHEN QUERIED AND USED IN ANALYSES. WHEN TO USE: - You want to query a metric to get its data. INSTRUCTIONS: - If the metric ID is already known, query it directly; search only when you need to discover the ID. - Preserve the requested date window and grouping. For a day-based window grouped weekly, use query_dataset with explicit start/end and interval=7, or query_amplitude_data with the same raw definition when query_dataset is unavailable. - For saved AmpSQL metrics with declared-column filters or breakdowns, use query_dataset (or query_amplitude_data) with a raw chart definition instead. RESPONSE FORMAT: Returns {isCsvResponse: bool, csvResponse or jsonResponse, definition}. Only ONE response type present. When jsonResponse is present, "seriesNames" (string[]) gives the human-readable name of each timeSeries entry in order — use it instead of the numeric seriesLabels for ungrouped segments. "seriesKeys" (string[], same order) gives each series' customSerieLabels key; use it verbatim to rename a legend. Check the isCsvResponse flag to determine which response format to parse CRITICAL — NON-ADDITIVE METRICS (uniques, pct_dau): - These metrics cannot be summed across intervals. The chart UI plots per-interval values, not a running total. - Additive metrics (totals, sums) CAN be summed across intervals. How to read the JSON response, by metric type: 1. COUNT metrics ("uniques"): - Use "overallSeries" — it is the TRUE deduped unique count across the full date range. - Do NOT sum "timeSeries" values — that overstates the count due to user overlap across intervals. 2. RATIO metrics ("pct_dau" only): - Use "timeSeriesAverage" (mean of per-interval values) — this matches what the chart UI displays. For "current" reporting, also consider the most recent N intervals from "timeSeries". - Do NOT use "overallSeries" for pct_dau over multi-interval ranges. For pct_dau, "overallSeries" is a long-range aggregate (deduped numerator over the full range / deduped denominator over the full range). Over many intervals the denominator dedupes a much larger pool than the numerator, which compresses the ratio — typically reporting roughly half of the per-interval values the chart shows. This is mathematically valid as a long-range aggregate but is NOT what users see in the chart. - Do NOT sum "timeSeries" values — ratios cannot be summed. CSV Response Structure (when isCsvResponse is true): - Header rows: The top rows contain metadata including chart name, description, events, formulas, and other chart configuration details - Data header row: A single row containing column labels for the data points below (typically includes dates or time periods) - Data rows: Each row contains: * Label columns: First few columns contain row labels identifying the data series * Value columns: Numerical data organized under the corresponding date/time columns from the data header row - Parse by: Skip metadata rows, identify the data header row, then extract labels from first columns and values from remaining columns - Cells in the CSV response are delimited by commas and may be prepended with a character Example below measures uniques of custom event "Valuable Tweaking" over 3 days (2025-08-23, 2025-08-24, 2025-08-25) for all users. The data points are 614, 1769, and 4132 for the 3 days respectively. IMPORTANT: The overall unique users is 5642 (NOT 614+1769+4132=6515), because users overlap across days. data: " Example chart name" " Formula"," UNIQUES(A)" " A:"," [Custom] 'Valuable Tweaking'" " Segment"," 2025-08-23"," 2025-08-24"," 2025-08-25" " All Non-Amplitude Users","614","1769","4132" definition: { "app": "APP_ID", "params": { "countGroup": "User", "end": 1756166399, "events": [ { "event_type": "ce:'Valuable Tweaking'", "filters": [], "group_by": [] } ], "groupBy": [], "interval": 1, "metric": "uniques", "segments": [], "start": 1755907200, }, "type": "eventsSegmentation", } JSON Response Structure (when isCsvResponse is false): - Parse using the following structure: - timeSeries: Array of arrays, each containing data points for a given time period with a "value" property and, when present, "setId"/"setIds" identifying the users at that point. For microscope drill-down, call create_cohort_from_set_ids with those set IDs (or use_amplitude_cohorts with action create_from_set_ids when consolidated) — not create_cohort (behavioral definition) or get_users (requires event.event_type) - overallSeries: Array of arrays, each containing the overall data point across the entire range under the "value" property. IMPORTANT — interpretation depends on the metric: * For "uniques" (count): this is the TRUE deduped unique count over the full date range. Use this. * For "pct_dau" (ratio): this is a long-range aggregate ratio (deduped numerator over range / deduped denominator over range). It does NOT match the per-interval values the chart UI plots and is typically much smaller. Do NOT report it as the headline number — use "timeSeriesAverage" instead. - timeSeriesAverage: Present only for "pct_dau". Array of arrays, one per series, each containing a single {value} that is the mean of "timeSeries" values for that series. Use this as the headline ratio when the chart spans multiple intervals — it matches what users see in the chart UI. - seriesMetadata: Array of objects containing metadata for each series - xValuesForTimeSeries: Array of strings representing the x-axis values (dates) for the time series - Use the dataset definition to be able to parse referenced events, properties, and segments. Example below is a JSON response is for the same query as the CSV example above. { "timeSeries": [[{"value": 614}, {"value": 1769}, {"value": 4132}]], "overallSeries": [[{"value": 5642}]], "seriesMetadata": [{"segmentIndex": 0, "formulaIndex": 0, "formula": "UNIQUES(A)"}], "xValuesForTimeSeries": ["2025-08-23T00:00:00", "2025-08-24T00:00:00", "2025-08-25T00:00:00"] } Note: 614+1769+4132=6515, but overallSeries shows 5642. This is because unique users overlap across days. For "uniques", always use overallSeries for the total. Example below is a "pct_dau" query over 3 weeks (a ratio metric): { "timeSeries": [[{"value": 0.1402}, {"value": 0.1421}, {"value": 0.1444}]], "overallSeries": [[{"value": 0.0712}]], "timeSeriesAverage": [[{"value": 0.1422}]], "seriesMetadata": [{"segmentIndex": 0, "formulaIndex": 0, "formula": "PCT_DAU(A)"}], "xValuesForTimeSeries": ["2026-04-06T00:00:00", "2026-04-13T00:00:00", "2026-04-20T00:00:00"] } Note: the chart UI shows ~14% per week. timeSeriesAverage (14.22%) matches that. overallSeries (7.12%) is the deduped 3-week aggregate ratio and would HALVE the reported value if used as the headline — never report it as "the number" for "pct_dau". Always use timeSeriesAverage for "pct_dau". Event Segmentation with Insights (anomaly detection / confidence intervals): - When params.insights.isOn is true, Event Segmentation charts queried via query_charts or query_dataset return jsonResponse with joinable band data. - To also receive chartConfig (Highcharts), explicitly pass includeAdditionalInfo: ["chartConfig"]. - jsonResponse.seriesIntervals maps stringified seriesMetadata keys to { low, high, yhat } arrays (parallel to xValuesForTimeSeries). Use seriesMetadata + xValuesForTimeSeries to join bands to series. - Metric Explorer charts with Insights return seriesIntervals inside each data[] entry instead.

query_metric

Create a chart alert monitor on a saved chart that does not already have one. WHEN TO USE: - The user wants to start alerting on a chart. - get_config returned hasMonitor=false for this chartId. INSTRUCTIONS: - Provide chartId. Defaults to a smart/automatic monitor (99% confidence interval, above or below). - Optional name, frequency (daily or hourly), conditions, and emailRecipients. Emails default to the current user. - Only chart owners and project managers can create a monitor. - If a monitor already exists, do not create another — use get_config, then subscribe or update. EXAMPLES: - {"chartId":"abc123"} - {"chartId":"abc123","frequency":"hourly","name":"Hourly active users"} - {"chartId":"abc123","conditions":[{"type":"automatic","confidence_interval":95,"direction":"below"}]} NOTES: - This does not query chart data. Use get_amplitude_charts or query_amplitude_data for that. - After create, use subscribe_chart_alert (or action=subscribe) to add Slack/Teams, and update_chart_monitor to enable/disable.

create_chart_monitor

Create a comprehensive dashboard with charts, rich text, and custom layout WHEN TO USE: - After the user has searched existing content or explored some analysis in Amplitude - The user has explicitly requested to create a dashboard CRITICAL - CHART IDs MUST BE FROM SAVED CHARTS: - Only use chartIds from SAVED/PERMANENT charts - these are returned by save_chart_edits (in the chartId field) or create_chart - DO NOT use editIds from query_amplitude_data — this tool cannot persist them. Call save_chart_edits first, or create via use_amp_dashboards which saves edit IDs automatically - The typical workflow is: query_amplitude_data (returns editId) → save_chart_edits (converts editId to permanent chartId) → create_dashboard (uses chartId) - If you use an editId instead of a saved chartId, this tool fails with "NotFoundError: No chart" INSTRUCTIONS: - Provide a descriptive name for the dashboard - Saves unpublished to your personal space by default. To put it somewhere the team can see, pass destination {"kind":"space","spaceId":"..."} using a space id from the user or a shared-space URL. To create a space or move an existing dashboard, use manage_amp_entities. The response echoes where it landed in savedTo - Shared-space creates always notify members. DashboardService.createDashboard has no quiet flag, so destination.notify is ignored here - Use rows array where each row contains items in left-to-right order - Each item specifies width (3-12 columns). If width is omitted, items auto-fill remaining space - Each row must specify height in pixels. Only heights of 375, 500, 625, 750 are allowed - Total width of items in a row must not exceed 12 columns - Max 4 items per row (ensures minimum 3-column width per item) - Use chartMetas to configure chart display options (view type, annotations, etc.) - Return a link to the new dashboard in the response - DO NOT include static analysis in dashboard text content. Dashboards are meant to be long-lived and thus a point in time insight does not help - DO group similar charts together and include a header and some text describing how to interpret the charts effectively MARKDOWN FORMAT: - Rich text content uses standard markdown syntax - Supported: headers (# ## ###), bold (**text**), italic (*text*), lists (- or 1.), links ([text](url)), code blocks (```), inline code (`code`) - Example: "# Overview\n\nThis dashboard shows **key metrics** for user engagement." LAYOUT EXAMPLES: - Full-width item: { height: 6, items: [{ type: 'chart', chartId: '123', width: 12 }] } - Two side-by-side: { height: 4, items: [{ type: 'chart', chartId: '1', width: 6 }, { type: 'rich_text', content: '# Notes', width: 6 }] } - Three columns: { height: 5, items: [{ width: 4 }, { width: 4 }, { width: 4 }] } - Auto-fill: { height: 4, items: [{ type: 'chart', chartId: '1' }, { type: 'chart', chartId: '2' }] } (each gets 6 columns)

create_dashboard

Get detailed information about specific cohorts by their IDs. WHEN TO USE: - You want to retrieve full cohort definitions after finding them via search. - You need detailed cohort information including definition, metadata, and audience details. INSTRUCTIONS: - Use the search tool to find the IDs of cohorts you want to retrieve, then call this tool with the IDs. - This returns full cohort objects with all details, unlike the search tool which returns summary information.

get_cohorts

Single read entry point for Amplitude Agent Analytics (AI/LLM session investigation). NOT FOR: Customer product feedback (use use_amplitude_ai_feedback) or browser Session Replay. Set `view` to choose the read route (each view has its own parameters in the tool schema): - `schema` — fields, rubrics, taxonomy, filter_options. Use only when an exact filter identifier is not already known; request only the needed filterOptionTypes. - `sessions` — filtered session lists and groupBy aggregations (replaces metrics/timeseries tools). - `conversation` — full transcript; sessionId is required. - `spans` — per-operation trace; sessionId or traceId is required (no org-wide scans). - `tool_reliability` — metrics enum is only tool_stats | tool_definitions. REMOVED (use sessions filters instead): - search_agent_analytics_conversations (ILIKE scans) - query_agent_analytics_metrics quality/cost/topics/timeseries enums EXAMPLES: - Agent names: { "view": "schema", "projectId": "12345", "include": ["filter_options"], "filterOptionTypes": ["agent_names"] } - Failed sessions: { "view": "sessions", "projectId": "12345", "hasTechnicalFailure": true, "agentNames": ["global-chat"] } - Transcript: { "view": "conversation", "projectId": "12345", "sessionId": "abc-123" } - Tool reliability: { "view": "tool_reliability", "projectId": "12345", "metrics": ["tool_stats","tool_definitions"], "agentNames": ["global-chat"] }

get_amplitude_agent_analytics_info

Unified entry point for Amplitude context. Routes to one of two underlying tools based on whether a `projectId` is provided. ROUTES: - No `projectId` → 'get_context' route: returns the current user, organization (including org-level AI context), and the LIST of accessible projects as `{ appId, appName }`. Use this to discover which projects exist and their ids. - `projectId` provided → 'get_project_context' route: returns that single project's details — description, timezone, currency, session definition, source projects, project-level AI context, and data view definition when applicable. WHEN TO USE: - Session start, "what projects do I have access to?", "show me my org details", "what is my role?" → call with no arguments. - "what timezone / currency / session settings does project X use?", "describe project X" → pass `projectId`. CONTEXT DOCUMENTS (uploaded files): - `org.aiContext` / project `aiContext` are short text fields only. Customers also upload context files (CSV data dictionaries, PDFs, process docs) in Settings → AI Controls; those are indexed for search and never returned in full — only titles (opt-in) or search snippets. - `listContextDocuments: true` adds `contextDocuments` — document titles and ids only, no file contents. Use it when `aiContext` references an uploaded file by name (e.g. "always check <file> before answering"). - `searchContextDocuments` runs semantic search over the uploaded documents' contents and adds `contextDocumentSearch` with matching text snippets. Use specific terms from the user's question (event names, property names, column names). - Scope for both: without `projectId`, org-level documents only; with `projectId`, org-level plus that project's documents. EXAMPLES: - Session start: {} - Project settings: {"projectId": 12345} - aiContext says "check the event dictionary file" → {"projectId": 12345, "listContextDocuments": true} - Look up a term from uploaded docs: {"projectId": 12345, "searchContextDocuments": "envelope_event_type_id"} NOTES: - `projectId` is optional on purpose. Omit it to get the project list first, then call again with a real id from that list — do NOT guess project ids. - The two layers are meant to be loaded together: call once without `projectId` at session start for org context, then with a `projectId` to drill into a project. On conflict, project-level context overrides org-level. - Omit `listContextDocuments` and `searchContextDocuments` at session start — they add latency and are only useful once you know what to look for. - A data view is a governed, filtered subset of a source project. Use its projectId for analysis to preserve its filters. The returned dataView.sourceAppId describes lineage, not a replacement query target. DO NOT USE FOR: - Running analytics queries → use 'query_dataset'. - Finding charts/dashboards/cohorts → use 'search'.

get_amplitude_context

Unified entry point for session replay data: find replays and inspect what happened in them. Replaces get_session_replays, list_session_replays, get_session_replay_events, and get_session_replay_timeline. ACTIONS: - `search` (default): find replays by event / user-property / cohort filters, by Amplitude user (`userId`), by ID (`sessionReplayIds`), or sample recent sessions with no filters (random slice from the last 24 hours). - `list`: simple paginated time-range listing via the public Session Replay API (`start_time`/`end_time`/`page_size`/`page_token`). Use `search` instead when filtering by events or user properties. - `events`: processed rrweb interaction timeline for one replay (`sessionReplayId`) — page navigations, clicks, inputs, scrolls. - `timeline`: full analytics event timeline for one replay (`sessionReplayId`) — every event the user fired during and around the session. PREFER THIS over user-timeline tools when you have a replay ID. REQUIRED FOLLOW-UP — render_amp_session_replay: - After `search`/`list` return replay IDs, you MUST call `render_amp_session_replay` in the SAME turn whenever the user's request implies viewing the replays ("show me", "let me see", "pull up", "watch", "play", "open", or any phrasing where seeing the replays is the deliverable). A list of IDs alone is not the answer the user wants. - ONLY skip the render call for raw data extraction ("just count them", "export the IDs"). When in doubt, render. INSTRUCTIONS: - Provide `projectId` for every action. - Replay IDs use the "<device_id>/<session_id>" format — pass them verbatim between actions. - search: filters are ANDed; reference real event names (call get_events first if unsure). `userId` and `sessionReplayIds` are mutually exclusive with each other and with filters. - list: use the returned next_page_token to fetch subsequent pages; keep sort_order consistent across pages. The list response's start/end times describe the analytics session window, NOT the recorded replay length. - events vs timeline: `events` shows what the user DID in the recording (clicks/inputs/navigation from rrweb); `timeline` shows which analytics EVENTS fired (with properties). For "walk me through this session" prefer `timeline`. EXAMPLES: - Sample recent sessions: { "projectId": "12345" } - Users who hit checkout errors: { "action": "search", "projectId": "12345", "events": [{ "name": "Checkout", "withProperty": { "name": "error_type", "exists": true } }] } - Replays for a user yesterday: { "action": "search", "projectId": "12345", "userId": "98765", "since": "yesterday" } - Paginated listing: { "action": "list", "projectId": "12345", "page_size": 50, "sort_order": "desc" } - What the user did in a replay: { "action": "events", "projectId": "12345", "sessionReplayId": "device-abc/1773235450374" } - Events fired during a replay: { "action": "timeline", "projectId": "12345", "sessionReplayId": "device-abc/1773235450374", "includeEventProperties": true } NOTES: - search defaults: 10 results; 30-day window for filtered queries, 24 hours otherwise. If a filtered search is empty, widen the window or relax filters instead of retrying unchanged. - list defaults to the last 48 hours when no time range is provided. - Cohort filters take numeric IDs only — resolve names with get_cohorts first.

get_amp_session_replay_info