Amplitude EU

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

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: - 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 the 'search' tool to find if there are charts with properties that relate to the data you want to query. 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_event_properties' tool 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 - 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 search/get_charts/get_properties/get_event_properties before querying Supported chart types: eventsSegmentation, funnels, metricExplorer, retention, revenueLtv, sessions, stickiness RESPONSE FORMAT: Returns {isCsvResponse: bool, csvResponse or jsonResponse, definition}. Only ONE response type present. 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 - 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".

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: - Use the search tool to find the ID of the metric you want to query. - Use this tool to query the metric. RESPONSE FORMAT: Returns {isCsvResponse: bool, csvResponse or jsonResponse, definition}. Only ONE response type present. 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 - 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".

query_metric

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_dataset - these are temporary IDs that cannot be added to dashboards - DO NOT use the editId from query_dataset responses - you must first call save_chart_edits to get a permanent chartId - The typical workflow is: query_dataset (returns editId) → save_chart_edits (converts editId to permanent chartId) → create_dashboard (uses chartId) - If you use an editId instead of a saved chartId, the dashboard creation will fail with "NotFoundError: No chart" INSTRUCTIONS: - Provide a descriptive name for the dashboard - 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

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, and project-level AI context. 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. DO NOT USE FOR: - Running analytics queries → use 'query_dataset'. - Finding charts/dashboards/cohorts → use 'search'.

get_amplitude_context

Retrieve chart alert anomalies for a project or for one specific chart. WHEN TO USE: - The user wants recent chart alerts, anomalies, or alert notifications. - Use chartId to scope to one chart. - Use get_chart_monitor when the user wants monitor configuration or subscribers instead of alert history. INSTRUCTIONS: - chartId is optional. If provided, projectId is not needed. - For project-wide alerts, projectId is optional only when the user has access to exactly one project. If multiple projects are accessible, provide projectId. - includeUnseen filters to alerts the current user has not marked as seen. - limit defaults to 20 and is capped at 100. EXAMPLES: - {"projectId":"12345"} - {"chartId":"abc123","limit":10} - {"projectId":"12345","includeUnseen":true} NOTES: - This tool returns alert anomalies, not monitor configuration. - Alerts are returned newest first.

get_chart_alerts

Get the parameter schema, valid enum values, and a working example for a specific chart type. WHEN TO USE: - Before calling query_dataset, to understand the correct parameter schema for a chart type. - When you need to know valid enum values (e.g., funnel modes, segmentation metrics). - When you need a working example definition to use as a template. INSTRUCTIONS: - Call this tool with the chart type you want to build a definition for. - Use the returned schema to construct a valid definition object. - Pass the constructed definition to query_dataset. - If the chart type is not yet supported, construct the definition based on existing chart examples from search/get_charts. SUPPORTED CHART TYPES: eventsSegmentation, funnels, metricExplorer, retention, revenueLtv, sessions, stickiness

get_chart_definition_params

Retrieve the current monitor configuration and subscribers for a chart. WHEN TO USE: - The user wants to inspect a chart alert monitor before changing it. - Use this before subscribe_chart_alert if you need the monitorId or current subscriber list. - Use get_chart_alerts if the user wants alert anomalies instead of monitor settings. INSTRUCTIONS: - Provide chartId. - Returns the monitor ID, enabled state, conditions, email recipients, and channel subscriptions. EXAMPLES: - {"chartId":"abc123"} NOTES: - This only works for charts that already have a monitor.

get_chart_monitor