Amplitude

Tools 47

• Get Amplitude Charts

  Read saved Amplitude charts by ID, or look up the chart-type schema. One tool with five output modes selected by `include` (default `link`). OUTPUT MODES: - `link` (default) → 'get_chart_link': validates each id exists, then returns the chart's URL(s). Does not run the chart — cheap id lookup only. - `typed` → 'lower_chart': returns the chart as typed UI-shaped parameters (`kind` + events/where/group_by/…) — the same shape `query_amplitude_data`'s `chart` parameter accepts. Prefer this when creating a variant of an existing chart or preparing a modification: edit the typed object, then call `query_amplitude_data` with `chart` (+ `chartId` to fork/modify the saved chart). - `definition` → 'get_charts': returns the full raw Amplitude definition object(s). Use when `typed` cannot lower the chart (advanced features) or you need fields the typed model does not cover. - `data` → 'query_charts': runs the chart(s) and returns the result data. Use when you need the numbers. - `guide` → 'get_chart_definition_params': no ids needed. Pass `chartType` to get that type's parameter schema, valid enum values, and a working example definition — use BEFORE calling `query_amplitude_data` if you are unsure of the shape, or to look up valid enum values (e.g. funnel modes, segmentation metrics). Omit `chartType` to list all supported chart types. NOTE: This schema describes chart STRUCTURE only (params, enums, example) — it does NOT validate event or property names against your project's taxonomy. An unrecognized event/property key will NOT error; it silently returns a chart with empty data. Before building, confirm exact spelling via 'search', 'get_properties' (propertyType="event"), or get_amplitude_charts include='definition' on a similar existing chart — never guess a key name. PREREQUISITES (required): - For `link` / `typed` / `definition` / `data`: you MUST have at least one concrete `chartIds` or `chartEditIds` entry. Do not call speculatively. Resolve ids FIRST via `search` (by name), `get_from_url` (from a chart link), or `query_amplitude_data` (for ad-hoc analysis, which returns a chart edit id). - For `guide`: no ids required; `chartType` is optional (omit to list all supported types). INSTRUCTIONS: - Create a new chart: `search` (taxonomy) → build typed `chart` → `query_amplitude_data`. - Modify / fork a saved chart: `search` (find chart) → `get_amplitude_charts include='typed'` → edit the returned `chart` → `query_amplitude_data` with that `chart` and `chartId` set to the saved chart id. - Saved charts → `chartIds`. Chart edits (links ending in /chart/new/<edit_id> or /chart/<chart_id>/edit/<edit_id>) → `chartEditIds`. - `typed` and `definition` modes support `chartIds` only. For a chart edit's data use `data` mode. - `data` mode accepts up to 3 ids/edits combined. - The data params (`groupByLimit`, `excludeIncompleteDatapoints`, `timeSeriesLimit`) only apply when `include = 'data'`. `chartType` only applies when `include = 'guide'`. DO NOT USE FOR: - Ad-hoc analysis without a saved chart → use 'query_amplitude_data'. - Finding charts by name → use 'search'.

