1Open Slashspace and go to Settings, then Connectors.
2On Discover, search for Amplitude MCP and click Connect.
3Sign in to Amplitude MCP in your browser. Slashspace updates when the account is connected.
Then ask for what you need in any Agent mode chat. Amplitude MCP is on in every chat unless you switch it off.
What your chats can do
48 tools from Amplitude MCP.
Create group typesCreate one or more group types in a project, OR add already-ingested group types with status "unexpected" to the tracking plan.
A group type is a category of group that users can belong to (for example "Company", "Account", "Team", "Workspace", "Organization"). The Amplitude Accounts add-on lets you analyse product usage at the group level rather than per individual user. NOTE: group TYPES are the categories themselves — use create_properties with propertyType "group" to add attributes (e.g. company name, plan tier) to an existing group type.
When a user says "create a group type" without further qualification, or "add to plan" for an unexpected group type, use this tool. Specify whether each item is unexpected with `isUnexpected`. If `isUnexpected` is true, the group type must already exist in the project as observed-but-unexpected and will be added to the tracking plan. If false (default), a brand-new entry is created.
INSTRUCTIONS:
- Use get_context to get available project IDs first.
- Use get_group_types to check which group types already exist before creating new ones.
- If the user has not specified a project, prompt the user to decide. Don't decide for them.
EXAMPLES:
- Minimal: {"projectId": "123456", "groupTypes": [{"name": "Company"}]}
- With description: {"projectId": "123456", "groupTypes": [{"name": "Team", "description": "Engineering teams within a company"}]}
- Mixed batch (one fresh, one add-to-plan, on a feature branch): {"projectId": "123456", "branchName": "marketing-edits", "groupTypes": [{"name": "Account"}, {"name": "Workspace", "isUnexpected": true}]}
# Response
Each input item is reported individually in `groupTypes[]` with a `result` of `"created"`, `"addedToPlan"`, or `"failed"` (with a `reason`). Partial successes are preserved: a failure on one item never discards the results of others in the same batch.
PERMISSIONS:
- This tool requires the "Update Tracking Plan" permission and may fail with a 403. Don't pre-warn the user; if it fails, surface the error and note that an admin may need to grant access.
# Workspace warnings
Be sure you have information on the workspace settings and environments from get_workspace_context before using this tool. If the workspace has more than one environment, warn the user that the change will apply across multiple environments. If the main branch is protected (workspace setting approvalWF is "Required"), let the user know that changes cannot be made on the default branch and they will have to first create a new branch and make changes on that.
NOTES:
- A group type with the same name cannot already exist on the targeted branch — that item will be marked as failed.
- Branch targeting: unless specified, the default branch is used. Pass either branchId or branchName, not both.
- `description` is only allowed on brand-new group types (isUnexpected: false). Unexpected items added to the plan cannot include metadata at the same time — add them first, then use a follow-up tool call to set the description.
USER-INTERFACING LANGUAGE:
When relaying results to the user, do not surface internal mechanics.
- Refer to the default branch as "main", not "default branch".
- Say "unexpected group types" not "isUnexpected group types".
- Say "added to the tracking plan" rather than using field names like "addedToPlan".
- Say "branch approval setting" not "approvalWF".
- Do not mention "mutations", "versionId", "stagingVersionId", "propertyPath", branch IDs, or GraphQL details to the user.
Create propertiesCreate one or more properties in a project's tracking plan. Use propertyType to select which kind of properties to create.
PROPERTY TYPES:
| propertyType | What it creates | Key params |
|---|---|---|
| event | Event properties (global or event-scoped) | properties[].eventType (omit for global) |
| user | User-level properties | properties[].type, regex, enumValues |
| group | Group properties (e.g., company_name, plan_tier) for a group type | groupType, properties[] |
INSTRUCTIONS:
- If a user says "create a property" without specifying a type, ask them to clarify which type they mean: event, user, or group.
- If a user says "create a property on an event," assume they mean an event property — propertyType "event" is the default for that phrasing.
- Derived properties, profile properties, lookup properties, computed properties, and persisted properties are NOT supported via MCP tools. If the user asks to create one of these, let them know that this property type is not currently supported through MCP tools.
- If the user has not specified a project, prompt them to decide. Don't decide for them.
PERMISSIONS:
- This tool requires the "Update Tracking Plan" permission and may fail with a 403. Don't pre-warn the user; if it fails, surface the error and note that an admin may need to grant access.
# Workspace warnings
Be sure you have information on the workspace settings and environments from get_workspace_context before using this tool. If the workspace has more than one environment, warn the user that the change will apply across multiple environments. If the main branch is protected (workspace setting approvalWF is "Required"), let the user know that changes cannot be made on the default branch and they will have to first create a new branch and make changes on that.
NOTES BY PROPERTY TYPE:
- group: Group properties describe attributes of a group type (e.g., company name, plan tier). Accepts a group type name (e.g., "org id", "Company") — the tool resolves it to the correct ID internally. If no branch is specified, defaults to the main branch.
EXAMPLES:
- Event property (global): { "propertyType": "event", "projectId": "123", "properties": [{ "name": "page_url", "type": "string" }] }
- Event property (event-scoped): { "propertyType": "event", "projectId": "123", "properties": [{ "name": "button_name", "eventType": "Button Clicked", "type": "string" }] }
- Event properties (mixed: one fresh, one add-to-plan, on a feature branch): { "propertyType": "event", "projectId": "123", "branchName": "marketing-edits", "properties": [{ "name": "page_url", "type": "string" }, { "name": "button_name", "eventType": "Button Clicked", "isUnexpected": true }] }
- User property: { "propertyType": "user", "projectId": "123", "properties": [{ "name": "plan_type", "type": "string" }] }
- Group properties: { "propertyType": "group", "projectId": "123", "groupType": "Company", "properties": [{ "name": "plan_tier", "type": "string" }] }
USER-INTERFACING LANGUAGE:
When relaying results to the user, do not surface internal mechanics.
- Refer to the default branch as "main", not "default branch".
- Say "event property", "user property", or "group property" not "propertyType".
- Say "unexpected" or "unplanned" not "isUnexpected" when describing properties not yet in the plan.
- Say "array type" not "isArrayType", "hidden" not "isHidden", "enum values" not "enumValues", and "classification" not "classifications".
- Say "branch approval setting" not "approvalWF".
- Do not mention "mutations", "versionId", "stagingVersionId", branch IDs, or GraphQL details to the user.
Delete event propertiesDelete one or more event properties in a project.
Each requested property is routed by whether eventType is provided:
- eventType provided → per-event delete (scoped to that one event):
- live on this event → marked as deleted on this event (restorable).
- planned on this event → the property-event link is removed on this event only (does NOT affect other events).
- unexpected on this event → added to the plan as deleted on this event.
- eventType omitted → plan-wide delete (across all events):
- live → marked as deleted (restorable).
- planned → removed entirely (NOT restorable; you'd have to recreate). Affects all events that used the property.
- unexpected → added to the plan as deleted.
A single call may mix both — each entry is routed independently. Amplitude-owned properties cannot be deleted.
# Before deleting
Before an event-property delete, pass includeDeleted: true when looking up which events are using the property so deleted attachments are also included.
# Warning
Marking an ingested event property as deleted stops ingestion until restored (immediately on main; after merge on other branches). A delete on a non-main tracking-plan branch does not drop live ingest until that branch is merged into main. Removing a planned property does not stop ingestion — it was never ingested. Always surface this to the user before they confirm.
# Confirmation
This is a destructive taxonomy mutation. Mark as deleted and remove both use the same confirmation gate — never skip it. The first call returns a confirmation_required response showing the bucketed actions, project, and branch; relay that and its warning field to the user. Only call again with confirmed: true after the user explicitly acknowledges. Do not pass confirmed: true on the first call.
# Branch targeting
Unless specified, the default branch is used. To apply changes to a non-default branch, pass either branchId or branchName. If the user references a branch by name (e.g. "my-edits-branch"), use branchName. Pass only one.
# Permissions
This tool requires the "Update Tracking Plan" permission and may fail with a 403. Don't pre-warn the user; if it fails, surface the error and note that an admin may need to grant access.
Delete user propertiesDelete one or more user properties in a project.
Properties that are planned and ingested are marked as deleted (restorable). Properties that are planned but never ingested are removed. Properties ingested but not in the plan are added to the plan as deleted. When a name exists as both customer and Amplitude, only the customer property is targeted.
# Warning
Marking ingested properties as deleted (toMarkAsDeleted) stops ingestion until restored (immediately on main; after merge on other branches). A delete on a non-main tracking-plan branch does not drop live ingest until that branch is merged into main. Removing planned properties (toRemove) does not stop ingestion — they were never ingested and cannot be restored. Always surface both buckets and this warning to the user before they confirm.
This tool only deletes customer-defined user properties. Amplitude-owned user properties cannot be deleted and are always skipped — tell the user if any were requested.
# Confirmation
This is a destructive taxonomy mutation. Mark as deleted and remove both use the same confirmation gate — never skip it. The first call returns a confirmation_required response listing the bucketed properties, project, and branch; relay that and its warning field to the user. Only call again with confirmed: true after they explicitly acknowledge. Do not pass confirmed: true on the first call.
# Branch targeting
Unless specified, the default branch is used. To apply changes to a non-default branch, pass either branchId or branchName. If the user references a branch by name (e.g. "my-edits-branch"), use branchName. Pass only one.
# Permissions
This tool requires the "Update Tracking Plan" permission and may fail with a 403. Don't pre-warn the user; if it fails, surface the error and note that an admin may need to grant access.
Get agent resultsRetrieve results from AI agents that have analyzed your dashboards or session replays.
This is NOT for searching dashboards, charts, or notebooks — use 'search' for that.
This is specifically for retrieving the AI-generated insights and analyses that agents produced.
This tool handles both searching for agent analyses and fetching full results in a single call.
MODES:
1. **Search mode** (no session_id): Search agent analyses with filters. Returns preview summaries.
2. **Direct fetch mode** (session_id provided): Fetch full artifact data for a specific session.
3. **Auto-expand**: If search returns exactly 1 session, full artifacts are included automatically.
SEARCH STRATEGY (important — follow this order):
1. If you have a specific session_id, use direct fetch mode.
2. For dashboard analyses, pass agent_params with dashboard_id (cheap exact-match).
3. For session replay insights, use agent_params with category and/or impact (cheap exact-match).
4. Use "query" ONLY for natural language / fuzzy search when exact filters aren't sufficient.
WHEN TO USE:
- "What are my dashboard agents?" → agent_type: dashboard_explorer
- "Show my agent results" → agent_type: dashboard_explorer (or session_replay_explorer)
- "What agents have I run?" → agent_type: dashboard_explorer
- "What analyses exist for dashboard xyz?" → agent_type: dashboard_explorer, agent_params: { dashboard_id: "xyz" }
- "Show me high-impact session replay insights" → agent_type: session_replay_explorer, agent_params: { impact: "High" }
- "Friction hotspots in the checkout flow" → agent_type: session_replay_explorer, agent_params: { category: "Friction Hotspots" }, query: "checkout flow"
- "What did the AI find about rage clicks?" → agent_type: session_replay_explorer, query: "rage clicks"
- "Any dashboard insights about revenue?" → agent_type: dashboard_explorer, query: "revenue"
- "Show me insights from last week" → agent_type: session_replay_explorer, created_after: "2026-03-16T00:00:00Z"
- "What did I analyze recently?" → agent_type: dashboard_explorer
DO NOT USE FOR:
- Finding or listing dashboards, charts, or notebooks → use 'search' instead
- Running new analyses or queries → use 'query_dataset' or 'query_charts' instead
- Creating dashboards → use 'create_dashboard' instead
RETURNS:
- Search mode: List of analysis sessions with preview summaries, URLs, and pagination info
- Direct fetch mode: Full artifact data for the session
- Links to view each session in the Amplitude UI are included
Get amplitude agent analytics infoSingle 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 chartsRead 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'.
Get amplitude contextUnified 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 amp session replay infoUnified 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 taxonomyRead a project's tracking plan: the events it defines, the properties on them, what a branch changes relative to main, and who changed what when.
# WHEN TO USE — answer questions like:
- "What events exist in project 12345?" → { action: "events", projectId: "12345" }
- "List the custom events" → { action: "events", kind: "custom", projectId }
- "Show custom and labeled events together" → { action: "events", kind: "all", projectId }
- "Which properties are on the Purchase event?" → { action: "properties", propertyType: "event", eventType: "Purchase", projectId }
- "Which events use button_name?" → { action: "properties", propertyType: "event", names: ["button_name"], projectId }
- "What user properties are tracked?" → { action: "properties", propertyType: "user", projectId }
- "What does branch feature/v2 change?" / "review this branch before merging" → { action: "branch_changes", branchName: "feature/v2", projectId }
- "What changed in the tracking plan last week?" / "who deleted that event?" → { action: "activity", since: "2026-09-01T00:00:00Z", projectId }
- Discovering valid event or property names before building a query_dataset filter or group_by
This is a fast schema lookup. Do NOT run query_dataset to discover which events or properties exist.
# DO NOT USE FOR:
- Metrics, counts, trends, funnels, retention → use 'query_dataset'
- Creating, updating or deleting taxonomy → use 'manage_amp_events' / 'manage_amp_properties'
ACTIONS:
| action | What it returns | Key params |
|---|---|---|
| events | Events in the tracking plan, with status and metadata. `kind` picks the surface: `event` (default, raw), `custom`, `labeled`, or `all` (custom + labeled together). | kind; raw: eventTypes, fields, includeDeleted, branchId/branchName; custom/labeled: customEventNames, customEventIds; both: limit, cursor |
| properties | Properties by surface. propertyType selects which: event, user, group, derived, lookup, channel, persisted. | propertyType, eventType, name, sources, groupTypes, names, fields, includeDeleted, includeHidden, includeBlocked, includeTransformations, branchId/branchName |
| branch_changes | What a branch adds, removes or updates vs main — events, properties, templates, group types. Use before approving or merging: review_branch reports only a count. `detail` adds per-field before/after; `detailFor` expands only the entities you name. | branchId/branchName, includeMainDrift, detail, detailFor |
| activity | Change history: who changed which taxonomy entity and when, newest first. Use for activity logs, "what changed since X", and per-person attribution. `detail` adds stored before/after values. | since, until, entityTypes, changeActions, loginIds, detail, limit, cursor, branchId/branchName |
INSTRUCTIONS:
- Use get_amplitude_context first to get project IDs. If the user has not specified a project, prompt them to decide.
- Raw events and custom/labeled events take different identifiers: `eventTypes` for raw, `customEventNames` / `customEventIds` for custom and labeled. Passing the wrong one is rejected rather than ignored.
- Only raw-event reads are branch-aware and take `fields`; custom and labeled events are neither branch-scoped nor field-projected.
- Where branch-aware, omit branchId/branchName for the default branch; otherwise pass exactly one selector.
- Event and property semantics are unchanged from the tools this replaces — same statuses, same transformation folding, same field projection via fields.
- activity reports current state nowhere: use it for "what changed", and events/properties for "what exists now".
- activity is NOT a complete audit of everything that changed — say so rather than implying it is. Custom, labeled and autotrack event edits deliberately write no activity record; transformations live in a separate service with no activity log; derived and computed properties are not tracking-plan entities; and newly ingested unexpected events and properties never appear (read `firstSeen` from an events or properties read instead). Passing entityTypes or changeActions narrows further, dropping changes whose activity type has no mapping — sources, tags, group types, and edits made through the API — so an unfiltered query is the only complete view.
- activity history belongs to the Data workspace, not the project, so every project sharing that workspace (its dev, staging and EU environments) returns the same rows. The response echoes workspaceId and branch — state that scope.
- branch_changes requires exactly one branch selector, and always reports a `comparison` field. "3-way" compares against the point the branch was cut and also returns `mainDrift` and `conflicts`; "2-way" is used when no review is open, may include changes main made after the branch was cut, and cannot report drift or conflicts. Relay that caveat rather than presenting a 2-way result as the branch's own edits.
Get amp user dataLook up Amplitude users. One tool with modes selected by `include` (default `profile`).
TWO KINDS OF "USER":
- Product users (default): people in project analytics data — use amplitudeId / userId / email / deviceId.
- Org teammates (`include='org'`): people with Amplitude login accounts in your org — emails for sharing charts/dashboards/notebooks.
PRODUCT LOOKUPS — identify with exactly one of:
- `amplitudeId` → exact lookup (fastest, no resolution step).
- `userId` → your product's user id; resolved to an amplitudeId first.
- `email` → resolved to an amplitudeId (most projects use the email as the user id; a fallback search covers the rest).
- `deviceId` → resolved via device-id match (anonymous / pre-login users).
- `amplitudeIds` → batch form (max 10); profile mode only.
OUTPUT MODES (`include`):
- `id` → 'resolve_user_id': resolve identifier to amplitudeId only.
- `profile` (default) → 'get_user_profile': identity, properties, groups, usage stats.
- `timeline` → 'get_user_timeline': recent event stream.
- `both` → profile + timeline.
- `org` → 'get_org_users': list org login emails/names for sharing. No product identifier or projectId needed. Pass returned `loginId` values to share tools.
INSTRUCTIONS:
- `projectId` is required for product modes (id/profile/timeline/both); omit it for `include='org'`.
- If a product identifier matches multiple users, the response lists candidates (status 'ambiguous') — re-call with `amplitudeId`.
- Experiment-prefixed properties/events are excluded by default; set `includeExperimentData` when debugging experiments.
DO NOT USE FOR:
- Enumerating product users who performed an event → use 'use_amplitude_cohorts' (action='find').
- Aggregate counts or trends → use 'query_dataset'.
- Org role / group / RBAC admin reads → use 'get_org_users' with the matching admin action.
Get data warehouse destinationsList the Data Warehouse export destinations configured for a project.
WHEN TO USE:
- You want to see where a project exports its data (Snowflake, BigQuery, S3, etc.), their type, status, and last-export timing.
- You need a destination's connection id to inspect its export jobs by passing that id to use_amplitude_data_connections (view: 'jobs', as dataSourceId) — or to get_data_warehouse_jobs if that standalone tool is available in this session.
- This is the export-side counterpart of the ingestion-source listing (which lists the import sources feeding the project).
INSTRUCTIONS:
- Provide the projectId (appId) to list all configured export destinations.
- Narrow the list with the optional `type` (matches `eventDestinationType` case-insensitively, whole value, so "SNOWFLAKE" does NOT match SNOWFLAKE_EXPORT_DATASHARE) and `enabled` filters instead of listing everything and scanning client-side. When either is set the response carries `filteredFrom`, the pre-filter count: an empty `destinations` with a non-zero `filteredFrom` means "none matched your filter", NOT "this project has no destinations". Report it that way.
- Each destination's `id` is a ready-to-use `falcon:{id}` — pass it as the dataSourceId to use_amplitude_data_connections (view: 'jobs'), or as the connectionId to the standalone get_data_warehouse_jobs tool if that is the one available, to see that destination's export jobs.
TIMING FIELDS (three different measurements — NOT three views of one job, and NOT reconcilable 1:1 with get_data_warehouse_jobs):
- latestSuccessfulJobStartTime / latestFailedJobStartTime: START (enqueue) time of the most recent successful/failed automatic job, INCLUDING successful runs that exported 0 rows. Format 'YYYY-MM-DD HH:MM:SS' with fractional seconds and no timezone (effectively UTC).
- latestExportCompletionTime: a data-export watermark — the COMPLETION time of the most recent successful run that actually exported data. Empty (0-row) successes and failures do NOT advance it, so it can legitimately lag latestSuccessfulJobStartTime by days or months when no new data has arrived. ISO-8601 with 'T' separator, no timezone designator (effectively UTC) — a different format from the two fields above.
- RECONCILIATION CAVEAT: get_data_warehouse_jobs hides successful export jobs that exported 0 rows, so a destination can show latestSuccessfulJobStartTime = today while get_data_warehouse_jobs returns no recent SUCCESS job for the same connection. That is expected, not a contradiction. Do not treat these fields as ground truth against the jobs list, and do not conclude from them alone that a data-bearing export ran recently — use latestExportCompletionTime together with the jobs list to confirm actual data delivery.
NOTES:
- Destinations only (exports); import/ingestion sources are listed separately.
- Two kinds of destination are returned. `falcon:{id}` supports job history; `gyrfalcon:{id}` (Snowflake CUSTOM_EVENTS / EVENT_TRANSFORMATIONS, Databricks) does NOT yet — asking for its jobs returns `supported: false`, which does NOT mean it never ran. Judge those on latestSuccessfulJobStartTime / latestFailedJobStartTime / `latestError` (present only on gyrfalcon rows with a recorded error; its absence elsewhere means the backend cannot report one, not that all is well).
- If `note` is present, part of the list could not be fetched — say so rather than reporting it as complete.
- Responses never include credential fields — only type, status, timing (see TIMING FIELDS), and count fields when Falcon has populated them (see COUNT FIELDS).
- COUNT FIELDS: `latestRowsUnloadedCount` / `latestResolvedUserCount` come from Falcon and are often unset. Null is omitted from the response (not a failure). For export row counts, inspect job history via use_amplitude_data_connections (view: 'jobs') or get_data_warehouse_jobs if that standalone tool is available — do not chase missing destination-level counts.
Get from urlRetrieve objects from Amplitude URLs
WHEN TO USE:
- CRITICAL: Only use this tool for full Amplitude app URLs on supported hosts (app.amplitude.com, app.eu.amplitude.com, apps.stag2.amplitude.com, local.amplitude.com)
- You have an Amplitude URL and want to get the full object definition
- User shares a link to a dashboard, chart, notebook, experiment, etc.
INSTRUCTIONS:
- Provide the full Amplitude URL (e.g., https://app.amplitude.com/analytics/myorg/chart/456 or https://app.eu.amplitude.com/analytics/myorg/chart/456)
- The tool will parse the URL, validate the organization, and return the full object
- Works with charts, dashboards, notebooks, experiments, flags, cohorts, metrics, and opportunities
- /chart/new/{id} URLs may refer to a chart draft or a temporary chart edit (from query tools); both are resolved automatically
- Agent session URLs (/agents/session/{id}) are not resolvable here — use get_agent_results with the session_id instead
Get group typesList available group types for a project. Group types are the categories of groups (e.g., "Company", "Team", "Account") — NOT the properties/attributes of those groups.
WHEN TO USE:
- Use this tool to discover what group types exist (e.g., "Company", "Team").
- Use get_properties with propertyType "group" instead if the user is generally asking for group properties (e.g., company_name, plan_tier).
NOTES:
- Returns group types from the latest staging version of the default branch.
Get session replay durationAPP SUPPORT ONLY. Do not call this tool from the LLM or agent.
The session replay app calls this tool to hydrate replay duration metadata without downloading the full replay. Prefer list_session_replays, get_session_replays, get_session_replay_events, or render_amp_session_replay for user-facing tasks.
APP INSTRUCTIONS:
- Provide projectId and sessionReplayId in "<device_id>/<session_id>" format (as returned by list_session_replays / get_session_replays).
- Returns durationMs: last event timestamp minus first event timestamp.
- Returns null durationMs for empty or single-frame recordings.
Get session replay streamAPP SUPPORT ONLY. Do not call this tool from the LLM or agent.
The session replay app calls this tool to stream rrweb events for inline playback. The response is base64-encoded gzipped NDJSON and is not useful for text reasoning.
If you need to understand what happened in a replay, use get_session_replay_events instead.
APP INSTRUCTIONS:
- First call: pass projectId + sessionReplayId. Response includes durationMs, events (file 0), and nextCursor.
- Continue with nextCursor until it is null.
- For duration-only hydration, pass metadataOnly: true.
Get session replay timelineAPP SUPPORT ONLY. Do not call this tool from the LLM or agent. The session replay app calls this tool to hydrate the events panel and user identities. Use get_amp_session_replay_info (action timeline) for user-facing tasks.
Get tracking plan sourcesList the sources configured on a project's tracking plan (e.g. iOS, Android, Web, Server).
WHEN TO USE:
- You need source IDs before adding sources to an event in the tracking plan.
- The user asks what sources are configured on their tracking plan.
INSTRUCTIONS:
- Pass projectId.
- Returns each source's id and name. Use the id when modifying event sources.
NOTES:
- The Sources UI merges tracking-plan labels with pipeline connections, but this tool returns only the tracking-plan catalog (id + name) for assigning sources to events. Use get_data_ingestion_sources for ingestion status, volumes, and warehouse/import connections.
Get transformationsRetrieve data transformations from a project. Transformations are data cleaning operations that merge events, merge properties, or map property values.
WHEN TO USE:
- Use this tool to see what transformations are configured for a project.
- Use this tool to understand how events or properties are being merged or remapped.
- Use this tool to audit data cleaning rules applied to a project.
WHAT IT RETURNS:
- A list of transformations with their type, name, description, and configuration details.
- Transform types include: merge (merge events), merge_events_derived_prop (merge events with derived property), merge_event_properties, merge_user_properties, map_event_property_values, map_user_property_values.
INSTRUCTIONS:
- Get the project ID from the context tool.
- Optionally filter by transform type to narrow results.
- Use pagination to retrieve large lists of transformations.
Manage amp contextManage AI context. Actions: `set_org_context` and `set_project_context` replace customer AI context. Use `get_amplitude_context` to read your current org, projects, and context.
Manage amp entitiesCreate a shared (team) space, rename a space or change its members, or move charts, dashboards, notebooks, or cohorts into a shared space. Opens a confirmation card the user approves. Selected by `route`.
ROUTES:
- `create_space`: create a new shared space. Opens a compact form prefilled with the proposed name and members (`spaceName`, `members`).
- `manage_space`: update an existing shared space's name, description, or members. Requires `spaceId`.
- `move_to_space`: move charts, dashboards, notebooks, or cohorts into an existing shared space. Renders a destination picker over the entities you pass.
- `search_members`, `validate_confirmation`, and `commit`: reserved for the confirmation card. Do not call them yourself.
SPACE MANAGEMENT:
- This is the only tool for creating, updating, or moving content into shared spaces.
- If the needed destination does not exist, use `create_space` first. Do not create a destination inside `move_to_space`.
INSTRUCTIONS:
- For `move_to_space`, prefer `objects` and pass each entity's id plus the display name already established in the conversation or source tool output. This is especially important for unnamed chart edits: preserve the useful name you gave the chart instead of showing "Untitled chart". Do not use one title for multiple objects.
- Resolve entity ids with `search_amp_entities`, or pass chart edit ids straight from `query_amplitude_data`. `objectIds` and `objectId` remain compatibility fallbacks when no display name is available.
- `objectType` is optional for charts (saved vs unsaved is detected from the id) and required for dashboards, notebooks, and cohorts.
- Set `title` to a short line explaining why the app opened, in the user's own words.
- Nothing is written when a launch route returns. The user confirms in the app, which applies the change and reports back.
DO NOT USE FOR:
- Archiving flags or cohorts: no archive route exists yet.
- Sharing individual charts or dashboards, or org invites: use `share_amp_entities`.
Manage amp eventsWrite to a project's tracking-plan events — raw ingested events, custom events, and labeled (autotrack) events — in one tool selected by `action` + `kind`. Reading events lives in `get_amp_taxonomy`.
KINDS:
- `event` (default): raw ingested / planned event types in the tracking plan (Purchase, Page Viewed, …). Identified by `eventTypes`.
- `custom`: virtual events composed of one or more raw source events with optional filters (`isAutotrack=false`). Identified by `customEventNames` / `customEventIds`.
- `labeled`: autotrack / labeled events (`isAutotrack=true`). Same identifiers as custom. Update and delete — MCP cannot create labeled events.
ACTION + KIND MATRIX (key params per combo):
- create + event → `events: [{ name, isUnexpected, … }]` (isUnexpected: true adds an already-ingested unexpected event to the plan; false creates a brand-new planned event)
- create + custom → `name` + `definition` (raw source events)
- update + event → maps keyed by exact raw event `name` (`descriptions`, `newNames`, `categories`, `sources`, `tags`, `visibility`, `owners`, …)
- update + custom|labeled → maps keyed by id / display name / ce:<name> (`descriptions`, `newNames`, `categories`, `isOfficial`, `eventDefinitions`)
- delete + event → `eventTypes`; mark as deleted (ingested) / removed (planned); two-step with `confirmed`
- delete + custom|labeled → `customEventNames` / `customEventIds`; permanently removed (same as UI); two-step with `confirmed`
- restore + event only → `eventTypes` (custom/labeled cannot be restored)
COMMON MISTAKES (seen in production — avoid these):
- Using `eventTypes` with kind custom/labeled, or `customEventNames` with kind event. Raw events → `eventTypes`; custom/labeled → `customEventNames`/`customEventIds`.
- Sending `kind: "all"`. It is no longer a valid kind here — it only ever meant "custom and labeled together" on a read. Use `get_amp_taxonomy` (`action: events`) to read both, or pick `custom` or `labeled` for a write.
- Omitting `action`. It is required now; it used to default to `get`, which no longer exists on this tool.
- Putting `ce:<name>` values in a custom event `definition` — source events must be raw event types; custom events cannot nest, and labeled events as sources are not supported yet.
- create + event failing with "name already exists": the event was likely already ingested (unexpected) — retry with `isUnexpected: true` to add it to the plan instead.
- Setting `description`/`category`/`isOfficial` on an event with `isUnexpected: true` — add to plan first, then update.
- update + event on events not yet in the tracking plan — only planned/live events can be updated; add unexpected events to the plan first.
- Creating a custom event whose definition duplicates an existing one — the API rejects duplicates and returns the existing event; reuse it instead.
HOW TO FIND THE EVENTS YOU ARE ABOUT TO CHANGE:
1. Discover names with `search` (`entityTypes: ["EVENT"]` or `["CUSTOM_EVENT"]`). That is the primary path.
2. Hydrate them with `get_amp_taxonomy` (`action: events`) before writing — it returns status, category, activity, visibility, and ingestion timestamps, and confirms the exact name to key update maps by.
DELETE / RESTORE:
- For kind:event, delete is a two-step confirmation gate for every target — mark as deleted and remove alike. Never skip confirmation.
- Marking as deleted stops ingestion immediately on main; on any other tracking-plan branch, ingest is unchanged until merge. Removing a planned event does not stop ingestion (the event was never ingested).
- Restore: on main, ingestion resumes immediately; on any other branch, the restore is staged until merge. Only events that were marked as deleted can be restored; removed planned events must be recreated.
- Custom/labeled delete is permanent and does not use this branch-ingest rule.
TYPICAL FLOWS:
- Add raw events on a branch: manage_amp_taxonomy create_branch (if main protected) → create with kind event + branchName → update metadata as needed.
- Build a custom event: get_amp_taxonomy for the raw source events → create with kind custom + definition (source events).
- Delete raw events (not custom/labeled): delete with kind event (confirmation_required first), then confirmed: true after the user acknowledges the buckets and branch. Ingested events are marked as deleted (restorable); planned events are removed (not restorable).
- Permanently remove a custom/labeled event: delete with kind custom|labeled + customEventNames/Ids (confirmation_required first), then confirmed: true. Cannot be restored.
- Restore a deleted raw (not custom/labeled) event: get_amp_taxonomy with `action: events` + `includeDeleted: true` to find it, then restore with its exact `eventTypes`.
PROJECT ID:
- Pass numeric `projectId`. Get it from `get_amplitude_context` if needed.
- If omitted and the user has exactly one accessible project, that project is used automatically.
DO NOT USE FOR:
- Reading events → `get_amp_taxonomy` (`action: events`)
- Fuzzy discovery → `search`
- Properties → `manage_amp_properties` (writes) / `get_amp_taxonomy` (reads)
- Branch governance → `manage_amp_taxonomy` (or legacy branch tools)
Manage amp taxonomyRead Data workspace governance settings and manage tracking-plan branches for a project. One tool selected by `action` (default `get`).
TYPICAL FLOW (most common production path):
1. `get` first — learn `mainProtected`, naming conventions, approval workflow, and environments before changing the plan.
2. If `mainProtected` is true (or the user wants an isolated change), `create_branch` — do not mutate main. Optionally `get` again / check `branches` first so you do not recreate an existing name.
3. Apply tracking-plan edits with the taxonomy mutation tools (`create_events`, `create_properties`, `update_event`, …) and pass `branchName` / `branchId` to target that branch — those tools are separate from this one.
4. Finish with `merge_branch` (two-step `confirmed`) when the user wants changes on main, or `delete_branch` (two-step `confirmed`) to abandon. Many sessions stop after step 3 with work left on the feature branch — that is normal.
5. Less common: `refresh_branch` (pull main into the feature branch; two-step), `review_branch` (approve/unapprove when approvals are required), `update_branch` (description only).
ACTIONS:
- `get` (default): workspace settings + environments + branches in one response. Includes `mainProtected` (true when approvalWF is "Required" — changes must go on a feature branch, not main) and `workflowHint`.
- `create_branch`: create a branch off main. Requires `name`.
- `update_branch`: update a branch description (not name). Requires `branchName` or `branchId` + `description`.
- `delete_branch`: delete a non-main branch. Two-step: call once, then again with `confirmed: true` after the user acknowledges.
- `merge_branch`: merge a feature branch into main. Two-step with `confirmed`. If approvals are required and missing, reports status instead of merging.
- `refresh_branch`: pull latest main into a feature branch. Two-step with `confirmed`; conflicts overwrite the feature-branch version.
- `review_branch`: approve or unapprove a branch for merge. Pass `reviewDecision` ("approve" | "unapprove"). Prefer after the branch has pending changes — empty branches cannot be approved.
PROJECT ID:
- Pass numeric `projectId` (e.g. "123456"). Get it from `get_amplitude_context` if you do not already have one.
- If omitted and the user has exactly one accessible project, that project is used automatically.
- Do not invent project ids. Do not use project names.
DO NOT USE FOR:
- General org/user/project discovery → `get_amplitude_context`
- Creating or updating events/properties → the taxonomy mutation tools (`create_events`, `create_properties`, …) with `branchName` when on a feature branch
- Listing events/properties → `get_events` / `get_properties`
Query amplitude dataRun 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:
- 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 event/property names with 'search' (or search_amp_data_taxonomy) — never guess them.
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
- 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
- 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.
Rename chartRename 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
Render amplitude chartRender 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.
Render amp session replayRender an interactive session replay player UI for one or more session replays. This is the ONLY way to actually show a session replay to the user — text descriptions are not a substitute.
WHEN TO USE (call this tool whenever the user wants to SEE a replay):
- Any user request with a viewing verb: "show me", "render", "play", "watch", "let me see", "pull up", "open", "display", "view", "I want to see", "can I see" + "session replay(s)" / "session(s)" / "recording(s)" / "the replay" / "those sessions".
- Any time the user asks to look at, observe, or visually inspect session activity, even without an explicit verb (e.g. "the session for jane@acme.com", "that recording", "those replays from yesterday").
- Immediately after a session replay search returns replay IDs in response to such a request — chain directly into render_amp_session_replay with the returned IDs. Do NOT stop at listing IDs in text when the user asked to see the replays.
- If the user asks to see replays but you don't have IDs yet, FIRST find them with the session replay search tool available to you (`get_amp_session_replay_info`, else `get_session_replays` / `list_session_replays`), THEN call this tool with the results — in the same turn.
- Call ONCE with a list of IDs to render multiple replays the user can switch between — do NOT call this tool separately per replay.
WHEN NOT TO USE:
- The user is asking for a count, summary, or analysis of replay events without wanting to watch them ("how many replays…", "what did the user do in…", "summarize…"). Use the timeline / events tools instead.
INSTRUCTIONS:
- Provide projectId and one or more sessionReplayIds.
- sessionReplayId format is "<device_id>/<session_id>" (e.g. "0c650142-4a68-4f82-ad6a-4f154fee5265/1773235450374") — use the ids returned from the search/list tools verbatim.
- This tool is an MCP App: it ships the player manifest through structuredContent/_meta, so hosts treat it as a UI render rather than a data read.
- Maximum 20 IDs per call. The UI hydrates the rrweb player on demand for each replay.
- Set `title` to a short, human-readable summary of WHY you're rendering these replays based on the user's request (3–8 words). This is shown as the heading above the player. Examples: "Recent web sessions for nvidia.com", "Sessions where users hit checkout errors", "Top 3 longest sessions yesterday". Do NOT echo IDs or device info — that lives in the player itself. If the user gave no specific framing, omit `title`.
EXAMPLES:
- Single replay: { "projectId": "678910", "sessionReplayIds": ["0c650142-4a68-4f82-ad6a-4f154fee5265/1773235450374"], "title": "Most recent session for jane@acme.com" }
- Multiple replays: { "projectId": "678910", "sessionReplayIds": ["abc/111", "def/222"], "title": "Sessions where users abandoned checkout" }
- No framing context: { "projectId": "678910", "sessionReplayIds": ["abc/111"] }
NOTES:
- The UI plays the replay inline (rrweb-based) with a tree-style event list — the model does NOT need to summarize that data in text.
- This tool is UI-only. Do not rely on its response for reasoning about the replays.
Restore event propertiesRestore event properties that were previously marked as deleted in a project.
Each requested property is routed by whether eventType is provided:
- eventType provided → per-event restore: restore the property on that specific event only.
- eventType omitted → plan-wide restore: restore the property across the tracking plan.
A single call may mix both — each entry is routed independently. Amplitude-owned properties cannot be restored (they cannot be deleted in the first place).
# Note
On the main branch, ingestion for a restored event property resumes immediately. On any other branch, the restore is staged on that branch and only takes effect on ingestion once the branch is merged into main. Always warn the user about this.
# Branch targeting
Unless specified, the default branch is used. To apply changes to a non-default branch, pass either branchId or branchName. If the user references a branch by name (e.g. "my-edits-branch"), use branchName. Pass only one.
# Permissions
This tool requires the "Update Tracking Plan" permission and may fail with a 403. Don't pre-warn the user; if it fails, surface the error and note that an admin may need to grant access.
# Caveats
Properties that were removed (planned but never ingested at the time of deletion) cannot be restored — they have to be recreated via create_properties. Only properties that were marked as deleted can be restored.
Restore user propertiesRestore user properties that were previously marked as deleted in a project.
# Note
On the main branch, ingestion for a restored user property resumes immediately — incoming data with this property will be accepted again as soon as the restore succeeds. On any other branch, the restore is staged on that branch and only takes effect on ingestion once the branch is merged into main. Always warn the user about this.
This tool only restores customer-defined user properties. Amplitude-owned user properties cannot be restored and are always skipped — tell the user if any were requested. When a name exists as both customer and Amplitude, only the customer property is targeted.
# Branch targeting
Unless specified, the default branch is used. To apply changes to a non-default branch, pass either branchId or branchName. If the user references a branch by name (e.g. "my-edits-branch"), use branchName. Pass only one.
# Permissions
This tool requires the "Update Tracking Plan" permission and may fail with a 403. Don't pre-warn the user; if it fails, surface the error and note that an admin may need to grant access.
# Caveats
Properties that were removed (planned but never ingested at the time of deletion) cannot be restored — they have to be recreated via create_properties. Only properties that were marked as deleted can be restored.
Save chart editsPromote 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
Search amp data taxonomySemantic search over a project's data taxonomy: discover events, properties, and property values by describing what you're looking for in natural language. Batches many searches into ONE call.
INSTRUCTIONS:
- Use get_amplitude_context FIRST to get the projectId.
- Batch your entire discovery plan into a single call (one search per concept, up to 16) instead of calling this tool repeatedly.
- Populate each search based on its kind:
- "events": set 'description' to one event concept (e.g. "user completes a purchase").
- "properties": set 'descriptions' to 1-2 concise phrasings of the property (e.g. ["subscription plan", "pricing tier"]).
- "property_values": set 'propertyName' to the EXACT property name (find it with a "properties" search first); set 'eventType' when it is an event property.
- Per-search 'limit' is 1-50 hits (default 10). Raise it only for broad concepts where the default may miss the right entity; larger limits cost context.
USING THE RESULTS:
- Results come back in the same order as the input searches. A failed search returns an 'error' entry without failing the others.
- Hits are semantically ranked; the top hit is not guaranteed to be correct. Use the returned names EXACTLY as spelled — never guess variants.
- An 'ambiguity' block on a result means several hits scored similar confidence — surface those candidates and ask which the user means rather than silently picking one, whenever the choice is load-bearing for the answer.
- Reason from whatever extra signal a hit carries instead of taking rank 1 on faith: 'query_volume' (how often the org actually queries it) is the strongest tiebreaker between similar names, 'last_seen' exposes stale or deprecated entities, and a property's 'scope' (event vs. user vs. group) decides where a filter belongs.
- Report taxonomy quality problems back to the user — near-duplicate events for one concept, several casing variants of the same value, hits with no recent volume, or an 'ambiguity' block you had to guess past. Say which one you picked and why. These are fixable data issues, and staying silent means every later answer quietly inherits the same ambiguity.
- 'detail' controls response verbosity — pick the cheapest level that answers the question:
- "compact" (default): names, descriptions, ranking hints only — cheapest, right for most lookups.
- "stats": adds usage/recency metrics per hit. 'volume' (+ *_30d/*_180d) = ingested event counts; 'query_volume' = how often the org uses it in charts/queries (the strongest tiebreaker between similar hits); 'first_seen'/'last_seen' = recency (an old last_seen means stale/deprecated — avoid building new analyses on it).
- "full": nothing stripped (tags, category, importance scores, all stats) — most tokens, only when you need governance metadata.
- Need just one or two stat fields? Stay on "compact" and name them in 'extraFields' (e.g. ["query_volume"]) — cheaper than "stats" or "full".
- Use 'maxResponseChars' to hard-cap the payload when context is tight; results are truncated per search so every search stays represented.
EXAMPLES:
- Ground a funnel: {"projectId": "123456", "searches": [{"kind": "events", "description": "user signs up"}, {"kind": "events", "description": "user completes checkout"}]}
- Find a property then its values: {"projectId": "123456", "searches": [{"kind": "properties", "descriptions": ["subscription plan"]}]} then {"projectId": "123456", "searches": [{"kind": "property_values", "propertyName": "plan_type", "eventType": "Subscription Started"}]}
- Rank by usage: {"projectId": "123456", "searches": [{"kind": "events", "description": "purchase"}], "detail": "stats"}
- Compact but keep one stat: {"projectId": "123456", "searches": [{"kind": "events", "description": "purchase"}], "extraFields": ["query_volume"]}
- Tight context budget: {"projectId": "123456", "searches": [{"kind": "events", "description": "purchase"}], "maxResponseChars": 4000}
NOTES:
- Hits are already ranked by a hybrid of semantic and keyword search — a single ranking, not two lists to reconcile.
- 'source' says which backend served the batch. 'langley' is the normal path. 'unisearch_fallback' means that backend was unreachable, so results are keyword-only and lower quality; the response carries a 'degradedReason', the fallback cannot serve 'property_values' searches, and it ignores 'detail' and 'extraFields' (always compact hits). Treat a fallback answer as provisional and say so when it materially affects your conclusion.
Search amp entitiesSearch for dashboards, charts, notebooks, experiments, docs, and other content in Amplitude.
INSTRUCTIONS:
- Use this as your primary tool to discover and explore available analytics content before diving into specific analyses.
- If you are not sure what to search for, use the default search query.
- Do not specify appIds/projectIds in the input unless the user explicitly asks to search within a specific app/project.
- To search Amplitude's official product documentation (SDK setup guides, API reference, help articles), include 'AMPLITUDE_DOCS' in entityTypes. This searches the public docs corpus — NOT your org's content — and returns doc pages with browsable URLs. Pair it with a natural-language query (e.g. "how to track revenue in the browser SDK").
DO NOT USE FOR:
- AI agent results, agent analyses, or agent runs → use 'get_agent_results' instead
- Getting full dashboard definitions with chart details → use 'get_dashboard' with the IDs from search results
- Running queries or analysis → use 'query_dataset' or 'query_charts'
ADDITIONAL INFORMATION:
- Results are personalized to the user you are making the request on behalf of.
- Results do not include the full object definition. You will need to use other tools to get the full object definition when needed.
- Best practice is to query for a single entity type, unless the user's request is open ended.
- The response includes an isOfficial flag in contentMeta to identify content that has been marked as official by the organization.
Share amp entitiesManage sharing and org invites for Amplitude entities. One outcome-based tool selected by `action`.
ACTIONS:
- `get`: list owners/viewers for a CHART / DASHBOARD / NOTEBOOK / COHORT (`objectId` + `objectType`).
- `share`: add users as viewers (`userIds` or singular `userId`). Existing editors are not downgraded.
- `update_role`: set one user's role to CAN_EDIT / CAN_VIEW / NOT_ADDED (`userId` + `shareRole`).
- `invite`: invite people to the org by email (optional chart access at invite time). Requires org role Manager or higher.
INSTRUCTIONS:
- Resolve object IDs with `search_amp_entities` first. Object types are uppercase enums (not "space").
- Resolve recipients with `get_amp_user_data` include=`org`. Pass returned `loginId` emails as recipients. If the user did not name a teammate, ask for an email instead of guessing.
- Prefer `update_role` with CAN_EDIT to promote a viewer to editor; `share` only adds viewers.
- Callers need edit access on the object to share or change roles.
DO NOT USE FOR:
- Creating a shared space, renaming it, changing space members, or moving content into a space: use `manage_amp_entities`.
- Comments on objects: use `use_amp_comments`.
- Product analytics end-user lookup: use `get_amp_user_data` with include id/profile/timeline.
Track ui render responseInternal telemetry tool used by MCP UI components to report render latency and errors.
NOT FOR DIRECT MODEL USE.
Update propertiesUpdate property description, isOfficial, category, and/or name in a project's tracking plan. Use propertyType to select which kind of properties to update.
This tool CANNOT be used to update property visibility or type. It can also NOT be used to set event properties to required.
PROPERTY TYPES:
| propertyType | What it updates | Key params |
|---|---|---|
| event | Event property metadata (global or event-scoped) | metadataScope, eventType (when scope is "event") |
| user | User property metadata | descriptions, isOfficial, categories, newNames |
INSTRUCTIONS:
- Use get_properties first to verify property names and status before updating.
- Call this tool only after the user has explicitly confirmed the properties to change and the exact new values.
- Do not auto-apply speculative or inferred changes.
- If the user has not specified a project, prompt them to decide. Don't decide for them.
- This tool requires the "Update Tracking Plan" permission. If it fails with 403, note that an admin may need to grant access.
- Make sure you have used the get_workspace_context tool to get information on workspace settings and environments for specified projectId. If there is more than one environment in the workspace, warn the user that the change will apply across multiple environments. If the workspace has main branch protected (indicated by approvalWF being "Required"), let the user know that changes cannot be made on the default branch and they will have to first create a new branch and make changes on that.
- This tool only updates properties that are already in the tracking plan (status: planned, live, blocked). Unexpected properties (auto-detected from ingested data, isPlanned: false) are skipped. To edit an unexpected property's metadata, first add it to the plan with create_properties by setting properties[].isUnexpected: true on that item, then call update_properties.
WHEN UPDATING EVENT PROPERTIES:
- Do not try to update the properties globally if it failed on the event-scoped update, or vice-versa. Always confirm with the user whether the event property should be updated on a global or event-scoped basis.
WHEN UPDATING USER PROPERTIES:
- Remove the gp: prefix, if present, from user property names when requesting updates with this tool.
EXAMPLES:
- Event properties (global): { "propertyType": "event", "projectId": "123", "metadataScope": "global", "descriptions": { "revenue": "USD amount" } }
- Event properties (event-scoped): { "propertyType": "event", "projectId": "123", "metadataScope": "event", "eventType": "Purchase", "descriptions": { "line_items": "JSON array" } }
- User properties: { "propertyType": "user", "projectId": "123", "descriptions": { "plan_tier": "Customer subscription tier" } }
Use amp ai visibilityUse Amplitude AI Visibility.
Set `action`:
- `list_brands`: list tracked brands and get orgBrandId. Start here when the brand is unknown.
- `read`: read a brand using orgBrandId plus `view`: scores, scores_over_time, reports, topics, prompts, prompt_responses, competitors, aliases, models, pages, sentiment, or sources.
- `update_page_view_config`: set a project's page-view event, referrer property, and page-URL property.
Use amp commentsRead 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 dashboardsRead 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.
- `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 experimentsUnified entry point for experiments: read, analyze, create, and set metrics. Replaces get_experiments, query_experiment, create_experiment, and update_experiment.
ACTIONS:
- `get` (default): fetch experiments by `ids`.
- `analyze`: run experiment analysis for `id` (same as query_experiment). Omit metricIds unless the user asks for specific/secondary metrics.
- `create`: create an experiment across projects (same fields as create_experiment).
- `update`: replace experiment metrics (`experimentId` + `metrics`). For name/variants/testers/deployments/links on an experiment, use `use_amp_flags` action `update` — experiments are flags.
INSTRUCTIONS:
- Resolve experiment IDs with `search` (entityTypes: ["EXPERIMENT"]) before get/analyze/update.
- Resolve deployment IDs with `use_amp_flags` action `list_deployments` before passing `deploymentIds`.
- Resolve metric IDs with `use_amplitude_metrics` before passing `metrics` or `projectMetrics`.
- On `create`, strongly prefer setting `proxyExposureEvent` to the event where users hit the tested surface. Without it, pre-launch planning falls back to Any Active Event and can wildly overstate the required duration.
- ALWAYS reference queried experiments by their Amplitude link in analyses.
- Metrics for `update` fully replace the existing set; create metrics first via `use_amplitude_metrics`.
DO NOT USE FOR:
- Feature flags → `use_amp_flags`.
- Metric definitions → `use_amplitude_metrics`.
- Chart / dataset queries → chart query tools.
Use amp flagsUnified 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.
- `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. 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`.
Use amp guides surveysList Guides and Surveys or get one by ID. Use `action: "list"` for filtered discovery and rollout summaries; use `action: "get"` for full content, targeting, variants, steps, and rollout details. Both require `projectId`; get also requires `nudgeId`.
Use amplitude ai feedbackRead Amplitude AI Feedback (customer VoC) for a project — surveys, support tickets, app reviews, and grouped themes.
This is CUSTOMER product feedback (what users said in connected sources). NOT for:
- AI/LLM agent session quality, transcripts, or agent analytics → use get_amplitude_agent_analytics_info
- Reporting that you (the agent) are stuck → use report_agent_feedback (requires user approval)
Set `facet` to choose what to read:
- `sources` → connected feedback integrations + sourceIds (call first when you need sourceIds for filters)
- `comments` → raw feedback comments with search, categories, pagination
- `insights` → grouped themes (requests, complaints, loved features, …) sorted by popularity
- `mentions` → drill into comments behind ONE insightId or trendId (do not call for every insight)
- `trends` → saved themes tracked over time
TYPICAL WORKFLOWS:
1. Bootstrap: facet=sources → facet=comments or facet=insights
2. Themes: facet=insights → facet=mentions with insightId when user asks for examples
3. Tracked themes: facet=trends → facet=mentions with trendId
EXAMPLES:
- Connected sources: {"facet": "sources", "projectId": "123456"}
- Complaints this month: {"facet": "insights", "projectId": "123456", "types": ["complaint"], "dateStart": "2026-06-01", "dateEnd": "2026-06-30"}
- What are customers saying about pricing: {"facet": "comments", "projectId": "123456", "search": ["pricing", "price"]}
- Show comments behind insight 42: {"facet": "mentions", "projectId": "123456", "insightId": 42}
Use amplitude chart monitorsRead 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'.
Use amplitude cohortsWork with Amplitude cohorts end to end. One tool with eleven 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.
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'.
Use amplitude data connectionsUnified entry point for everything to do with a project's data connections — ingestion sources, import/export job history, Snowflake credentials, live Snowflake warehouse browsing, and Amplitude import-config recommendations. Replaces 10 previously separate tools (get_data_ingestion_sources, get_data_source_details, get_data_warehouse_jobs, get_data_warehouse_health, get_falcon_integrations, get_snowflake_warehouse_databases/_schemas/_tables/_columns/_rows, recommend_falcon_import_config).
ROUTES (action='read', selected by `view`):
- omit `dataSourceId` and `view` → list every configured source for the project ('data_connections.list (get_data_ingestion_sources)'). Start here.
- `dataSourceId` set, `view` omitted or 'summary' → detail for that one source ('data_connections.summary (get_data_source_details)').
- `view: 'connections'` → list the project's Snowflake credentials/integrations ('data_connections.connections (get_falcon_integrations)'). Use this to find an `integrationId` for the browsing views below.
- `view: 'jobs'` → import/export batch job history for one connection ('data_connections.jobs (get_data_warehouse_jobs)'). Requires `dataSourceId` in `vacuum:{id}` / `falcon:{id}` / `gyrfalcon:{id}` form (as returned by the list route; `gyrfalcon:` answers `supported: false` — no per-run history yet, not "never ran"); auto-resolved when the project has exactly one configured source.
- `view: 'health'` → project-wide health of EVERY import and export connection in one call ('data_connections.health (get_data_warehouse_health)'): which are failing, degraded, running, healthy, idle or unknown, worst first, with last-success age per connection. No `dataSourceId`. Optional `direction` (imports or exports only), `since` (failure-counting window, default 7 days) and `maxConnections`. Use this instead of listing sources and destinations and then calling 'jobs' per connection.
- `view: 'databases' | 'schemas' | 'tables' | 'columns' | 'rows'` → live Snowflake warehouse browsing, one drill-down level at a time ('data_connections.databases (get_snowflake_warehouse_databases)' etc.). Needs a connection reference (`integrationId` or `sourceDestinationId`) — auto-resolved via 'connections' when the project has exactly one Snowflake credential. Snowflake-only today; other warehouse types will extend this enum, not rename the tool.
ROUTES (action='recommend_import'):
- Generates a heuristic Amplitude import config + ready-to-run SQL for one or more warehouse tables ('data_connections.recommend_import (recommend_falcon_import_config)'). This is the ONLY correct way to produce warehouse-import SQL — never hand-write it.
WHEN TO USE:
- Anything about "what's sending data into my project", "did this import/export succeed", "are any of my pipelines failing / is anything broken or stale" (that is 'health'), "what Snowflake credentials/connections exist", "what's in my Snowflake warehouse", or "generate an import config/SQL for this table".
INSTRUCTIONS:
- Always provide `projectId`.
- Prefer omitting `dataSourceId`/connection refs on the first call in a session — this tool auto-resolves the connection when there's exactly one, and only asks you to disambiguate when there are several.
- For 'jobs', pass the prefixed `dataSourceId` from the list route (e.g. `vacuum:42`, `falcon:abc-123`, `gyrfalcon:c-9`) — not a bare numeric id.
- For 'health', omit `dataSourceId`; it inspects every connection. If the response says `truncated: true`, raise `maxConnections` or narrow with `direction` before concluding the project is healthy.
- For browsing views, drill down one level per call: 'databases' → 'schemas' (needs `database`) → 'tables' (needs `database`+`schema`) → 'columns'/'rows' (needs a read-only `sql` SELECT).
- For 'recommend_import', provide `tables` (fully qualified dotted names) and either `sourceDestinationId` (preferred — lets Amplitude introspect the warehouse; NOT the same id as `integrationId` from 'connections') or `warehouseKind` for a dry run with caller-supplied `columns`/`sampleRows`.
EXAMPLES:
- List sources: { "projectId": "123456" }
- Job history: { "projectId": "123456", "view": "jobs", "dataSourceId": "vacuum:42" }
- Health of every connection: { "projectId": "123456", "view": "health" }
- Browse tables: { "projectId": "123456", "view": "tables", "database": "ANALYTICS", "schema": "PUBLIC" }
- Recommend import: { "projectId": "123456", "action": "recommend_import", "sourceDestinationId": "789", "tables": [{"fullyQualifiedName": "ANALYTICS.PUBLIC.EVENTS"}] }
NOTES:
- Sensitive credential fields are never returned; empty strings stand in for secrets.
- Databricks/BigQuery/GA4 warehouse-native browsing isn't implemented yet — only classic Snowflake. `recommend_import` returns a `WAREHOUSE_NOT_SUPPORTED_YET` error for other kinds; surface it without retrying.
Use amplitude metricsUnified entry point for metric definitions, goals, and goal alerts in a project. Replaces get_metrics, create_metric, update_metric, delete_metric, get_metric_goals, the five goal write tools, and the four goal-alert CRUD tools.
WHEN TO USE:
- Anything about defining metrics, setting targets on metrics, listing goals/pacing, or configuring goal alerts.
- NOT for querying metric *values* over time — use query_metric or query_dataset instead.
INSTRUCTIONS:
- Select the operation with `action`.
- Metric defs: resolve metricIds with search first; create_metric needs projectId, name, and metricType plus type-specific fields (same rules as the legacy create_metric tool).
- Goals: use get_goals to discover goalIds before update / archive / restore / delete / alert actions.
- update_metric may be two-step when changing a metric definition with dependents; delete_metric and delete_goal may also be two-step when dependents exist. For any of these operations, first call without confirmed, show the returned dependency payload to the user, then retry with confirmed: true only after user confirmation.
- get_goals accepts either metricId OR projectId, not both.
DO NOT USE FOR:
- Chart or experiment metric *values* → query_metric / query_dataset.
- Experiments and flags → get_experiments / get_flags / create_experiment.
Use amp notebooksRead and manage Amplitude notebooks. One outcome-based tool selected by `action`.
ACTIONS:
- `get`: read notebooks by `notebookIds` (or singular `notebookId`). Resolve IDs with `search_amp_entities` (entityTypes: NOTEBOOK).
- `create`: create a notebook with `name` + `rows`. Chart cells accept saved chart IDs and temporary chart edit IDs interchangeably in `chartId`; edit IDs are saved as permanent charts automatically.
- `edit`: update name and/or one layout edit. Call get first and pass its `lastModifiedAt` as `expectedLastModifiedAt`. Rows accept edit IDs the same way `create` does — use this to add a freshly queried chart to an existing notebook.
ROW ITEMS:
- Types: `chart`, `rich_text` (markdown content), `session_replay`, `video`, `image`, `cohort`. Use `rich_text`, not `markdown`.
- Width 3–12 columns per item; row total ≤ 12; max 4 items per row.
DO NOT USE FOR:
- Finding notebooks by name: use `search`.
- Creating a shared space, changing space members, or moving an existing notebook into a space: use `manage_amp_entities`.
- Sharing / comments: use `share_amp_entities` / `use_amp_comments`.
Use amp skillLoad 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.
