Create a new cohort with the provided definition and configuration.

WHEN TO USE:

• You need to create a new audience segment based on user behavior or properties

• You want to save a cohort definition for reuse in charts, experiments, or other analyses

• You need to create a cohort from specific conditions like events, user properties, or funnels

LEARNING FROM EXISTING COHORTS:

• Before creating a cohort, use the "search" MCP tool to find relevant cohorts by name/description, then use get_cohorts with those IDs to analyze existing cohort definitions and structure

• Study the structure and patterns of existing cohort definitions to understand the correct payload format

• Pay attention to how different condition types (event, user_property, other_cohort, etc.) are structured

• Learn from the andClauses/orClauses patterns and how they combine different conditions

• Use existing cohorts as templates for similar use cases to ensure proper schema compliance

EXAMPLES:

• Create an event-based cohort (users who performed a specific event >= 1 time in the past 30 days): { "app_id": "365742", "name": "xuan-simple-event-cohort", "definition": { "version": 3, "andClauses": [{ "negated": false, "orClauses": [{ "type": "event", // Condition type: event-based "metric": null, // No specific metric aggregation "offset": 0, // No time offset from the base time range "group_by": [], // No grouping/segmentation by event properties "interval": 1, // Time granularity: 1 = DAY (daily buckets) "operator": ">=", // Event count operator: greater than or equal "time_type": "rolling", // Rolling time window (last N days from now) "time_value": 30, // Time range: 30 units of the interval (30 days) "type_value": "xuan-test-httpapi-event-type", // The specific event name to match "operator_value": 1, // Minimum event count threshold: >= 1 occurrence "exclude_current_interval": false // Include events from the current day }] }], "cohortType": "UNIQUES", // Count unique users (not event occurrences) "countGroup": {"name": "User", "is_computed": false}, // Group by User entities "referenceFrameTimeParams": {} // No additional time frame parameters }, "type": "redshift", // Cohort computation engine type (optional - defaults to "redshift") "published": true // Make cohort discoverable to others } // EXPLANATION: This creates a cohort of users who performed the event "xuan-test-httpapi-event-type" // at least once in the last 30 days. The interval=1 means we evaluate this on a daily basis, // so the system looks at each day in the past 30 days to see if the user performed the event.

• Create a complex cohort with multiple conditions (organizations in another cohort OR new active, AND performed an event): { "app_id": "365742", "name": "xuan-test", "definition": { "version": 3, "andClauses": [{ // First AND condition group "negated": false, "orClauses": [{ // First OR condition: existing cohort membership "type": "other_cohort", // Condition type: reference to another cohort "offset": 0, // No time offset "interval": 1, // Time granularity: 1 = DAY (daily evaluation) "time_type": "rolling", // Rolling time window (last N days) "time_value": 365, // Time range: 365 days (1 year lookback) "cohort_keys": ["rs4d2xg5"], // Reference to cohort ID "rs4d2xg5" "exclude_current_interval": false // Include current day in evaluation }, { // Second OR condition: new/active users "type": "new_active", // Condition type: new or active user status "offset": 0, // No time offset "interval": 1, // Time granularity: 1 = DAY (daily buckets) "time_type": "absolute", // Absolute time range (specific dates) "time_value": [1760572800, 1761955199], // Unix timestamps: specific date range "type_value": "new", // Filter for "new" users (vs "active") "exclude_current_interval": false // Include current day }] }, { // Second AND condition group "negated": false, "orClauses": [{ // Event-based condition "type": "event", // Condition type: event-based "metric": null, // No specific metric aggregation "offset": 0, // No time offset "group_by": [], // No event property grouping "interval": 1, // Time granularity: 1 = DAY (daily buckets) "operator": ">=", // Event count operator: greater than or equal "time_type": "rolling", // Rolling time window (last N days) "time_value": 30, // Time range: 30 days "type_value": "test event", // Event name to match "operator_value": 1, // Minimum event count: >= 1 occurrence "exclude_current_interval": false // Include current day }] }], "cohortType": "UNIQUES", // Count unique organizations (not occurrences) "countGroup": {"name": "org id", "is_computed": false}, // Group by Organization entities "referenceFrameTimeParams": {} // No additional time frame parameters }, "type": "redshift", // Cohort computation engine type (optional - defaults to "redshift") "published": true // Make cohort discoverable to others } // EXPLANATION: This creates a complex cohort using boolean logic: // (Organizations in cohort "rs4d2xg5" in the last 365 days OR new users in the specified date range) // AND (Organizations that performed "test event" >= 1 time in the last 30 days) // // The interval=1 in all conditions means daily granularity: // - Cohort membership is checked daily over 365 days // - New user status is evaluated daily within the absolute date range // - Event occurrences are counted daily over the last 30 days // // Note: This cohort counts organizations (org id) rather than individual users.

Create a new experiment across one or more projects.

INSTRUCTIONS:

• If the user has not specified projects, prompt them to decide which projects to use

• Creates a feature A/B test with control and treatment variants

• Creates the same experiment in each specified project

• Returns the experiment IDs and URLs for viewing in Amplitude

EXAMPLES:

• Basic A/B test: Provide projectIds, key, and name

• Multiple projects: Provide array of projectIds to create experiment in each

• With custom variants: Provide projectIds, key, name, and variants array

NOTES:

• Experiment keys must be unique within each project

• Variants default to 'control' and 'treatment' if not specified

Retrieve full chart objects by their IDs using the chart service directly

WHEN TO USE:

• You want to retrieve a full chart definition.

• Useful if you want to base an ad hoc query dataset analysis on an exsiting chart.

INSTRUCTIONS:

• Use the search tool to find the IDs of charts you want to retrieve, then call this tool with the IDs.

Get detailed information about specific cohorts by their IDs.

WHEN TO USE:

• You want to retrieve full cohort definitions after finding them via search.

• You need detailed cohort information including definition, metadata, and audience details.

INSTRUCTIONS:

• Use the search tool to find the IDs of cohorts you want to retrieve, then call this tool with the IDs.

• This returns full cohort objects with all details, unlike the search tool which returns summary information.

Get context information about the current user, org, and projects.

Get specific dashboards and all their charts

WHEN TO USE:

• You want to retrieve full dashboard definitions including chart IDs that you can query and analyze individually.

INSTRUCTIONS:

• Use the search tool to find the IDs of dashboards you want to retrieve, then call this tool with the IDs.

• Very commonly you will want to query the charts after retrieving a dashboard.

Retrieve all deployments for the current project. Deployments are api keys for flags and experiments.

Retrieve event properties for a specific event type from a project. This tool provides a concise way to get all properties associated with a particular event.

WHEN TO USE:

• You want to get all properties associated with a particular event with the EXACT event type.

INSTRUCTIONS:

• Search for the exact event type you want to get properties for using the search tool or the get_events tool.

• Use this tool to get all event properties associated with a particular event.

Retrieve specific experiments by their IDs.

WHEN TO USE:

• You want to retrieve addition information for experiments like state, decisions, etc.

INSTRUCTIONS:

• Use the search tool to find the IDs of experiments you want to retrieve, then call this tool with the IDs.

Get feedback comments for a project with optional filtering and pagination.

WHEN TO USE:

• You want to retrieve raw feedback comments from various sources (surveys, support tickets, app reviews).

• You need to see the actual customer feedback text and metadata.

• You want to analyze comments with optional filters before they are grouped into insights.

• You need to search for specific feedback or paginate through results.

INSTRUCTIONS:

• Provide the projectId (appId) to retrieve comments.

• To get available sourceId values, first call get_feedback_sources with the projectId.

• Provide sourceId to filter comments from a specific feedback source.

• Use search parameter to filter comments by body text (searches within comment content).

• Use page and pageSize parameters for pagination (defaults: page=1, pageSize=20).

• Returns a list of comments with metadata including totalCount for pagination.

• Each comment includes the feedback text, source information, and associated metadata.

Get feedback insights (processed and grouped themes) for a project with optional filtering and pagination.

WHAT ARE INSIGHTS:

• Insights are derived from mentions in feedback comments. Insights represent processed and grouped themes extracted from feedback comments.

• The 8 types of insights are: feature requests (request), complaints (complaint), loved features (lovedFeature), brands mentioned (competitor), bugs (bug), feature mentions (mentionedFeature), pain points (painPoint), and key takeaways (takeaway).

SORTING AND FILTERING:

• Results are sorted by popularity (mention count), NOT by creation date. The tool cannot sort by when insights were created.

• dateStart and dateEnd filter to insights with feedback comments within the date range.

DRILLING DEEPER:

• Present the deep dive details to the user to help them understand the insight better.

• If a user asks for more details on a specific insight, use get_feedback_mentions with the insightId to see the actual user feedback.

• Do NOT call get_feedback_mentions for every insight - only when explicitly requested.

DIFFERENCE FROM GET_FEEDBACK_COMMENTS TOOL:

• Insights are processed and grouped themes, while comments are raw individual feedback from a feedback source.

• Use insights to understand themes and trends, use comments to see individual feedback.

Get feedback mentions (user feedback comments associated with an insight) for a specific insight.

PREREQUISITE: You MUST call get_feedback_insights first to obtain an insightId before using this tool.

WHAT ARE MENTIONS:

• Mentions are the individual user feedback comments that contributed to a specific insight.

• Each mention represents a piece of feedback from a user (survey response, support ticket, app review, etc).

WHEN TO USE:

• ONLY after a user asks for more details or wants to see the actual feedback behind a specific insight.

• Do NOT call this tool for every insight - only when the user specifically requests to drill down.

REQUIRED PARAMETERS:

• insightId: The ID of the insight (from get_feedback_insights response)

• All filter parameters (dateStart, dateEnd, sourceIds, ampId) should match what was used in the get_feedback_insights query to ensure consistent results.

Get feedback sources (connected feedback integrations) for a project.

WHEN TO USE:

• You want to retrieve the list of feedback sources/integrations configured for a project.

• You need to understand which feedback channels (e.g., surveys, support tickets, app reviews) are connected.

• You need sourceId values to filter feedback comments by specific sources.

• You want to see metadata about feedback sources before analyzing comments.

INSTRUCTIONS:

• Provide the projectId (appId) to retrieve all configured feedback sources.

• Returns a list of sources with their sourceId, sourceType, name, and configuration details.

• Use the sourceId from results to filter comments in get_feedback_comments.

• Each source represents a connected integration like surveys, support tickets, or app store reviews.

TYPICAL WORKFLOW:

1. Call get_feedback_sources to discover available sources and their sourceId values.

2. Call get_feedback_comments with specific sourceId to retrieve comments from that source.

Retrieve objects from Amplitude URLs

WHEN TO USE:

• CRITICAL: Only use this tool if the user shares a link to an amplitude URL which starts with https://app.eu.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.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, and metrics

Search session replays for a project using event count filters and segment filters.

WHEN TO USE:

• You want to find session replays that match certain event count filters and user segments or conditions (e.g., variant membership, cohorts, user properties).

INSTRUCTIONS:

• Provide the projectId and one or more event count filters and one or more segments with conditions.

• Searches the last 30 days with a limit of 10 replays by default.

• Optionally include eventCountFilters, groupBys, and limit.

IMPORTANT: ALWAYS provide the clickable replay links to users. Each session replay result includes a direct URL that users can click to view the full replay in Amplitude's Session Replay interface. These links are essential for users to actually watch and analyze the sessions. Simply providing raw session data without the viewing links is not helpful.

EXAMPLES:

• Segments: All users segmentFilters: [{ "conditions": [] }]

• Segments: Experiment variant membership segmentFilters: [ { "conditions": [ { "type": "property", "group_type": "User", "prop_type": "user", "prop": "gp:[Experiment] My Flag", "op": "is", "values": ["treatment"] } ] } ]

• Segments: Country = US and plan in {Pro, Enterprise} segmentFilters: [ { "conditions": [ {"type":"property","group_type":"User","prop_type":"user","prop":"country","op":"is","values":["US"]}, {"type":"property","group_type":"User","prop_type":"user","prop":"plan","op":"is","values":["Pro","Enterprise"]} ] } ]

• Event counter: at least 1 Purchase event eventCountFilters: [ { "count": "1", "operator": "greater or equal", "event": {"event_type": "Purchase", "filters": [], "group_by": []} } ]

• Event counter: >= 3 Page Viewed on pricing page eventCountFilters: [ { "count": "3", "operator": "greater or equal", "event": { "event_type": "Page Viewed", "filters": [ { "group_type": "User", "subprop_key": "page", "subprop_op": "is", "subprop_type": "event", "subprop_value": ["pricing"] } ], "group_by": [] } } ]

NOTES:

• Prefer property-based segment conditions for attributes; prefer eventCountFilters for behavioral criteria.

Query a single chart given its ID.

RULES:

• Users want to know references for analyses in order to validate the data.

• ALWAYS REFERENCE CHARTS TO THE USER BY THEIR LINK WHEN QUERIED AND USED IN ANALYSES.

WHEN TO USE:

• You want to query a chart to get its data.

• Only one chart or chart edit can be queried in a single request.

INSTRUCTIONS:

• Identify the IDs of the charts you want to query from the conversation context (e.g., from URLs) or use the search tool to find them.

• Provide saved charts via chartId parameter and chart edits (links ending in /chart/new/<edit_id> or /chart/<chart_id>/edit/<edit_id>) via the chartEditId parameter.

• Only one chart or chart edit ID is allowed per request; if you have both, prefer the chart edit ID.

• Use this tool to query one chart or chart edit.

• Results will include data for the chart and errors if it fails.

RESPONSE FORMAT: Returns {isCsvResponse: bool, csvResponse or jsonResponse, definition}. Only ONE response type present. Check the isCsvResponse flag to determine which response format to parse

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. 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 point for a given time period with a "value" property

  • overallSeries: Array of arrays, each containing data the overall data point (across the entire range) under the "value" property

  • 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"] }

Query up to 3 charts concurrently given their IDs.

RULES:

• Users want to know references for analyses in order to validate the data.

• ALWAYS REFERENCE CHARTS TO THE USER BY THEIR LINK WHEN QUERIED AND USED IN ANALYSES.

WHEN TO USE:

• You want to query multiple charts to get their data efficiently.

• Maximum of 3 charts can be queried in a single request.

INSTRUCTIONS:

• Identify the IDs of the charts you want to query from the conversation context (e.g., from URLs) or use the search tool to find them.

• Provide saved charts via chartIds parameter and chart edits (links ending in /chart/new/<edit_id> or /chart/<chart_id>/edit/<edit_id>) via the chartEditIds parameter.

• Chart edit IDs take precedence over chart IDs when both are available for a given chart.

• Use this tool to query up to 3 charts + chart edits (combined total).

• Results will include data for each successfully queried chart and errors for any failed charts.

RESPONSE FORMAT: Returns {isCsvResponse: bool, csvResponse or jsonResponse, definition}. Only ONE response type present. Check the isCsvResponse flag to determine which response format to parse

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. 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 point for a given time period with a "value" property

  • overallSeries: Array of arrays, each containing data the overall data point (across the entire range) under the "value" property

  • 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"] }

Execute a data query using the dataset endpoint for more complex queries.

WHEN TO USE

• You want to query data to form an ad hoc analysis within a project that does not already exist as a chart, metric, or experiment.

• You want to tweak an existing chart to glean more information from it (e.g. add a group by, change the time range, etc.)

STRATEGIES

1. Use the 'search' tool to find existing charts that relate to the data you want to query.

2. Use the 'get_charts' tool to understand the events, properties, and dataset schema generally.

3. Optionally use the 'search' tool again to find additional events, user properties, etc. needed for the query.

4. Optionally use the 'get_event_properties' tool to get properties on individual events.

5. Use this tool to query the ad hoc analysis.

GENERAL GUIDELINES

• Don't assume or guess properties, events, or schema. Use the tools provided to you to understand the data before running a dataset query.

• When running into query failures, try searching for existing charts to understand the data taxonomy and dataset schema.

• When you receive a 400 error response the schema is likely incorrect or the events/properties do not exist.

• ALWAYS include a descriptive "name" field in the definition object. This name will be displayed as the chart title. Examples: "Active Users Last 7 Days", "Sign Up to Purchase Funnel", "New User Retention".

AMPLITUDE WIDE META EVENTS TYPES

Special system events available for analysis. Events are passed in the "event_type" field:

• "_active": Any active event useful for tracking 'active users' like DAU, MAU(events not marked as inactive)

• "_all": Any event being tracked in Amplitude

• "_new": Events triggered by new users within the time interval. Useful for tracking 'new users'.

• "_any_revenue_event": Any revenue-generating event. Useful for tracking 'revenue'.

• "$popularEvents": Top events by volume (dynamically computed). Useful for more meta taxonomy analyses like 'what are the most common events'.

PROPERTY TYPES:

• AMPLITUDE CORE PROPERTIES: Built-in properties automatically tracked by Amplitude

  • Have source: "AMPLITUDE"

  • Use standard naming (lowercase, underscores)

  • Available for all events and users

• CUSTOM PROPERTIES: Organization-defined properties

  • Have source: "CUSTOMER"

  • ALWAYS prefixed with "gp:" (e.g., "gp:email", "gp:full name")

  • Include experiment flags like "gp:[Experiment] feature-name"

COMPLETE LIST OF AMPLITUDE CORE PROPERTIES:

User & Session Identification:

• user_id: Primary user identifier

• amplitude_id: Amplitude's internal user ID

• device_id: Unique device identifier

• session_id: Session identifier

• event_id: Unique event identifier

Geographic Properties:

• ip_address: User's IP address

• country: Country (from GeoIP)

• city: City (from GeoIP)

• region: State/region (from GeoIP)

• dma: Designated Market Area

• $postal_code: Postal/ZIP code

• location_lat: Latitude coordinate

• location_lng: Longitude coordinate

Device & Platform Properties:

• platform: Device platform (iOS, Android, Web, etc.)

• device: Device family name

• device_type: Type of device (mobile, tablet, desktop)

• os: Operating system

• language: Device language setting

• carrier: Mobile carrier

Application Properties:

• version: Current app version

• start_version: Version when user first used the app

• library: SDK library used to send data

• server_upload_time: When data was received by Amplitude

Business Properties:

• paying: Whether user is a paying customer

RESPONSE FORMAT: Returns {isCsvResponse: bool, csvResponse or jsonResponse, definition}. Only ONE response type present. Check the isCsvResponse flag to determine which response format to parse

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. 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 point for a given time period with a "value" property

  • overallSeries: Array of arrays, each containing data the overall data point (across the entire range) under the "value" property

  • 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"] }

Query an experiment analysis.

CRITICAL: Do NOT pass metricIds unless user explicitly requests specific metrics or requests analysis on secondary metrics. Omit metricIds for primary metric only (cleaner, focused results).

RULES:

• Users want to know references for analyses in order to validate the data.

• ALWAYS REFERENCE EXPERIMENTS TO THE USER BY THEIR LINK WHEN QUERIED AND USED IN ANALYSES.

WHEN TO USE:

• You want to query a experiment for analysis.

INSTRUCTIONS:

• Use the search tool to find the ID of the experiment you want to query.

• You may want to use the get_experiments tool to get more context about the experiment (i.e. state, variants, etc.)

• Use this tool to query the experiment analysis.

EXAMPLE: groupBy: [{"type": "user", "value": "device type", "group_type": "User"}]

Search for dashboards, charts, notebooks, experiments, 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.

• When searching for taxonomy entities like events, properties, etc. use higher limits (e.g. 100-200) to get more results as there are more important entities to search through.

• When searching for events, use the get_event_properties tool to get event properties on an individual event.

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.