• Query Amplitude Data

  Run analytics queries to answer data questions about users, events, funnels, and retention — and to create or modify charts via the typed `chart` parameter. PREFERRED: pass the typed `chart` parameter (segmentation | funnel | retention | sessions | data_table). It is a small, UI-shaped model (events, where, group_by, measured_as, segments, date_range) that is deterministically compiled server-side into a validated chart definition — compile errors come back with a fix-oriented hint, so you never need to hand-build raw definition JSON. FALLBACK: pass a raw `definition` only for chart types the typed model does not cover (composition, revenueLtv) or advanced params the typed model has no field for. Raw definitions are validated inline; on failure the response includes chartTypeSchema with the parameter schema, valid enums, a working example, and coercion rules. Provide exactly one of `chart` or `definition`. # 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?" - "Create a chart…" / "Modify chart X to…" - 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`). Chart queries cannot serve them. - Finding existing charts/dashboards → use 'search' or 'get_amplitude_charts' instead - Project settings (timezone, currency) → use 'get_amplitude_context' with projectId instead # STRATEGIES 1. Discover the exact event name with 'get_events', then query directly. For semantic/fuzzy taxonomy lookup (you know the concept, not the exact name), use 'search' or 'search_amp_data_taxonomy'. Use event-scoped property discovery only when the requested analysis actually needs a filter or group-by property — never page the project-wide property catalogue after a query error. 2. Create: build the typed `chart` (events + date_range required; add where/group_by/segments as asked) → call this tool. 3. Modify / fork a saved chart: `search` to find the chart id → `get_amplitude_charts include='typed'` → edit the returned `chart` → call this tool with that `chart` AND `chartId` set to the saved chart id (links the edit to the parent; parent params fill gaps the typed model omits — including `date_range`, which may be left out to keep the parent's window). 4. Call query_amplitude_data — compile and validation errors are actionable; fix the named field and retry. 5. To show the result visually, call 'render_amplitude_chart' with the returned chartEditId. # GENERAL GUIDELINES - Read saved metric definitions with get_metrics or use_amplitude_metrics action="get_metrics" before building a chart from them. - Don't guess event or property names — discover them first, and use the exact name and scope returned. - ALWAYS set a descriptive "name" (becomes the chart title) and an explicit date_range (except when modifying with chartId and the parent's window should be kept). - Relative date_range windows support an Offset suffix for day-over-day / historical comparisons: "Last 0 Days Offset 1" (yesterday), "Last 0 Days Offset 7" (same day last week), "Last 7 Days Offset 7" (the prior week). - On errors, follow the hint in the message; the compiler names the offending field. Chart types supported by raw `definition`: 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. 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 BOTH chartConfig (Highcharts) AND jsonResponse with joinable band data. - 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.

• Render Amplitude Chart

  Render an interactive Amplitude chart UI for a saved chart or a chart edit by ID. This is the way to SHOW a chart to the user — it spins up the chart widget; the widget fetches the chart's data itself and draws it. ## SUPPORTED CHART TYPES eventsSegmentation, funnels, retention, metricExplorer. - dataTableV2 CANNOT be rendered in the chart widget. Present query results directly instead. ## WHEN TO USE - The user wants to SEE a chart and you already have a `chartId` (saved chart) or `chartEditId` (ad-hoc chart edit). - Right after `query_dataset` returns a `chartEditId` for a non-empty result — pass that `chartEditId` here to render it. - Right after `search` / `get_from_url` resolves a saved `chartId` the user asked to see. ## WHEN NOT TO USE — DO NOT CALL WITHOUT AN ID - You do NOT have a `chartId` or `chartEditId` yet. Resolve one FIRST: - `query_dataset` (returns a `chartEditId` for an ad-hoc definition) - `search` with `entityTypes: ["CHART"]` (finds a saved `chartId`) - `get_from_url` (parses an id out of an Amplitude chart URL) - The query you ran returned empty / all-zero data — tell the user, do NOT render an empty chart. ## INSTRUCTIONS - Provide exactly one of `chartId` (saved chart) or `chartEditId` (chart edit). If you have both, prefer `chartEditId`. - When rendering a chart edit from `query_dataset`, pass its returned `title` so the widget displays the requested chart title. - This tool does NOT return chart data to you — it only renders the widget. To reason about the numbers, call `get_amplitude_charts` (include='data') / `query_dataset` for the data.

• Use Amplitude Chart Monitors

  Read and manage chart alert monitors. One tool with eight actions selected by `action` (default `get_alerts`). ACTIONS: - `get_alerts` (default) → recent alert anomalies for a chart (`chartId`) or project (`projectId`). - `list` → custom chart monitors you created or are subscribed to (email / Slack / Teams). Includes ones others created if you are a recipient. Chart name + short summary + alertsLast30Days. Optional `projectId`. Does not need `chartId`. - `get_config` → a chart's monitor configuration + subscribers when `chartId` is set. Omit `chartId` to list (same as `list`). Charts with no monitor return hasMonitor=false — then use `create`. - `create` → add a monitor on a chart that does not have one. Requires `chartId`. Defaults to smart anomaly detection (99% CI, above or below) and emails the current user. - `history` → audit trail of monitor config changes (who changed what, when). Requires `monitorId` or `chartId`. Not alert firings — use `get_alerts` for those. - `subscribe` / `unsubscribe` → add/remove an alert subscription (email for the current user, or a Slack/Teams channel). Requires `monitorId` and `deliveryMethod`. - `update` → enable or disable a monitor. Requires `monitorId` and `enabled`. INSTRUCTIONS: - If the user asks what chart alerts or monitors they have, call `list` (or `get_config` without chartId). That returns monitors they created or are subscribed to — not every monitor in the org. - If `get_config` returns hasMonitor=false, call `create` with that `chartId` instead of telling the user to use the Amplitude UI. - Resolve a `monitorId` first with `get_config` (from a `chartId`) before `subscribe` / `unsubscribe` / `update`. For `history`, you may pass `chartId` directly instead of `monitorId`. - For `get_alerts` and `list`, `projectId` is optional when you have access to exactly one project; otherwise provide it to scope. Pass `chartId` to scope `get_alerts` to one chart. - Email subscriptions only manage the current user; for Slack/Teams pass `deliveryChannel` (and `deliveryWorkspaceId` when needed). DO NOT USE FOR: - Reading chart data → use 'get_amplitude_charts' (include='data') or 'query_dataset'.

• Save Chart Edits

  Promote chart edits to saved charts — Save as (new chartId) or Save in place (same chartId). WHEN TO USE: - You have a chartEditId from query_amplitude_data and need a permanent chartId - The user asked to update an existing chart and keep the same chartId / links MODES (per item in charts[]): - **Save as** (default): omit chartId → creates a new unpublished chart in personal space - **Save in place**: chartId + expectedLastModified → overwrites that chart (same chartId; updates all dashboards/notebooks referencing it) → ONLY when the user explicitly asked to update the existing chart — never infer from context → Requires a two-step confirm flow (probe, then confirm) — see workflow below WORKFLOW — save as new: 1. query_amplitude_data → chartEditId 2. save_chart_edits({ charts: [{ editId, name }] }) 3. Use returned chartId in dashboards/notebooks WORKFLOW — update existing chart (two-step — always confirm with the user): 1. get_amplitude_charts({ chartIds, include: "definition" }) → lastModified 2. query_amplitude_data({ chart, chartId }) → chartEditId 3. **Probe** (no confirm flags): save_chart_edits({ charts: [{ editId, name, chartId, expectedLastModified }] }) → returns overwriteImpact (chart name, URL, dashboards, published status) → present this to the user and ask whether to update in place or save as new 4. **Confirm** (only if user explicitly wants in-place): re-call with confirmOverwrite: true → if requiresSharedChartConfirmation, also add confirmSharedImpact: true after user reviews sharedChartImpact IMPORTANT: - Never set confirmOverwrite on the first in-place call — the probe response exists so you can double-check with the user - Default to save-as-new unless the user clearly wants the same chartId updated - Having chartId from a URL or prior query does NOT mean in-place save is allowed - Save-as-new charts default to unpublished in your personal space until a human publishes - To collaborate on save-as-new, pass destination {"kind":"space","spaceId":"..."} using a space id from the user or a shared-space URL. You must have permission to add to that space. To create a space or move already-saved charts, use manage_amp_entities - The response echoes where charts landed in savedTo (kind, spaceName, published, notified). Report that to the user rather than assuming the requested destination was used - In-place save requires edit access, matching edit provenance, and a fresh expectedLastModified (409 conflict if stale) - Prefer save in place when the user explicitly asks to update a chart others reference; use save as for new analyses

• Rename Chart

  Rename a chart that has already been saved WHEN TO USE: - A chart was saved (e.g. via save_chart_edits) and the user wants a different name on that same chart IMPORTANT: - Updates the existing chart in place and records a version-history entry; it does not create a copy - Requires edit access to the chart and write access to its project - To save a new chart from an ad-hoc edit, use save_chart_edits instead

• Use Amplitude Cohorts

  Work with Amplitude cohorts end to end. One tool with twelve actions selected by `action` (default `list`). DISCOVER & READ: - `list` (default) → browse/search the project's cohorts by name (`projectId` required, optional `query`). Use this FIRST when you don't have cohort ids — never guess or use placeholder ids. - `get` → full cohort definitions/metadata for known ids (`cohortIds`, max 50). - `find` → ad-hoc audience: individual users who performed an event (`projectId`; optional `event`, defaults to any active user; optional `timeRange`, `limit`). Returns user records + session replays, without creating a cohort. - `membership` → is a user in these cohorts? (`cohortIds` max 5 + one of `amplitudeId` / `userId` / `email`). CREATE: - `create` → save a new cohort (`projectId`, `name`, `definition`). Definition uses andClauses/orClauses condition sets. - `create_from_set_ids` → microscope drill-down from chart point set IDs (`projectId`, `setIds`, `microscopeCohortType`, optional `chartId` / `chartEditId`). Creates a cohort and returns a sample of users. Set IDs come from a chart widget "View users" action — never guess them. SYNC & EXPORT: - `get_destinations` → configured sync destinations for a project (`projectId`). Call BEFORE `sync`. - `get_syncs` → sync jobs + status (`projectId` for the whole project, or `cohortIds`). - `get_history` → execution logs for one cohort's syncs (`cohortId`, `projectId`, `target`). - `sync` → trigger a one-time sync now (`cohortId` + `targetId` from get_destinations; `partner` too for classic integrations). Two-step confirm: first call returns a preview, re-call with `confirmed: true`. Cohorts under 10k sync synchronously; 10k+ return `submitted` — tell the user it was queued, then poll `get_history`. - `export_submit` → start a CSV export of members (`cohortId`), returns `exportRequestId`. - `export_download` → poll export status / fetch CSV url (`cohortId` + `exportRequestId`). INSTRUCTIONS: - Resolve cohort ids with `list` before `get`/`membership`/`sync`/`export_*`. - For `sync`: always call `get_destinations` first — a targetId is only unique within a partner. - `membership` accepts `userId`/`email` directly (resolved to an amplitudeId automatically, cached). DO NOT USE FOR: - Aggregate counts/trends over a cohort → use 'query_dataset' with a cohort segment filter. - One user's profile or event timeline → use 'get_amp_user_data'.

• Get Amplitude Context

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

• Use Amp Skill

  Load an Amplitude skill — a workflow playbook describing the optimal sequence of Amplitude tools for a task. Consult a skill BEFORE improvising a multi-step Amplitude workflow (analysis, chart or dashboard creation, experiment review, replay debugging, instrumentation). Actions: - list: every available skill with its description. Use to browse what exists, or to find the name of the skill you want. - get: exact skill name or skill:// URI → that skill's full instructions.

• Use Amp Dashboards

  Read and manage Amplitude dashboards. One outcome-based tool selected by `action`. ACTIONS: - `get`: read up to three dashboards by `dashboardIds`. Resolve IDs with `search_amp_entities` (entityTypes: DASHBOARD). - `create`: create a dashboard. Row items accept saved chart IDs and temporary chart edit IDs interchangeably in `chartId`; edit IDs are saved as permanent charts automatically before the dashboard is created. Optionally pass `chartEdits` to control the saved name and description of each edit. If the events the user asked about are not instrumented, explain the gap and confirm before building a proxy dashboard from substitute events. Never pass placeholder or invented chart IDs. - `edit`: update dashboard metadata or layout. Read the dashboard first and pass its `lastModified` as `expectedLastModified`. Rows in `set_rows` / `update_row` / `insert_row` accept saved chart IDs and temporary chart edit IDs interchangeably, same as `create` — use this to add a freshly queried chart to an existing dashboard. Optionally pass `chartEdits` to control the saved name and description of edit IDs referenced by the layout edit. Pass `dryRun: true` to preview without saving — no chart edits are promoted and no dashboard change is applied. - `replace_properties`: discover or replace chart properties across a dashboard. - `subscribe` / `edit_subscription`: create or edit a recurring email, Slack, or Teams dashboard delivery. SUBSCRIPTIONS: - Use top-level `notificationType`, `sendWeek`, `sendDay`, and `sendHourUtc`; do not send nested JSON strings. - For email, `email` defaults to the current user; never ask the user for their own email address. For Slack or Teams, provide `recipientType` and `recipientId`; Teams also needs `recipientTeamId`. - If the user has not given a delivery channel or cadence, ask instead of assuming defaults. DO NOT USE FOR: - Finding dashboards by name: use `search`. - Creating a shared space, changing space members, or moving an existing dashboard into a space: use `manage_amp_entities`. - Creating or querying chart data: use the chart tools.

• Use Amp Comments

  Read and add plain-text comments on Amplitude charts, dashboards, and notebooks. One outcome-based tool selected by `action`. ACTIONS: - `get`: read comments for `source` + `id`. Dashboards/notebooks also roll up comments from charts inside them. - `add`: leave a plain-text comment (`content`). Prefixed with the AI client name automatically. INSTRUCTIONS: - `source`, `id`, and `projectId` are required on every call. Resolve the object with `search_amp_entities`, then pass its id as `id` with source CHART, DASHBOARD, or NOTEBOOK. `projectId` comes from `get_amplitude_context`. - Call get before add to avoid duplicates. - Comments are plain text only (no mentions/reactions). DO NOT USE FOR: - Opportunity / Wave comments: use opportunity tools. - Sharing access: use `share_amp_entities`.

• Use Amp Flags

  Unified entry point for feature flags and deployments. Replaces get_flags, create_flags, update_flag, and get_deployments. ACTIONS: - `get` (default): fetch flags by `flagIds` (numeric IDs or flag keys). - `create`: create one or more flags (`flags` array — same shape as create_flags). Supports evaluationMode, bucketingKey, percentage, rolloutWeights, targetSegments, testers, deploymentIds, tags (attached in a follow-up update after creation). - `update`: update a flag or experiment (`flagId` + only the fields to change). Supports flagConfig (name/description/enabled), evaluationMode, bucketingKey, percentage, rolloutWeights, targetSegments, variants, testers, deployments, links, tags (add/remove by name, not a full replace). Experiments are flags — use this for shell/rollout changes on experiments too. - `list_deployments`: list deployments (API keys) for the current project. Deployments are shared by flags and experiments — this is the only place to list them. INSTRUCTIONS: - Resolve IDs with `search` (entityTypes: ["FLAG"] or ["EXPERIMENT"]) before get/update. - Use `list_deployments` before create/update when associating deployment IDs. - Only include update sections you intend to change. - evaluationMode is "local" or "remote"; bucketingKey is "user_id", "device_id", or "amplitude_id". - For update rollout: `percentage` / `rolloutWeights` apply to "All Other Users"; omit `targetSegments` to keep existing conditional segments, pass `[]` to clear them, or pass a full array to replace them. - To GA a flag: `{"action":"update","flagId":"...","percentage":100,"rolloutWeights":{"on":1}}` (optionally `"targetSegments":[]` to drop prior segments). DO NOT USE FOR: - Experiment analysis → `use_amp_experiments` action `analyze`. - Attaching experiment metrics → `use_amp_experiments` action `update`. - Creating experiments → `use_amp_experiments` action `create`.