Pendo

Rank pages, features, or track events by aggregate usage over a date range, or measure a named set of them as one population. Entities are identified by ID, never by name. Returns {meta, summary, rows}; which part answers the question depends on which of the two was asked. WHOLE TYPE - omit productArea and name the entityType. Ranks every entity of that type, shaped by sortBy, sortOrder and limit. By default only entities WITH activity are ranked, so sortOrder='asc' gives the least-used among the USED ones; add includeUnused=true when the question is about entities getting no use at all. Two cautions: a named entity missing from the rows may simply have fallen outside limit, so to ask whether one specific entity was used, scope to it with an inline productArea instead; and the summary here covers every entity of the type, not only the rows returned, so it is not a total for the top N. A NAMED SET - pass productArea to scope to saved areas or exactly the inline entities listed, which may span entity types in ONE call; that is the only way to measure a set crossing them. Read the SUMMARY for the set as a whole: it treats the set as one deduplicated population and is independent of limit, so limit=1 still summarises everything in scope, while the rows give the breakdown within it. An entity with no activity is absent from the rows rather than ranked last, but the rows are still capped by limit - so take absence to mean 'no activity' only when limit is at least as large as the list, or set includeUnused=true (single-type lists only) to get an explicit all-zero row for every entity in the scope. Add minEvents to count only the visitors whose events across the set reach a threshold - 'how many people used this bundle at least N times'. Supply entityType for an unscoped whole-type ranking; inline productArea entries carry their own types. NEVER add rows together for a set-wide figure, and use the summary instead. Counts of distinct things - uniqueVisitors, uniqueAccounts, and their current_/prior_ forms in comparison mode - count a visitor active on several entities ONCE in the summary but once per row, so summing them silently inflates the answer and the rows do not carry the overlap needed to correct it. Only the additive totals - totalEvents and the frustration counts - match the sum of the rows; avgTimePerVisitor is an average and does not. Where entityUsage returns per-visitor rows for one known entity, this returns one row per entity showing how an entire cohort, optionally scoped by a segment, uses each of them. COMPARISON MODE - supply compareToDateRange to rank by how usage CHANGED between two periods rather than by level: dateRange is the current period, compareToDateRange the earlier baseline. Sort by a change_ column (ascending = biggest drop-off, descending = biggest growth). The ranking happens in the aggregation, so no per-entity cross-referencing is needed. includeUnused is ignored when comparing. USE FOR: Ranking or comparing entities by usage (top pages by views, most-clicked features, features associated with a page, least-used track events), or measuring a named bundle of them - including one spanning entity types - as one population. EXAMPLES: - Top 5 features by clicks last month - Which page had the most views in the last 30 days? - Which features have the most rage clicks this quarter? - Which features associated with page X were clicked most in the last 30 days? - Least-used track events over the last week - Which pages got no views at all in the last 30 days? - Which features were never used by visitors in segment X last month? - Which pages in product area X have zero activity from visitors in segment Y? - Which pages dropped off in usage the most this month versus last month? - Which features grew the most in the last 30 days compared to the prior 30 days? - How many people used any of these three features last month? - How many visitors used our premium tier - these 4 features, this page and these 2 track events - at least twice last month? - How many visitors used these three features at least twice in the last 30 days? - How did usage of this bundle of pages change this quarter versus last? NOT FOR: Resolving an entity name to an ID. Single-entity questions where per-visitor rows are wanted, such as 'which people viewed Page X and how long did each spend'. Deriving stickiness (DAU/MAU, DAU/WAU, WAU/MAU) for a product area by calling this tool at multiple date-range granularities and dividing uniqueVisitors/uniqueAccounts across them - that does not match how the Product Areas page computes stickiness. There is no canonical product-area-scoped stickiness metric yet; say so instead of approximating one. WORKFLOW: For usage analytics about one named page, feature, or track event, call listPagesFeaturesAndEvents to resolve the name to an entity ID, then use entityUsage with that ID. Use aggregateEntityUsage only when the user asks to rank or compare multiple entities, or to analyse a named group of them together via productArea. When the user names several entities as a set ('the three features in our premium tier'), resolve each name to an ID and pass them all as inline entities in ONE productArea call - do not make a call per entity and add the results up, which double-counts every visitor active on more than one of them. This holds when the set crosses entity types: group the ids by type into one productArea list rather than issuing a call per type. RETURNS: - meta.dateRange: resolved startDate and endDate (YYYY-MM-DD); meta.compareToDateRange when comparing - summary: the whole scoped set as one deduplicated population - totalEvents, uniqueVisitors, uniqueAccounts (pages/features also: totalErrorClickCount, totalRageClickCount, totalDeadClickCount; pages also: totalUTurnCount, avgTimePerVisitor). Independent of limit, and not the sum of the rows. In comparison mode it carries the same current_/prior_/change_/pctChange_ columns the rows do. When productArea spans entity types the summary carries the three shared metrics only, and its uniqueVisitors counts a visitor once across the whole bundle even when they were active on entities of different kinds - rows: one per entity with entityId, entityName, appId, totalEvents (page views / feature clicks / track-event counts - report it with the word matching the entity type rather than the generic 'events', including the current_/prior_/change_ forms when comparing), uniqueVisitors, uniqueAccounts (pages/features also: totalErrorClickCount, totalRageClickCount, totalDeadClickCount; pages also: totalUTurnCount, avgTimePerVisitor). Track events carry none of the frustration or time metrics, so none of those columns can rank them. With includeUnused=true, unused entities appear with all-zero metrics. In comparison mode the headline metrics (totalEvents, uniqueVisitors, uniqueAccounts) are split into current_<m>, prior_<m>, change_<m> and pctChange_<m>, while the other metrics (frustration counts, avgTimePerVisitor) carry change_<m> only. Prefer change_ for mover/drop-off rankings (pctChange is noisy on small baselines and null when prior is 0). When productArea spans entity types each row adds entityType ('page', 'feature' or 'trackEvent') and carries the three shared metrics only - read totalEvents as views, clicks or event counts according to that row's entityType, and do not compare it across rows of different types as if it were one unit

Rank guides by aggregate usage over a date range, returning one row per guide. Where guideMetrics analyses a single known guide in depth, this tool compares an entire cohort's usage across every guide. Each row has entityId, entityName, appId, totalViews, totalCompletions, totalDismissals, uniqueVisitors, uniqueAccounts, and viewsPerUser. totalViews excludes continue-resumed guideSeen events to match the guide-details UI. Deleted guides surface with entityName "(Deleted Guide)". USE FOR: Cross-guide ranking - e.g. top guides by views, which guides have the most dismissals, least-used guides. EXAMPLES: - Top 10 guides by views last month - Which guides have the most dismissals? - Show me the least-completed guides over the last 30 days - Rank guides by unique visitors this quarter - Top public tooltips by views - Compare views for these three guides RETURNS: - meta.dateRange: resolved startDate and endDate (YYYY-MM-DD) - meta.totalGuideCount: total distinct guides with activity before limit - rows: one per guide with entityId, entityName, appId, totalViews, totalCompletions, totalDismissals, uniqueVisitors, uniqueAccounts, viewsPerUser FILTERING OPTIONS: - productArea: restrict the ranking to guides in saved product areas or an inline guide list - status: guide state - public, staged, scheduled, draft, pendingReview, inactive - guideType: guide type - banner, tooltip, lightbox, walkthrough, whatsnew, building-block, group, training, launcher, mobile-lightbox - activation: launch method - auto (automatic), api, badge, dom (element click), embed, launcher (resource center), page, feature, form, track - guideCategoryIds: guides belonging to those guide categories - pageIds: guides whose first step is on one of those pages ("sitewide" matches guides with no page) - appId, accountId, segmentPipeline: scope the underlying guide activity - Note: metadata filters resolve current guides, so deleted guides drop out of the results.

Get per-visitor or per-account app usage metrics for a date range. Returns {summary, rows}: summary has total active visitors/accounts, total events across the selected app scope, average daily time on apps, and totals for the four frustration counts (totalErrorClickCount, totalRageClickCount, totalUTurnCount, totalDeadClickCount); rows are per-visitor or per-account breakdowns with daysActive, totalTime and avgTimePerDay (duration objects {seconds, display}), totalEvents, and the same four frustration totals, sorted and limited. When groupBy="account" each row also includes numVisitors - the count of distinct visitors from that account who were active during the window. Rows can instead be grouped at scale by one event-time historic or current visitor/account metadata field with groupByMetadata; metadata-grouped rows include metadataValue, numVisitors, numAccounts, and the usage metrics. Optionally include metadata fields for each returned visitor or account with select. Optionally filter the usage by custom event properties, event-time historic metadata, or current visitor/account metadata with propertyFilters. Audience can be scoped via an inline segmentPipeline; scope can also be narrowed to a single app via appId, or to a group of entities via productArea - one or more saved product areas, every one of them, or an inline list of pages, features and track events that is not saved in Pendo. When productArea is supplied the same summary and rows describe headline usage metrics for that group, measured over its page, feature, and track-event activity, with a visitor active on several of its entities counted once. minEvents restricts every summary total and every row to visitors with at least that many events over the date range, counting events rather than visits - so it identifies heavy users, not returning ones; with groupBy="account" it returns the accounts containing at least one such visitor, and their metrics cover only those visitors' events. USE FOR: Per-visitor, per-account, or metadata-grouped app-level usage (events, time, days active) AND top-N ranking over a window across every app, or one app when appId is supplied, or a group of entities when productArea is supplied - saved product areas or an inline list of pages, features and track events (headline usage metrics for that group). Also counts visitors above an event threshold over the window via minEvents. EXAMPLES: - Who uses our apps the most in the last 30 days? - Top 50 accounts by app usage last quarter - Which visitors rage-click the most across our apps last week? - Top 20 visitors by total time in app X last month - Headline usage metrics for product area X over the last 30 days - Top 20 accounts by usage of product area X last quarter - Show the top 20 accounts by app usage last quarter with their ARR and company size - How many visitors generated at least 10 events last month? - Top 20 accounts by app usage last month, counting only visitors whose role was admin at the time NOT FOR: Deriving stickiness (DAU/MAU, DAU/WAU, WAU/MAU) for a product area by calling this tool at multiple date-range granularities and dividing the resulting totalNumVisitors/totalNumAccounts. That does not match how the Product Areas page computes stickiness and gives a different answer on every attempt. There is no canonical product-area-scoped stickiness metric yet - say so instead of approximating one. For app-scoped stickiness, use productEngagementScore instead. RETURNS: - meta.dateRange: resolved startDate and endDate (YYYY-MM-DD) - meta.visitorsFromGateway: whether summary.totalNumVisitors was sourced from the aggmw gateway (only attempted for a product-area request with no segment/app/minEvents/propertyFilters scope; false otherwise or on any gateway failure) - summary: totalNumVisitors or totalNumAccounts, totalNumEvents, avgDailyActiveTime (duration object {seconds, display}), totalErrorClickCount, totalRageClickCount, totalUTurnCount, totalDeadClickCount - rows: daysActive, totalTime, totalEvents, avgTimePerDay, totalErrorClickCount, totalRageClickCount, totalUTurnCount, totalDeadClickCount per visitor or account; per-account rows also include numVisitors; metadata-grouped rows include metadataValue, numVisitors, and numAccounts; select adds requested metadata fields

Get app-level usage metrics over time. Groups events into buckets of the requested period (daily/weekly/monthly) and returns one row per bucket with app-wide totals: active visitors, active accounts, events, average active time (a duration object {seconds, display}), and the four frustration counts (totalErrorClickCount, totalRageClickCount, totalUTurnCount, totalDeadClickCount). The average metric matches the requested period: avgDailyActiveTime, avgWeeklyActiveTime, or avgMonthlyActiveTime. Audience can be scoped via an inline segmentPipeline; scope can also be narrowed to a single app via appId, or to a group of entities via productArea - one or more saved product areas, every one of them, or an inline list of pages, features and track events that is not saved in Pendo. When productArea is supplied each bucket describes that group's usage, measured over its page, feature, and track-event activity, with a visitor active on several of its entities counted once in that bucket. minEvents restricts every bucket to the visitors with at least that many events in that bucket, applied independently per bucket, so one call tracks an engagement threshold across the whole range. It counts events rather than visits, so it is not a returning-visitor measure. It combines with productArea, so a per-bucket threshold over a group of entities is one call rather than one call per bucket. USE FOR: Trend questions about whole-app usage over a window - e.g. 'how did active visitors trend over the last 12 weeks?', 'are rage clicks across our apps trending up?'. Also trends a product area or an inline entity list over time via productArea. With minEvents, tracks a per-bucket event threshold over time - e.g. 'visitors with at least 2 events per month', including over a product area. EXAMPLES: - How did active visitors trend over the last 12 weeks? - Total events per week across all apps over the last quarter - Are rage clicks across our apps trending up over the last 30 days? - How many visitors had at least 2 events in each of the last twelve months? - How did weekly active visitors for product area X trend over the last quarter? - Average weekly visitors with at least 2 events across these pages and features RETURNS: - meta.dateRange: resolved startDate and endDate (YYYY-MM-DD) - meta.period: echoed bucket size (daily|weekly|monthly) - meta.metrics: list of metric names returned per bucket - rows: one entry per time period, containing a 'bucket' string (YYYY-MM-DD or YYYY-MM), a startTime (epoch ms), and metric values; numeric metrics zero-fill for empty buckets

buildPendoSegment: Purpose: Describe one visitor segment by visitor or account ID, activity on Pages, Features, TrackEvents, Guides, Poll responses, the elements inside a guide, guide-experiment variant membership, segment membership, or metadata. Input shape: pass definition as an array of rule groups. Top-level groups are ANDed together; rules within a group are ORed together. For one ANDed rule, wrap it in a single-item group. SINGLE CALL CONTRACT (important): The ENTIRE segment, including every AND clause and every OR clause, MUST be built with ONE call to this tool. Never split a segment across multiple calls. Combine all clauses into a single definition array and pass it once. Calling the tool more than once produces multiple unrelated segments, NOT one combined segment, so the AND/OR logic between the calls is lost. Mapping a request to a single definition: - Split the request into top-level AND clauses. - Each AND clause becomes one group (one inner array) in the definition. - Inside a clause, every OR alternative becomes one rule object in that group. - A clause with no OR is a group containing a single rule object. CLAUSE COVERAGE (important): Account for EVERY clause in the request. Before returning, count the AND clauses in the request and confirm the definition has exactly that many top-level groups, then confirm every OR alternative inside each clause is present as a rule object. Never drop, merge, or skip a clause. If the request mentions a page rule, a feature rule, and a track event rule joined by AND/OR, all of them must appear. A request like "(X OR Y) AND Z" has 2 top-level groups (one for "X OR Y", one for "Z") and 3 rule objects total; returning fewer groups or rules is wrong. Full example (combining AND and OR in one call): Request: "(visitors who spent > 15 minutes on page A in May OR have NOT seen page B in the last year) AND triggered track event C on fewer than 5 days in the last 7 days" Correct single definition (one tool call): [ [ { "entityType": "page", "entityId": "A", "metric": "eventTime", "operator": ">", "threshold": 15, "condition": "between", "first": "2026-05-01", "last": "2026-05-31" }, { "entityType": "page", "entityId": "B", "metric": "notseen", "condition": "withinLast", "lookbackAmount": 12, "granularity": "months" } ], [ { "entityType": "trackEvent", "entityId": "C", "metric": "daysActive", "operator": "<", "threshold": 5, "condition": "withinLast", "lookbackAmount": 7, "granularity": "days" } ] ] The first group (the two page rules) is ORed together; that group is then ANDed with the second group (the track event rule). This is ONE call, not two. REQUIRED FIELDS AND CONDITION CHOICE (important): Activity metrics with non-empty supportedConditions MUST include an explicit "condition" field. It is the discriminator that selects which time/frequency fields apply, and it is NOT optional for those metrics. Always choose condition from the chosen metric's supportedConditions. Do NOT rely on the presence of first/last, lookbackAmount/granularity, or date to imply the condition; you must still set condition explicitly for activity metrics. For example: - first + last present => you MUST also set condition: "between" - lookbackAmount + granularity => you MUST also set condition: "withinLast" - date present => you MUST also set condition: "since" Segment membership metrics are the exception: - isMemberOfSegment and isNotMemberOfSegment have supportedConditions: [] by design. - For these metrics, omit "condition" entirely. Do NOT add "ever" or infer any default condition. - supportedConditions: [] means "no condition field", not "choose a default condition". Visitor and account ID rules are conditionless and metricless: - Use entityType: "visitor" or "account". - Use operator: one of "==", "!=", "contains", "!contains", "empty", "!empty". Omit it to default to "==". - Use entityId for the comparison value with "==", "!=", "contains", and "!contains". - Use an empty entityId with "empty" and "!empty". - Example: { "entityType": "visitor", "entityId": "bob@example.com" }. - Example: { "entityType": "visitor", "entityId": "@example.com", "operator": "contains" }. - Example: { "entityType": "account", "entityId": "acme-corp" }. Metadata rules are also conditionless and metricless: - Use entityType: "metadata". - Use entityId for the full metadata key, e.g. "visitor.agent.job_role". - Use operator: one of "==", "!=", ">=", "<=", "contains", "!contains", "empty", "!empty". - Use value for "==", "!=", ">=", "<=", "contains", and "!contains". Omit value for "empty" and "!empty". - Time and date metadata values may use ISO 8601, e.g. "2025-12-31T23:59:59Z". - Example: { "entityType": "metadata", "entityId": "visitor.agent.job_role", "operator": "==", "value": "Software engineer" }. Event-property filters narrow page, feature, or track-event aggregation rules by a property on each event: - Add one eventProperty object with property, operator, and (except for empty/!empty) value. - For a custom event property, use its plain property name. Custom properties are supported on feature and trackEvent rules. - For historical metadata captured on an event, use kind.group.field, e.g. "visitor.agent.user_job_role". Historical metadata is supported on page, feature, and trackEvent rules. - Event properties require an aggregation metric such as eventCount or daysActive; they cannot be added to seen/used counter metrics. - Use listPagesFeaturesAndEvents eventPropertyNames to discover custom properties. Historical metadata must currently be promoted. - Example: visitors who ran a report with the "source" filter in the last 30 days: [ [ { "entityType": "trackEvent", "entityId": "<reportRanTrackEventId>", "metric": "eventCount", "operator": ">=", "threshold": 1, "condition": "withinLast", "lookbackAmount": 30, "granularity": "days", "eventProperty": { "property": "filter", "operator": "==", "value": "source" } } ] ] Guide element rules cover clicks on one button, link or close icon inside a guide: - Use entityType: "guideElement". - Use entityId for the GUIDE id, stepId for the step the element sits on, and elementId for the element's uiElementId, e.g. { "entityType": "guideElement", "entityId": "<guideId>", "stepId": "<guideStepId>", "elementId": "pendo-button-a1b2c3d4", "metric": "eventCount", "operator": ">=", "threshold": 1, "condition": "withinLast", "lookbackAmount": 30, "granularity": "days" }. - One getEntity call gives both ids: steps[].stepId and the steps[].elements[].uiElementId nested under it. Never guess either. - eventCount is the only supported metric, and it counts clicks on that element in the chosen window: - "clicked it" => operator ">=", threshold 1 - "did not click it" => operator "==", threshold 0 - click counts => any operator, e.g. "clicked it more than 3 times" is operator ">", threshold 3 - stepId does not narrow the count. - Only withinLast and between are available, so a click rule is always scoped to a window. Poll response rules select visitors by a numeric poll response: - Use entityType: "poll", entityId for the guide id, and pollId for its poll. - Resolve pollId from getEntity's guide steps[].polls[] output; select the poll whose type is the poll type. Never guess a pollId. - Use metric: "response", a numeric operator and threshold, plus a supported condition. - Conditions ever, since (with date), withinLast, and between are supported. A response range requires two separate top-level AND groups, not one OR group. For example, responses from 7 through 10 in the last 30 days: [ [{ "entityType": "poll", "entityId": "<surveyGuideId>", "pollId": "<pollId>", "metric": "response", "operator": ">=", "threshold": 7, "condition": "withinLast", "lookbackAmount": 30, "granularity": "days" }], [{ "entityType": "poll", "entityId": "<surveyGuideId>", "pollId": "<pollId>", "metric": "response", "operator": "<=", "threshold": 10, "condition": "withinLast", "lookbackAmount": 30, "granularity": "days" }] ] Resolution steps 1. Choose entityType from EntityTypes. 2. For visitor or account, use entityId + optional operator and stop here. 3. For metadata, use entityId + operator + optional value and stop here. 4. For activity and segment entities, choose metric from EntityTypes[entityType].supportedMetrics. 5. Look up Metrics[metric]. 6. If Metrics[metric].supportedConditions is non-empty, choose condition from that list and look up Conditions[condition]. 7. The final rule fields are: EntityTypes[entityType].requiredFields + Metrics[metric].requiredFields + Conditions[condition].requiredFields, only when a condition is required. Time phrase resolution examples: - "this year" / "so far this year" / "year to date" => condition: "since", date: "2026-01-01" - "this month" / "month to date" => condition: "since", date: "2026-06-01" - "since 2026-01-01" => condition: "since", date: "2026-01-01" - "last year" => condition: "between", first: "2025-01-01", last: "2025-12-31" - "in the last year" => condition: "withinLast", lookbackAmount: 12, granularity: "months" - "between 2026-01-01 and 2026-06-05" => condition: "between", first: "2026-01-01", last: "2026-06-05" - "in March" => condition: "between", first: "2026-03-01", last: "2026-03-31" - "last 3 weeks" => condition: "withinLast", lookbackAmount: 3, granularity: "weeks" - "last 7 days" => condition: "withinLast", lookbackAmount: 7, granularity: "days" CONDITION CHOICE FOR TIME PHRASES (important): - Use "since" (set only date) for any open-ended period running from a start date up to now: "this year", "this month", "year to date", "so far", "since <date>". Do NOT express these as "between ... today". - Use "between" (set first + last) ONLY for a closed range whose end is a specific past date or the last day of a named calendar period (e.g. "in March", "last year", "between X and Y"). - Use "withinLast" (set lookbackAmount + granularity) for rolling windows: "last N days/weeks/months". - Set ONLY the fields the chosen condition requires. Never combine date with first/last in one rule. A segment should be just as valid in a week's time as it is today, so never hardcode today's date as an endpoint. For a fixed/named calendar period (e.g. "in March") use "between" spanning the entire period even if it has not finished yet. For an open-ended current period (e.g. "this year", "this month") use "since" with the period's start date, which stays valid going forward. EntityTypes: visitor: requiredFields: entityType: "visitor" entityId: String supportedMetrics: [] account: requiredFields: entityType: "account" entityId: String supportedMetrics: [] page: requiredFields: entityType: "page" entityId: String supportedMetrics: ["eventCount", "deadClicks", "errorClicks", "rageClicks", "daysActive", "uTurns", "eventTime", "seen", "notseen", "lastSeen"] feature: requiredFields: entityType: "feature" entityId: String supportedMetrics: ["eventCount", "deadClicks", "errorClicks", "rageClicks", "daysActive", "used", "notused", "lastused"] trackEvent: requiredFields: entityType: "trackEvent" entityId: String supportedMetrics: ["eventCount", "daysActive", "used", "notused", "lastused"] guide: requiredFields: entityType: "guide" entityId: String supportedMetrics: ["seen", "lastSeen", "notSeen"] poll: requiredFields: entityType: "poll" entityId: String pollId: String // the poll nested under the guide supportedMetrics: ["response"] guideElement: requiredFields: entityType: "guideElement" entityId: String stepId: String // the guide step the element sits on elementId: String // the element's uiElementId, e.g. "pendo-button-a1b2c3d4" supportedMetrics: ["eventCount"] segment: requiredFields: entityType: "segment" entityId: String supportedMetrics: ["isMemberOfSegment", "isNotMemberOfSegment"] metadata: requiredFields: entityType: "metadata" entityId: String supportedMetrics: [] agent: requiredFields: entityType: "agent" entityId: String supportedMetrics: ["eventCount", "daysActive", "used", "notused", "lastused"] guideExperiment: requiredFields: entityType: "guideExperiment" entityId: String experimentId: String // the experiment, from listGuideExperiments; draft experiments are not selectable. Requires guide experiments enabled for the subscription; rules that need it are refused otherwise. variantName: Enum["A", "B"] // POSITIONAL: "A" is the experiment's first variant and "B" its second, whichever is the control. Experiments have exactly two variants. experimentConverted: Enum["None", "Yes", "No"] // only when the experiment has a conversion goal; "None" means any conversion status supportedMetrics: [] Metrics: eventCount: description: Number of events for the selected entity. requiredFields: metric: "eventCount" operator: Enum["==", "!=", ">=", "<="] threshold: Integer supportedConditions: ["withinLast", "between"] deadClicks: description: Number of dead clicks for the selected page or feature. requiredFields: metric: "deadClicks" operator: Enum["==", "!=", ">=", "<="] threshold: Integer supportedConditions: ["withinLast", "between"] errorClicks: description: Number of error clicks for the selected page or feature. requiredFields: metric: "errorClicks" operator: Enum["==", "!=", ">=", "<="] threshold: Integer supportedConditions: ["withinLast", "between"] rageClicks: description: Number of rage clicks for the selected page or feature. requiredFields: metric: "rageClicks" operator: Enum["==", "!=", ">=", "<="] threshold: Integer supportedConditions: ["withinLast", "between"] daysActive: description: Number of active days for the selected entity. requiredFields: metric: "daysActive" operator: Enum["==", "!=", ">=", "<="] threshold: Integer supportedConditions: ["withinLast", "between"] uTurns: description: Number of u-turns for the selected page. requiredFields: metric: "uTurns" operator: Enum["==", "!=", ">=", "<="] threshold: Integer supportedConditions: ["withinLast", "between"] eventTime: description: Time in minutes spent on the selected page. requiredFields: metric: "eventTime" operator: Enum["==", "!=", ">=", "<="] threshold: Integer supportedConditions: ["withinLast", "between"] response: description: Numeric poll response. Use two ANDed rules for a range. requiredFields: metric: "response" operator: Enum["==", "!=", ">=", "<="] threshold: Integer supportedConditions: ["ever", "since", "withinLast", "between"] used: description: Whether the selected feature or track event was used, optionally with a frequency threshold. requiredFields: metric: "used" supportedConditions: ["ever", "since", "withinLast", "atLeast", "atMost"] notused: description: Whether the selected feature or track event was not used. requiredFields: metric: "notused" supportedConditions: ["ever", "since", "withinLast"] lastused: description: When the selected feature or track event was last used. requiredFields: metric: "lastused" supportedConditions: ["since", "withinLast", "between"] seen: description: Whether the selected page was seen, optionally with a frequency threshold. For checking withinLast requiredFields: metric: "seen" supportedConditions: ["ever", "since", "withinLast", "atLeast", "atMost"] notseen: description: Whether the selected page was not seen. requiredFields: metric: "notseen" supportedConditions: ["ever", "since", "withinLast"] lastSeen: description: When the selected page was last seen. requiredFields: metric: "lastSeen" supportedConditions: ["since", "withinLast", "between"] isMemberOfSegment: description: Whether the visitor is a member of the selected segment. requiredFields: metric: "isMemberOfSegment" supportedConditions: [] isNotMemberOfSegment: description: Whether the visitor is not a member of the selected segment. requiredFields: metric: "isNotMemberOfSegment" supportedConditions: [] Conditions: ever: description: The metric happened at any time. requiredFields: condition: "ever" since: description: The metric happened on or after a specific date. requiredFields: condition: "since" date: DateString("yyyy-mm-dd") withinLast: description: The metric happened within a rolling time window. requiredFields: condition: "withinLast" lookbackAmount: Integer granularity: Enum["days", "weeks", "months"] between: description: The metric happened within an inclusive date range. requiredFields: condition: "between" first: DateString("yyyy-mm-dd") last: DateString("yyyy-mm-dd") atLeast: description: The metric happened at least threshold times ever requiredFields: condition: "atLeast" threshold: Integer atMost: description: The metric happened at most threshold times ever requiredFields: condition: "atMost" threshold: Integer

Compute a retention curve for an app (scope='app'), a specific page or feature (scope='page' or 'feature'), a track event (scope='trackEvent'), or a whole product area (scope='productArea'). For track events: measures how many accounts/visitors continue firing the event over time. Supports visitor-level or account-level retention (unit) and all vs first cohort modes (cohortMode='all' for all active users, 'first' for first-time users only - best for onboarding effectiveness). For scope='productArea', a user counts as active in a period if they used any page, feature, or track event in that area; guides in the area are not counted. Omit appId when the entity or area spans multiple applications - passing one restricts the curve to that application. Call this tool ONCE per question. A single call returns all periods at once - do NOT call it multiple times with different periodCount values. The analysis window is anchored to now() and works backwards. Do NOT pre-filter for 'new users in the last N days' via segmentPipeline - pass cohortMode='first' instead, which restricts to users whose all-time first interaction falls within the analysis window (truly new users, not returning users re-entering the window). Period 0 = '< 1 Month' is the % of cohort active more than once in their first period - a real metric, NOT a 100% baseline (typical rates 25-60%). Period N = % of cohort still active N periods later. activeCount at higher periods decreases because users too new to have reached that period are excluded from the denominator (dynamic denominator - correct, not missing data). summary.finalRetentionRate is the most important single number - it represents the durable retained core. USE FOR: Retention and churn questions - e.g. 'what % of users return after 3 months?', 'show me our retention curve', 'what's our churn rate?'. Not for acquisition questions ('how many new accounts did we gain?') - this tool measures continued activity of existing cohorts, not new-user counts. EXAMPLES: - What % of users return after 3 months? - Show me our retention curve - What's our account churn rate over the last 6 months? - How often do accounts that created a dashboard keep creating dashboards? - How well do we retain first-time users of this feature? - What's the retention curve for our Onboarding product area? RETURNS: - scope, entityId, cohortMode, unit, periodType: echoed query parameters - retentionCurve: list of {period, periodLabel, activeCount, multiSession, retentionRate} sorted by period - summary: {totalCohortSize, avgRetentionRate, finalRetentionRate}

Creates a new feedback item in this subscription's qualitative customer feedback system. Returns the ID of the created feedback item. Before calling this tool, you should list product areas, and assign the feedback to the appropriate product area. Then, before submitting the feedback, repeat all non-empty fields back to the user for confirmation, resolving IDs to human-readable names. USE FOR: When the user explicitly asks you to submit product feedback, feature requests, bug reports, etc. on behalf of a customer to the qualitative customer feedback system EXAMPLES: - Create feedback for this: [paste text] - Log a feature request for dark mode support - Submit feedback that the export CSV button is confusing - Capture this bug report about broken pagination - Record this customer's request for a Slack integration RETURNS: - ID of the created feedback item

Creates a new draft Pendo guide from raw HTML content. Each entry in rawHtmls becomes one step in the guide. Returns the guide ID and a direct URL to edit the guide in Pendo. USE FOR: When the user has generated HTML guide content (e.g. from the pendo-guide-creator skill) and wants to create a real Pendo guide from it EXAMPLES: - Create a guide from this HTML - Send this guide to Pendo - Publish these HTML files as a Pendo guide - Turn my generated guide steps into a real Pendo guide NOT FOR: Listing, searching, or querying existing guides - use listGuides or searchEntities instead RETURNS: - Guide ID of the newly created draft guide - Direct URL to the guide in the Pendo UI

Creates a new product idea - a product enhancement or new feature request - for this subscription, and returns the ID of the created idea. Every idea must be associated with at least one application; if the user hasn't said which, resolve the correct appId(s) first. Optionally assign the idea to one or more product areas by their IDs. Before submitting the idea, repeat all non-empty fields back to the user for confirmation, resolving IDs to human-readable names. USE FOR: When the user explicitly asks you to log a product idea or feature concept into the ideas backlog EXAMPLES: - Create an idea for this: [paste text] - Log a product idea for a dark mode theme - Add an idea to support CSV exports on the reports page - Capture this idea about a bulk-edit workflow RETURNS: - ID of the created idea

Creates an empty HTML editor email (no body) as a draft Orchestrate email. Required emailType (marketing or transactional) and appId. Optional name defaults to New email with a timestamp when omitted. USE FOR: Creating a new empty HTML editor email (draft, empty body). EXAMPLES: - createOrchestrateEmail emailType marketing appId 100 - createOrchestrateEmail emailType transactional appId 100 name Product update NOT FOR: Template or block-builder emails. Audience, schedule, sender, or launch. WORKFLOW: 1. Required emailType (marketing or transactional) from the user; STOP if not specified - ask the user, do not guess. Confirm appId with the user. 2. Call createOrchestrateEmail. 3. Call updateOrchestrateEmailContent with the returned emailId to save HTML body (or open emailUrl in the Orchestrate UI). 4. Call getOrchestrateEmail to confirm emailId, emailType, and draft status. RETURNS: - resultSummary: human-readable summary of the create - validationReport: validation result (valid true with no issues on success) - emailId: new email campaign id - emailUrl: direct URL to the email in the Pendo UI - name: email display name - status: email lifecycle status (draft on success)

Creates a draft Orchestrate journey from templateJson and returns journeyId. Use when the user wants a custom multi-email journey that createOrchestrateJourneyFromTemplate cannot express (single built-in template only). Build templateJson to match the JSON Schema on the templateJson parameter in this tool's inputSchema. This tool creates the graph layout (email steps, Conditional Split nodes with Yes and No branches, wait days between steps) only; it does not set audience, schedule, goals, or email content. After create, call getOrchestrateJourneySteps to verify the draft graph, then setOrchestrateJourney* and updateOrchestrateEmailContent as needed. The condition on each Conditional Split is not set here - configure it in the Orchestrate UI. Activating or publishing the journey is UI-only (no MCP tool). USE FOR: Creating a new draft Orchestrate journey with a custom multi-step graph supplied as templateJson. EXAMPLES: - User wants a welcome email then a follow-up email 3 days later: read templateJson inputSchema, build messageGraph with two Message nodes, set messageData.durationInDays to 3 on the first Message node (the wait before the follow-up) and durationInDays to 1 on the last Message node, call createOrchestrateJourneyFromJson for app 12345 - User wants email A then a Conditional Split where the Yes branch goes to email B and the No branch to exit: add a nodeType Condition node with edgeType Yes and edgeType No edges after email A; configure the condition in the Orchestrate UI - User wants an initial email, then a Conditional Split where the Yes branch sends email 1 and the No branch sends email 2: build Start -> Message (initial) -> Condition with edgeType Yes to a Message named email 1 and edgeType No to a Message named email 2, each branch ending at its own Exit node; set messageData on all three Message nodes; configure the condition in the Orchestrate UI WORKFLOW: 1. Confirm multi-email need (not createOrchestrateJourneyFromTemplate). 2. Construct templateJson from templateJson inputSchema. 3. Create. 4. Verify the draft graph. RETURNS: - journeyId: id of the created draft journey - journeyUrl: direct URL to the journey in the Pendo UI - status: draft - validationReport: graph validation summary

Creates a draft Orchestrate journey from a built-in templateId and returns journeyId. Supply templateId only - the server applies a fixed messageGraph; do not send templateJson. Supported templateId values are listed in the templateId parameter enum in this tool's inputSchema. For custom multi-email journeys, use createOrchestrateJourneyFromJson (templateJson inputSchema on that tool). This tool only selects which built-in graph to apply; it does not set audience, schedule, goals, or email body. After create, call getOrchestrateJourneySteps to verify the draft graph, then setOrchestrateJourney* and updateOrchestrateEmailContent as needed. Activating or publishing the journey is UI-only (no MCP tool). USE FOR: Creating a new draft Orchestrate journey from a single built-in MCP template. EXAMPLES: - Create a draft Orchestrate journey named 'Welcome email' with templateId mcpSingleEmailJourneyTemplate for app 12345 WORKFLOW: 1. Confirm single built-in template is enough (not createOrchestrateJourneyFromJson). 2. Call with a templateId from inputSchema enum. 3. Verify the draft graph. RETURNS: - journeyId: id of the created draft journey - journeyUrl: direct URL to the journey in the Pendo UI - status: draft - validationReport: graph validation summary

Creates a new Pendo visitor segment and returns its id. Confirm the segment name and the human-readable summary of every AND/OR clause with the user before submitting. Pendo does not enforce unique segment names - if the user cares about uniqueness, check existing segments first. USE FOR: Only call this when the user wants a persistent segment saved to Pendo. Do not call this to preview a segment or to scope a one-off analytics query. EXAMPLES: - Create a segment named "Power users" for visitors active in the last 30 days. - Save this as a segment called "Trial churn risk". RETURNS: - id: the created segment's id. Can be used as a segmentId in downstream tools (segment-membership rules, list filters, etc.). - summary: plain-English description of the persisted segment rules with entity names resolved. Reflects what was actually stored after compile-time normalization (e.g. strict > operators become >= with adjusted thresholds). EntityTypes: visitor: requiredFields: entityType: "visitor" entityId: String supportedMetrics: [] account: requiredFields: entityType: "account" entityId: String supportedMetrics: [] page: requiredFields: entityType: "page" entityId: String supportedMetrics: ["eventCount", "deadClicks", "errorClicks", "rageClicks", "daysActive", "uTurns", "eventTime", "seen", "notseen", "lastSeen"] feature: requiredFields: entityType: "feature" entityId: String supportedMetrics: ["eventCount", "deadClicks", "errorClicks", "rageClicks", "daysActive", "used", "notused", "lastused"] trackEvent: requiredFields: entityType: "trackEvent" entityId: String supportedMetrics: ["eventCount", "daysActive", "used", "notused", "lastused"] guide: requiredFields: entityType: "guide" entityId: String supportedMetrics: ["seen", "lastSeen", "notSeen"] poll: requiredFields: entityType: "poll" entityId: String pollId: String // the poll nested under the guide supportedMetrics: ["response"] guideElement: requiredFields: entityType: "guideElement" entityId: String stepId: String // the guide step the element sits on elementId: String // the element's uiElementId, e.g. "pendo-button-a1b2c3d4" supportedMetrics: ["eventCount"] segment: requiredFields: entityType: "segment" entityId: String supportedMetrics: ["isMemberOfSegment", "isNotMemberOfSegment"] metadata: requiredFields: entityType: "metadata" entityId: String supportedMetrics: [] agent: requiredFields: entityType: "agent" entityId: String supportedMetrics: ["eventCount", "daysActive", "used", "notused", "lastused"] guideExperiment: requiredFields: entityType: "guideExperiment" entityId: String experimentId: String // the experiment, from listGuideExperiments; draft experiments are not selectable. Requires guide experiments enabled for the subscription; rules that need it are refused otherwise. variantName: Enum["A", "B"] // POSITIONAL: "A" is the experiment's first variant and "B" its second, whichever is the control. Experiments have exactly two variants. experimentConverted: Enum["None", "Yes", "No"] // only when the experiment has a conversion goal; "None" means any conversion status supportedMetrics: [] Metrics: eventCount: description: Number of events for the selected entity. requiredFields: metric: "eventCount" operator: Enum["==", "!=", ">=", "<="] threshold: Integer supportedConditions: ["withinLast", "between"] deadClicks: description: Number of dead clicks for the selected page or feature. requiredFields: metric: "deadClicks" operator: Enum["==", "!=", ">=", "<="] threshold: Integer supportedConditions: ["withinLast", "between"] errorClicks: description: Number of error clicks for the selected page or feature. requiredFields: metric: "errorClicks" operator: Enum["==", "!=", ">=", "<="] threshold: Integer supportedConditions: ["withinLast", "between"] rageClicks: description: Number of rage clicks for the selected page or feature. requiredFields: metric: "rageClicks" operator: Enum["==", "!=", ">=", "<="] threshold: Integer supportedConditions: ["withinLast", "between"] daysActive: description: Number of active days for the selected entity. requiredFields: metric: "daysActive" operator: Enum["==", "!=", ">=", "<="] threshold: Integer supportedConditions: ["withinLast", "between"] uTurns: description: Number of u-turns for the selected page. requiredFields: metric: "uTurns" operator: Enum["==", "!=", ">=", "<="] threshold: Integer supportedConditions: ["withinLast", "between"] eventTime: description: Time in minutes spent on the selected page. requiredFields: metric: "eventTime" operator: Enum["==", "!=", ">=", "<="] threshold: Integer supportedConditions: ["withinLast", "between"] response: description: Numeric poll response. Use two ANDed rules for a range. requiredFields: metric: "response" operator: Enum["==", "!=", ">=", "<="] threshold: Integer supportedConditions: ["ever", "since", "withinLast", "between"] used: description: Whether the selected feature or track event was used, optionally with a frequency threshold. requiredFields: metric: "used" supportedConditions: ["ever", "since", "withinLast", "atLeast", "atMost"] notused: description: Whether the selected feature or track event was not used. requiredFields: metric: "notused" supportedConditions: ["ever", "since", "withinLast"] lastused: description: When the selected feature or track event was last used. requiredFields: metric: "lastused" supportedConditions: ["since", "withinLast", "between"] seen: description: Whether the selected page was seen, optionally with a frequency threshold. For checking withinLast requiredFields: metric: "seen" supportedConditions: ["ever", "since", "withinLast", "atLeast", "atMost"] notseen: description: Whether the selected page was not seen. requiredFields: metric: "notseen" supportedConditions: ["ever", "since", "withinLast"] lastSeen: description: When the selected page was last seen. requiredFields: metric: "lastSeen" supportedConditions: ["since", "withinLast", "between"] isMemberOfSegment: description: Whether the visitor is a member of the selected segment. requiredFields: metric: "isMemberOfSegment" supportedConditions: [] isNotMemberOfSegment: description: Whether the visitor is not a member of the selected segment. requiredFields: metric: "isNotMemberOfSegment" supportedConditions: [] Conditions: ever: description: The metric happened at any time. requiredFields: condition: "ever" since: description: The metric happened on or after a specific date. requiredFields: condition: "since" date: DateString("yyyy-mm-dd") withinLast: description: The metric happened within a rolling time window. requiredFields: condition: "withinLast" lookbackAmount: Integer granularity: Enum["days", "weeks", "months"] between: description: The metric happened within an inclusive date range. requiredFields: condition: "between" first: DateString("yyyy-mm-dd") last: DateString("yyyy-mm-dd") atLeast: description: The metric happened at least threshold times ever requiredFields: condition: "atLeast" threshold: Integer atMost: description: The metric happened at most threshold times ever requiredFields: condition: "atMost" threshold: Integer

Permanently deletes a saved Pendo visitor segment. Confirm the segment name and id with the user before submitting - this cannot be undone from the agent. USE FOR: Removing a segment the user no longer needs. If the segment is referenced by a guide, another segment, or a saved report, the delete is rejected and the referencing entity is named in the error so the user can detach it first. Segments that back a feature flag must be deleted via the feature-flag tools. EXAMPLES: - Delete segment abc123. - Remove the "Old trial users" segment. RETURNS: - id: the deleted segment's id.

Fetch raw devlog events for a visitor or session, including HTTP request/response details, log levels, messages, and stack traces. Supports cross-tab replays via recordingSessionIds (array) to fetch devlogs across multiple browser tabs. Accepts a clipId or the individual fields (recordingSessionId, appId, visitorId, accountId, startTime, endTime) that identify a recording. When clipId is provided, the tool looks up the clip to resolve visitorId, accountId, appId, recordingSessionId, and time range automatically. If the user provides a session replay URL, parse the recordingSessionId from the URL path and query parameters (startTime, endTime, visitorId, accountId, appId) before calling this tool; for cross-tab replays, also parse the comma-separated crossTabSessions query parameter and pass the path ID plus those values in recordingSessionIds. USE FOR: Investigating developer console logs, network errors, or HTTP activity captured during a session replay. Use when the user provides a session replay URL (parse the URL yourself to extract params), a clip ID, or when the recordingSessionId, appId, visitorId, accountId, and time range for a session are already known. For cross-tab replays, pass the path recordingSessionId plus the comma-separated crossTabSessions query-param values as recordingSessionIds to fetch devlogs across all tabs in a single call. EXAMPLES: - Show me devlogs for this session replay: https://<hostname>/s/123/replay/player/abc - Show network requests captured in clip https://<hostname>/s/123/replay/clip/saved/xyz - What HTTP errors occurred during visitor john's session? - Fetch devlogs for clip ID abc-123 - Find devlog errors for account acme-corp - What API calls did this visitor make during their session? NOT FOR: Listing or discovering session replays. General page/feature/track-event analytics unrelated to a specific session recording. RETURNS: - Devlog events including subType (console/network), log level, message, stack trace, HTTP method, request URL, status code, request/response headers and bodies, recordingSessionId, and recordingId for cross-tab attribution. Limited to 100 events. The maximum time range for this tool is 31 days.

Get usage analytics for one known page, feature, or track event ID over a date range, including page views, feature clicks, event counts, and unique visitor ('people') and account counts. Returns {summary, rows}: summary has total events, unique visitors, unique accounts (and for pages/features, frustration counts; pages also include uTurnCount); rows are per-visitor or per-account breakdowns with events, time on entity, and days active, sorted and limited. Optionally filter or group by custom event properties, event-time historic metadata, or current visitor/account metadata. Optionally include metadata fields for each returned visitor or account with select. Audience can be scoped via visitorIds OR an inline segmentPipeline (mutually exclusive), and/or filtered to a single accountId. USE FOR: Scalar 'how many people viewed/clicked/used it' totals and top-N visitor or account questions over a window for one known page, feature, or track event ID. EXAMPLES: - How many page views did page X get last month? - How many distinct dashboardId values fired with feature Y in the last 30 days? - Top 20 visitors by time on page X in the last 30 days - Top 50 accounts by usage of feature Y last quarter - How many rage clicks did feature Y have last week? - Show the top 20 visitors by time on page X last month with their email and role NOT FOR: Looking up an entity ID from its name, or ranking multiple entities against each other. WORKFLOW: When the user names a page, feature, or track event but does not provide its ID, call listPagesFeaturesAndEvents to resolve the name to an ID, then call entityUsage with that ID. Do not substitute aggregateEntityUsage for this lookup: its limited ranking may omit the named entity. RETURNS: - summary: totalNumEvents, totalNumVisitors, totalNumAccounts (pages/features also: totalErrorClickCount, totalRageClickCount, totalDeadClickCount; pages also: totalUTurnCount) - summary.totalPropertyGroupCount: when groupByProperties is used, the exact number of distinct populated property groups before the row limit; the count excludes (none), which may still appear in rows - rows: events, timeOnEntityInMinutes, daysActive per visitor or account (pages/features also: errorClickCount, rageClickCount, deadClickCount; pages also: uTurnCount); per-account rows also include numVisitors; select adds requested metadata fields - property-grouped rows include propertyValues plus events, visitors, and accounts - sumEventProperty optionally adds the numeric event-property total to summary and every row, independent of the row limit for summary

Get usage of a page, feature, or track event over time. Groups events into buckets of the requested period (daily/weekly/monthly) and returns one row per bucket with all available metrics. Pages get the full set (visitors, accounts, events, timeOnEntity, averageTimeOnEntityPerVisitor (duration object {seconds, display}), errorClickCount, rageClickCount, uTurnCount, deadClickCount). Features drop the time-derived metrics and uTurnCount. Track events drop all click-level frustration counts. minEvents restricts every bucket to the visitors with at least that many events on the entity in that bucket, applied independently per bucket. For a specific entity, the query can filter or group by custom event properties or event-time historical metadata. For whole-app usage over time (not a specific entity), use the appUsageTimeSeries tool instead. USE FOR: Trend questions over a window - e.g. 'how did feature X usage change over the last 12 weeks?', 'are rage clicks on page X trending up?'. With minEvents, tracks a per-bucket event threshold over time - e.g. 'visitors using feature X at least twice a month'. EXAMPLES: - How did feature X usage change over the last 12 weeks? - Are rage clicks on page X trending up over the last 30 days? - How did visitor counts trend for this account last month? - Total page views per week across all pages over the last quarter - How many visitors used feature X at least twice in each of the last six months? RETURNS: - meta.dateRange: resolved startDate and endDate (YYYY-MM-DD) - meta.period: echoed bucket size (daily|weekly|monthly) - meta.metrics: list of metric names returned per bucket - rows: one entry per time bucket with bucket (YYYY-MM-DD or YYYY-MM), startTime (timestamp object {iso, display}), and metric values; numeric metrics zero-fill and averageTimeOnEntityPerVisitor (duration object {seconds, display}) defaults to 0s for empty buckets - property-grouped rows contain propertyValues, with one stable range-ranked group set zero-filled across every bucket - sumEventProperty optionally adds a numeric event-property total per bucket and property group, zero-filled for empty buckets

Generates AI-clustered topics from customer feedback matching the given filters. Each topic contains a name, description, and count of related insights. Use this for high-level overviews of the most common themes in a feedback subset.

Report an unsupported Pendo task as capability feedback. Use only when the user asks to report a missing capability. Records a brief task summary to help improve this connector and returns an acknowledgement; does not discover, install, or execute additional tools. Send a one-sentence summary of the task.

Returns the configuration for a given AI agent: its name, description (a human-authored summary of the agent's role and purpose, not its LLM system prompt), model preset, type, and the tool names and descriptions it has used in the specified date range. The agent config section comes from the stored agent record. The tools section is derived from runtime events in the date range and may be empty if the agent had no activity. USE FOR: Fetching the static configuration and runtime tool inventory of an AI agent. Use before analyzing issues or generating fix briefs to understand what the agent is configured to do and which tools it calls. EXAMPLES: - What is my agent's configured role and purpose? - Which tools does my agent have access to? - What model does agent X use? - Show me the full config for this agent before I debug it NOT FOR: The agent's actual LLM system prompt - this tool does not have access to that. Aggregated usage metrics, issue clusters, or conversation analysis - use the agent analytics tools for those. RETURNS: - Two labeled CSV sections: - [agent_config]: name, description (human-authored role/purpose summary, not the LLM system prompt), preset (model), type - one row. - [tools]: toolName, toolDescription - one row per tool seen in the date range; empty section if no activity found. The maximum time range for this tool is 90 days.

Get the configuration details of one page, feature, track event, or guide by ID. Does not include any usage or metrics. USE FOR: Understanding an entity before querying or acting on it. The name of any entity, reading a page's URL rules, the element a feature targets and the page it sits on, or a countable's event properties.For a guide, get its steps in order, each with its step ID and the interactive elements on it. EXAMPLES: - What is the page with ID abc123 and what URLs does it match? - Which element does feature xyz789 target, and what page is it on? - What event properties can I break down track event def456 by? - What are the step IDs and element IDs for guide ghi789? - Which buttons are on the second step of this guide and what do they do? NOT FOR: Usage, metrics or counts of any kind. Searching for an entity when you don't know its ID. RETURNS: - id, type, name, description, appIds, createdAt, lastUpdatedAt for every entity type. - eventPropertyNames: names of event properties attached to pages, features and track events. - page: rules and excludeRules (the URL rules that define the page). - feature: elementPathRules (CSS selector rules identifying the tagged element), and the pageId and pageName it is scoped to. - trackEvent: trackTypeRules (the event names that count towards it). - guide: state, launchMethod, and steps in the order they appear. Each step has id, name, and the pageId and elementPathRule it attaches to when it targets one. - guide steps[].polls: id, question and type ('PickList', 'NumberScale', 'FreeForm', 'NPSPoll', ...) per poll. For the answers given, use guidePollResponses. - guide steps[].elements: the buttons, close buttons and links on the step, each with uiElementId, text and actions ('Next Step', 'Dismiss Guide', 'External URL', 'Go to Step (2)', ...).

Retrieves key customer feedback insights extracted from raw feedback matching the given filters. Each item includes a summary, explanation, and supporting quote. Use this when the user wants to see actionable feedback insights which have been distilled from the raw customer feedback. Note: insights can also be referred to as 'highlights'

Retrieves the original, raw customer feedback matching the given filters. Each item includes id, title, description, status, and info about the account and visitor which gave the feedback. status is an object with id, name, and color fields. account is an object with id and name. visitor information is available via the createdBy and onBehalfOf objects. Each item also includes: assignee (email of the assigned user); labels, apps, and productAreas (each a list of {id, name} objects); productAreas identify the product areas the feedback is tagged to; lastUpdatedAt (epoch milliseconds, same format as createdAt); linkedIdeas (a list of the ids of ideas the feedback is linked to); importance ('Must Have', 'Nice to Have', or 'Not Interested'); and source (where the feedback originated, e.g. Portal, Salesforce, NPS). Use this when the user wants the full raw feedback, as opposed to the extracted insights or clustered topics. A maximum of 30 items will be returned, however there may be more matching the filter set.

Retrieves product ideas submitted by internal product employees which describe product enhancements and new features matching the given filters. Each item includes: id, title, description, createdAt, status, effort, impact, voteCount, accountVoteCount, and votes. Each item also includes: assignee (email of the assigned user); labels, apps, and productAreas (each a list of {id, name} objects); lastUpdatedAt (epoch milliseconds, same format as createdAt); and linkedFeedbackItems (list of feedback item IDs linked to this idea). status is an object with id, name, and color fields. voteCount is the number of positive votes cast for the idea ('Must Have' and 'Nice to Have') - use this as the primary signal of demand when ranking or comparing ideas. accountVoteCount is the number of unique accounts that cast positive votes - use this to indicate breadth of interest across customers; when accountVoteCount is much lower than voteCount, it means a small number of accounts voted multiple times. 'Not Interested' votes are excluded from voteCount, accountVoteCount, and the votes list by default. Pass includeNotInterestedVotes=true when the user asks to see 'Not Interested' votes or wants all vote counts including 'Not Interested'. Each vote includes: importance ('Must Have' or 'Nice to Have'; 'Not Interested' when includeNotInterestedVotes is true); voterId (the ID of the person who cast the vote); voterType ('Visitor' in most cases, 'User' for internal users - only mention this to the user when the value is 'User'); accountId (the account associated with the vote). A maximum of 30 items will be returned, however there may be more matching the filter set.

Get full details for a single Orchestrate email campaign by ID. Returns any orchestrate email the caller can access, including journey message emails when you already have the email ID. Use listOrchestrateEmails to discover orchestrate email campaigns; use this tool when you have a specific email ID. USE FOR: Reading full configuration for one Orchestrate email when you have its email ID. EXAMPLES: - Get email details for email 123 - Show orchestrate email config for abc - What is email xyz? - Show me full details for this orchestrate email - Get email campaign by ID NOT FOR: Discovering email IDs or browsing campaigns when you do not yet have a specific email ID. WORKFLOW: Call listOrchestrateEmails to discover email IDs, then call this tool with emailId. RETURNS: - Orchestrate email campaign configuration for agents: name, status (UI lifecycle label for standalone emails), subject, provider (Pendo, HubSpot, Marketo, or Eloqua), email settings, audience, schedule start time, and lifecycle timestamps (publishedAt, triggeredAt, executedAt) - attributes includes journeyId when the email belongs to a journey - Integration IDs (HubSpot, Marketo, Eloqua) when the email uses an external provider

Unique-visitor counts and rates for one Orchestrate email over a date range (Orchestrate Emails overview parity). Aggregates only: no visitorId and no rows. Discover emailId with listOrchestrateEmails; list who engaged with getOrchestrateEmailVisitors. USE FOR: Email-level totals and rates for one Orchestrate email in a date range. EXAMPLES: - How did email abc perform last month? - Show delivery and open rates for orchestrate email 123 - Get email metrics for email 123 between 2025-01-01 and 2025-01-31 NOT FOR: Per-visitor rows or identifying individual visitors. WORKFLOW: listOrchestrateEmails for emailId, then emailId + startDate + endDate. Optional metricsScope (see parameter). Optional segmentPipeline and blacklist narrow the audience. RETURNS: - emailId, startDate, endDate, metricsScope, metrics { sent, delivered, opened, clicked, bounced, unsubscribed, complaint } and rates on a 0-100 scale (not 0-1): openRate and clickRate are percent of delivered; deliveryRate, bounceRate, unsubscribeRate, complainRate are percent of sent; clickToOpenRate is percent of opened. Bounced is hard bounces only (Permanent). The maximum time range for this tool is 367 days.

List per-visitor email engagement for one Orchestrate email in a date range. Returns { meta, summary, rows } (see RETURNS). Each row is visitorId plus integer sent/delivered/opened/clicked/bounced/unsubscribed/complaint counts (events matching that type in range for that visitor). Counts can exceed 1 for opens/clicks; summary.numVisitors is still the distinct-visitor count for eventType, not a sum of row counts. Timestamps, URLs, and per-link click detail are unbounded and omitted. Bounce counts reflect hard bounces only (Permanent). eventType filters which visitors appear in rows (default opened); each row still includes all event-type counts. Use getOrchestrateEmailMetrics for email-level unique-visitor totals and rates without per-visitor rows. USE FOR: Listing which visitors engaged with one Orchestrate email over a date range. EXAMPLES: - Who opened orchestrate email abc last month? - List visitors who were sent email abc last month - List visitors who clicked email 123 in January - Did visitor X open email abc? - Which visitors bounced on email abc last month? NOT FOR: Email-level unique totals and rates without a per-visitor row list. WORKFLOW: Call listOrchestrateEmails for emailId, then call with emailId, startDate, endDate, and optional eventType (default opened; use sent or delivered for recipient lists). Optional visitorId narrows to one visitor. Optional segmentPipeline scopes the audience; optional blacklist controls blacklist filtering (default apply). RETURNS: - meta: { emailId, startDate, endDate, eventType } echo of request scope - summary.numVisitors: distinct visitors with at least one event matching eventType (defaults to opened when omitted); computed before the row limit and not capped by limit; may exceed len(rows) - rows[]: { visitorId, sent, delivered, opened, clicked, bounced, unsubscribed, complaint } non-negative integer event counts; sorted by visitorId; truncated at limit (default 200, max 5000); no pagination - rows are not a complete visitor list when summary.numVisitors exceeds len(rows) The maximum time range for this tool is 367 days.

Get full details for a single Orchestrate journey by ID. Returns curated journey configuration including audience, status, scheduling, and goal. Does not include the step graph, linked message/email IDs, or email settings (those live on each email; use getOrchestrateEmail). Use listOrchestrateJourneys to discover journey IDs. USE FOR: Reading journey-level configuration (audience, goal, schedule, status) for one journey when you have journeyId. EXAMPLES: - Get orchestrate journey details for journey 123 - Show me the full config for this orchestrate journey - What is orchestrate journey xyz? - Get orchestrate journey campaign by ID NOT FOR: Discovering journey IDs, browsing many journeys, or inspecting the step graph and linked message IDs. WORKFLOW: Call listOrchestrateJourneys to discover journey IDs, then call this tool with journeyId. RETURNS: - Journey configuration for agents: name, status (UI lifecycle label), audience, goal, and scheduling - Lifecycle timestamps (createdAt, updatedAt, publishedAt, firstPublishedAt) - App IDs, step count, audience targeting, and control-group settings

Get journey-level performance metrics for a single Orchestrate journey. Covers visitor entry and exit counts and - for journeys with a goal - goal attainment. Returns journey-wide aggregates only: no per-step, per-message, or per-visitor breakdown. USE FOR: Journey-wide entry, completion, and goal attainment aggregates for one Orchestrate journey. EXAMPLES: - How is orchestrate journey 123 performing? - How many visitors entered and exited orchestrate journey abc? - What is the goal attainment rate for this orchestrate journey? - Show journey metrics for journey 123 between 2025-01-01 and 2025-01-31 NOT FOR: Per-step performance, current enrollment rosters, or per-visitor engagement rows. WORKFLOW: Call listOrchestrateJourneys to discover journey IDs, then call this tool with journeyId, optionally with startDate and endDate. RETURNS: - visitorsEntered: unique visitors who entered the journey - visitorsCompleted: unique entered visitors who finished the journey by reaching an Exit step or aging out (for required-goal journeys, achieving the goal also marks completion). This is a journey-exit count, NOT goal attainment - use visitorsAchievedGoal for that. For optional-goal journeys, achieving the goal does not by itself mark a visitor completed, so an achiever is counted here only once they later reach an Exit or age out - visitorsAchievedGoal: unique entered visitors who achieved the journey goal, computed independently of completion tagging (omitted for journeys with no goal). Because attainment is tracked separately from completion, this can briefly exceed visitorsCompleted while achievers are still in-flight - it is not a stable relationship - goalAttainmentRate: visitorsAchievedGoal as a percentage of visitorsEntered on a 0-100 scale, not a 0-1 fraction - goal: the journey goal definition (type, itemType, itemId, isGoalOptional); omitted for journeys with no goal - When startDate and endDate are provided, visitorsEntered and visitorsCompleted are limited to entry/exit within that range; otherwise cumulative totals are returned - visitorsAchievedGoal and goalAttainmentRate are always cumulative (the backend goal-achievement definition is not time-bounded) and are omitted when a date range is provided; request without a date range to retrieve them The maximum time range for this tool is 367 days.

Get per-step performance metrics for a single Orchestrate journey by ID. Returns one entry per message step in execution-flow order, matching the per-step columns on the Orchestrate journey metrics page. Every count is scoped to journey entrants - visitors who entered THIS journey within the requested date range - not campaign- or guide-wide activity, so the numbers reconcile with the journey metrics page. Email steps include delivery, unique opens, unique clicks, bounces, unsubscribes, and spam complaints among those entrants. Guide steps include the journey-page guide engagement columns: viewed (entrants who saw the guide) and clicked (entrants who interacted with it), plus the derived clickRate. Survey and VOC email steps are not Orchestrate journey deliverables and carry metricUnavailableReason instead of email metrics. Other unsupported step types carry no metrics and a metricUnavailableReason instead. Use getOrchestrateJourneySteps for the full step graph, getOrchestrateEmailMetrics for a single standalone email, and getOrchestrateJourneyMetrics for journey-level goal attainment. Guide steps do not include guide-wide analytics (completions, NPS, poll breakdowns, or guide-level conversion goals). USE FOR: Per-step email or guide performance among journey entrants over a date range. EXAMPLES: - How did each step in orchestrate journey 123 perform last month? - Show per-step open and click rates for orchestrate journey abc between 2025-01-01 and 2025-01-31 - Which email step in this orchestrate journey had the best open rate? - Compare guide view and click counts across the steps of orchestrate journey 123 NOT FOR: Journey-wide entry and goal totals only, or per-visitor lists for one step. WORKFLOW: Call listOrchestrateJourneys to discover journey IDs, then call this tool with journeyId and a date range to get per-step metrics. RETURNS: - steps: an array of message steps in execution-flow order. Each step has: stepId, stepType, position, messageId, messageType, provider (plus the per-step metric fields below) - steps[].position: 0-based index of the step in the journey's execution flow across ALL nodes (start/exit/condition nodes also consume positions, so message-step positions are non-contiguous); cross-reference with getOrchestrateJourneySteps - steps[].email: per-step email metrics among journey entrants (sent, delivered, opened, clicked, bounced, unsubscribed, complaint and the derived rates on a 0-100 scale, not 0-1 fractions; openRate/clickRate are % of delivered); present only for email steps. The page surfaces opened and clicked per step; the remaining counts are the same entrant-scoped events - steps[].guide: per-step guide engagement matching the journey metrics page - viewed (journey entrants with a guide-seen event), clicked (journey entrants with a guide-interaction event), and clickRate (clicked/viewed % on a 0-100 scale, not a 0-1 fraction); present only for guide steps. Does not include guide completions, dismissals, NPS, poll breakdowns, or guide-level conversion goals; those are guide analytics, not journey per-step metrics - steps[].metricUnavailableReason: present when both email and guide are null - step_type_not_supported (unsupported step type, or survey/VOC email), or message_not_found (linked email/guide missing) - steps[]: every count is scoped to visitors who entered this journey within [startDate, endDate]; a step the caller cannot access (no view permission on the message's application) returns a zero-valued metrics block, not an error or a missing step, matching the journey metrics page - journeyId, name, status, startDate, endDate, and stepCount (number of message steps returned) are top-level fields for orientation The maximum time range for this tool is 367 days.

List per-visitor engagement for one message step of an Orchestrate journey within a date range. Scoped to journey entrants who entered this journey within [startDate, endDate] (same entrant scope as getOrchestrateJourneyStepMetrics and the journey metrics page), not standalone email sends (getOrchestrateEmailVisitors), not guide-wide analytics (guideUsage), and not current journey enrollment. Engagement events on each row must also fall within [startDate, endDate]. Returns { meta, summary, rows }. Each row is visitorId plus non-negative integer sent/delivered/opened/clicked/bounced/unsubscribed/complaint/viewed/guideClicked counts; fields that do not apply to the step type are 0; counts can exceed 1 for repeated opens/clicks while summary.numVisitors stays distinct-visitor scoped. eventType filters which entrants appear in rows (email default opened when omitted; guide default viewed when omitted). An eventType invalid for the step messageType returns invalid_request, not empty rows. summary.numVisitors is the distinct matching entrant count before limit; summary.truncated is true when numVisitors exceeds len(rows) (no pagination token yet). Survey/VOC email steps return empty rows with meta.metricUnavailableReason step_type_not_supported. Journeys not yet materialized (empty entry visitor-tag / StaticSegmentId) return empty rows with summary.numVisitors=0 and no metricUnavailableReason - not an error. A step the caller cannot view returns empty rows, not an error (unlike getOrchestrateEmailVisitors by emailId, which returns entity_not_found). USE FOR: Per-visitor engagement on one journey message step among entrants over a date range. EXAMPLES: - Who opened email <emailId> on journey <journeyId> last month? - List visitors who viewed guide <guideId> on journey <journeyId> in January - Did visitor visitor@example.com click guide <guideId> on journey <journeyId>? NOT FOR: Journey-wide aggregates or standalone email recipient lists outside journey-entrant scope. WORKFLOW: Call with journeyId, messageId (emailId or guideId - the same messageId from getOrchestrateJourneySteps or other Orchestrate tools), startDate, endDate, and optional eventType/visitorId/limit. stepId from getOrchestrateJourneySteps is accepted when messageId is unavailable. RETURNS: - meta: { journeyId, stepId, position, messageId, messageType, startDate, endDate, eventType } echo of request scope and resolved step - summary.numVisitors: distinct journey entrants matching eventType before the row limit (not capped by limit) - summary.truncated: true when summary.numVisitors exceeds len(rows); rows alone are incomplete when truncated is true (no continuation token yet) - rows[]: { visitorId, sent, delivered, opened, clicked, bounced, unsubscribed, complaint, viewed, guideClicked } non-negative integer event counts in range; irrelevant fields are 0; on guide steps guideClicked holds guide-interaction counts (getOrchestrateJourneyStepMetrics uses guide.clicked for the same concept); sorted by visitorId; capped at limit (default 200, max 5000) - meta.metricUnavailableReason when rows cannot be produced: step_type_not_supported (non-email/non-guide step, or survey/VOC email), or message_not_found (linked email/guide missing). Unmaterialized journeys (no entry segment yet) omit this field and return empty rows instead The maximum time range for this tool is 367 days.

Get the ordered step graph (nodes and edges) for a single Orchestrate journey by ID. Returns the journey's structure only: each step's type, position, and linked message IDs, plus the edges connecting the steps. Does NOT return per-step metrics (sends, opens, clicks); use getOrchestrateJourneyStepMetrics for those. Use listOrchestrateJourneys to discover journey IDs and getOrchestrateJourney for journey-level config. Before graph inserts on an existing journey, use this tool for edge ids, step ids, and journey status (inserts are allowed only in draft or review). USE FOR: One journey's step graph: ordered steps, edges (with ids for graph inserts), and message IDs on message steps. EXAMPLES: - Show the steps of orchestrate journey 123 - What messages are in this orchestrate journey? - List the steps and their order for orchestrate journey xyz - What is the structure of this orchestrate journey? - Which guide/email is sent at each step of orchestrate journey 123? WORKFLOW: Call listOrchestrateJourneys to discover journey IDs, then call this tool with journeyId to retrieve the journey's steps and how they connect. getOrchestrateJourneyStepMetrics needs only journeyId and a date range (all steps). Use messageId (emailId/guideId) from a step with getOrchestrateJourneyStepVisitors; stepId is a fallback graph node id for visitors when messageId is unknown. RETURNS: - status: UI lifecycle label for the journey (use with add-node workflows to confirm draft or review before graph inserts) - steps: journey nodes in execution-flow order (same order the Orchestrate editor renders, walking from the start node; a condition's Yes branch precedes its No branch). position is the 0-based index in that flow order - name: for message steps this is the linked email/guide's display name (as shown in the Orchestrate editor); for other steps it is the node's label and may be empty - message steps additionally include messageId, messageType (Email | Guide), provider, durationInDays (Email: days until the next step; Guide: days the guide stays active/eligible for the visitor) - edges: the connections between steps (from, to, edgeType where edgeType is Regular for linear steps or Yes/No for condition branches) - startNodeId and stepCount (number of message steps) for quick orientation

List who is in an Orchestrate journey and, for visitors still in progress, which step they are on. Who entered, who finished, and current step for visitors in the journey. Not email or guide opens/clicks. No date range. Use listOrchestrateJourneys for journeyId. Journeys that have not started yet return no rows (see meta.enrollmentAvailable). USE FOR: Listing who is in a journey: who entered, who finished, and the current step for visitors still in progress. EXAMPLES: - Who is in orchestrate journey abc right now? - Which step is visitor X on in journey abc? - List visitors still in journey abc - Who completed journey abc? - List everyone who ever entered journey abc NOT FOR: Historical performance over a date range, or email and guide open and click analytics. WORKFLOW: Call listOrchestrateJourneys for journeyId, then call with journeyId. Optional inputs: enrollmentFilter (default active), visitorId, limit (default 200, max 5000). No date range. RETURNS: - meta.journeyId, meta.journeyName, meta.journeyStatus (draft/active/paused/etc.), meta.enrollmentFilter (echo of enrollmentFilter input: active, completed, or all), meta.evaluatedAt (UTC time this snapshot was built) - meta.enrollmentAvailable: false when listing is not ready (no entry segment, no completion segment, or active journey with a future start date); true when listing works - numVisitors may still be 0 if nobody matches the filter. Invalid or missing visitor flow graph returns a tool error (no rows). - summary.numVisitors: visitors matching meta.enrollmentFilter; computed before the row limit and not capped by limit - summary.truncated: true when numVisitors exceeds len(rows); rows alone are incomplete when truncated is true (no pagination token) - rows[]: visitorId; enteredAt; completed (boolean); completedAt when completed; stepVisits[] (stepId, stepName, enteredAt) for each journey step segment tag visible at meta.evaluatedAt; when in progress and step is known: currentStepId, currentStepName, currentStepPosition, currentStepEnteredAt, messageId, messageType

List per-email engagement for one visitor across accessible Orchestrate emails in a date range. Returns { meta, summary, rows }. Each row is emailId plus integer sent/delivered/opened/clicked/bounced/unsubscribed/complaint counts for that visitor. eventType filters which emails appear in rows (default opened); each row still includes all event-type counts. Counts can exceed 1 for opens/clicks. Bounce counts reflect hard bounces only (Permanent). Only Orchestrate emails you can access are included - not every email campaign in the subscription. Use getOrchestrateEmailMetrics for email-level totals without per-visitor rows. USE FOR: Which Orchestrate emails did this visitor receive, open, click, bounce, unsubscribe, or complain about in a date range - one visitor, many emails. EXAMPLES: - Which orchestrate emails did visitor abc open last month? - List emails visitor@example.com clicked in January - Which orchestrate emails did visitor abc receive last week? - Show orchestrate emails visitor X bounced on last month NOT FOR: One email and its visitors in a date range (not all emails for one visitor). Email-level totals without per-visitor rows. Journey step visitors in a date range. Journey enrollment snapshots without a date range. WORKFLOW: Call with subId, visitorId, startDate, and endDate. Optional eventType (default opened; use sent or delivered for delivery lists). Optional segmentPipeline scopes the audience; optional blacklist controls blacklist filtering (default apply). RETURNS: - meta: { startDate, endDate, eventType } echo of request scope - summary.numEmails: distinct emails with at least one event matching eventType in range; computed before the row limit and not capped by limit; may exceed len(rows) - summary.truncated: true when summary.numEmails exceeds len(rows); rows alone are incomplete when truncated is true (no pagination token) - rows[]: { emailId, emailName?, sent, delivered, opened, clicked, bounced, unsubscribed, complaint } non-negative integer counts; sorted by emailId; truncated at limit (default 200, max 5000) The maximum time range for this tool is 367 days.

List which Orchestrate journeys one visitor is enrolled in and, for in-progress journeys, which step they are on. Returns { meta, summary, journeys[] } (not rows[]). Answers enrollment across journeys for a single visitor - who entered, who finished, current step. Not email or guide engagement in a date range. No startDate or endDate. Point-in-time snapshot at meta.evaluatedAt. Only journey definitions that are currently active or paused are in scope; enrollments on ended or archived definitions may not appear even when enrollmentFilter=all or enrollmentFilter=completed. USE FOR: Which journeys is this visitor in, how many active enrollments, and current step per journey - one visitor, all matching journeys. EXAMPLES: - Which orchestrate journeys is visitor abc in? - How many active journeys is visitor X enrolled in? - List completed orchestrate enrollments for visitor abc among active or paused journeys - Which step is visitor X on across their active orchestrate journeys? NOT FOR: Who is in one journey (not one visitor across journeys). One journey step with events in a date range. Journey-wide counts without per-journey rows. One email for one visitor in a date range. All emails for one visitor in a date range. WORKFLOW: Call with subId and visitorId. Optional enrollmentFilter (default active; same semantics as getOrchestrateJourneyVisitors) and limit on journeys[] (default 200, max 5000). No date range. RETURNS: - meta: enrollmentFilter (echo of input: active, completed, or all), evaluatedAt (UTC snapshot time) - summary.numJourneys: journeys matching enrollmentFilter before the row limit and not capped by limit - summary.numActiveJourneys: visitor mid-flow enrollments among journeys you can read (not filtered by enrollmentFilter); includes paused journey definitions; excludes future-scheduled active definitions only - summary.truncated: true when numJourneys exceeds len(journeys); journeys alone are incomplete when truncated is true (no pagination token) - journeys[]: journeyId, journeyName, journeyStatus (UI lifecycle label; scheduled when start is in the future), enteredAt and completedAt when present (omitted for legacy zero timestamps), completed when finished; when in progress: currentStepId, messageId, messageType, awaitingMessage, awaitingCondition; missingEntryTag on entry-tag anomalies (omitted from enrollmentFilter=all). Journeys where the visitor hit the entry throttle and never received an entry tag are omitted

Returns a single Pendo visitor segment by ID, including its name, definition in LLM-friendly DSL form, and optionally the guides, Orchestrate journeys, reports, compound segments, and session-replay apps that reference it. USE FOR: Inspect or read a saved segment's rules. Use when you need the current definition before modifying it, or when you need to know where a segment is in use. EXAMPLES: - Show me the definition of segment abc123. - What guides are using segment xyz789? RETURNS: - id: the segment ID. - name: human-readable segment name. - description: optional segment description (omitted if empty). - shared: whether the segment is publicly shared. - summary: plain-English description of the segment rules with entity names resolved. - definition: the segment rules in DSL form - same format accepted by create and update Segment tools. Omitted for segments authored outside the agent workflow that use features the DSL can't represent, and for segments with no rule-based definition (e.g. segment-flag or auto-managed segments). - note: only set when definition is omitted; explains why the segment can't be represented as DSL. Such segments are readable but not editable via the agent's update path. - usedBy: guides, Orchestrate journeys, reports, compound segments, and session-replay apps that reference this segment. Only present when includeUsedBy is true.

Dashboard-consistent, visitor-weighted Guide Effectiveness metrics for every guide, with optional comparison across up to 4 segments. Returns one row per guide plus an overview summary of averages across the matched set. Rates are visitor-weighted exactly as the Guide Effectiveness dashboard computes them: engagement = distinct visitors who interacted / distinct visitors who viewed; completion = distinct visitors who reached the last step / distinct visitors who reached the first step (multi-step guides only); goal adoption = converted visitors / total visitors (guides with a conversion goal only). Every rate ships with its raw numerator and denominator so sample size is visible. Aggregates cover the whole date range (no time-series buckets). Use sortBy to rank guides by a chosen metric, ascending or descending. IMPORTANT: When presenting results to the user, always state the active filters alongside the data: date range, app (if specified), segment(s), status filter, and activation filter. This lets users verify exactly which data scope produced the numbers. USE FOR: Reporting guide effectiveness that matches the Guide Effectiveness dashboard (engagement %, completion %, goal-adoption %), and comparing those rates across up to 4 segments. EXAMPLES: - How effective are our guides over the last 30 days? - Compare guide engagement and completion between the power-users and trial segments - Which guides have the lowest completion rate this month? - Show goal adoption for guides that have a conversion goal NOT FOR: Simple cross-guide ranking by raw views/dismissals (use aggregateGuideMetrics). Deep single-guide analysis with polls, NPS, or step funnels (use guideMetrics). RETURNS: - meta: resolved dateRange (startDate/endDate), the segments compared, and guideCount - summary: per-segment overview - totalViews, totalFirstTimeViews, totalVisitors, engagementRate, completionRate, goalAdoptionRate - rows: one per guide with entityId, entityName, state, launchMethod, and per-segment metric blocks (rate + raw numerator/denominator). completionRate is null for single-step guides; goalAdoptionRate is null for guides without a conversion goal

Get per-poll response distribution and per-visitor response rows for a guide's non-NPS polls. Returns {meta, summary, rows}: summary.polls lists each poll with its question and response distribution; rows are visitor-keyed and pivoted - one column per poll, null where a visitor did not respond. limit (default 10, max 200) applies to the pivoted visitor rows after joining across all polls. USE FOR: Answering questions about how visitors responded to polls in a guide: response distributions, individual visitor answers, and per-poll breakdowns. Not for NPS guide score metrics. EXAMPLES: - What were the responses to the poll in the onboarding guide? - Show me the response distribution for guide X polls - Which visitors answered 'Yes' to the helpfulness poll? - What did visitors respond to the polls in guide G last month? RETURNS: - meta.dateRange: resolved startDate and endDate (YYYY-MM-DD) - summary.polls: array of {pollId, question, distribution: [{response, count}]} for each poll. For free-text polls (open-ended responses), freeText is true and distribution is omitted because every response is unique - refer to the per-visitor rows instead. - rows: per-visitor with visitorId, accountId, browserTime, and one column per pollId (null if no response)

Get per-visitor or per-account usage breakdown for a single guide, with time-on-guide and new vs returning viewers. totalViews excludes continue-resumed guideSeen events to match the Pendo guide-details UI. For poll guides, includes per-poll response counts and response rate in summary. USE FOR: Per-visitor or per-account guide engagement - e.g. top visitors by time on guide, which accounts are completing vs dismissing, new vs returning viewer counts. With includeElements=true, also attributes each step's clicks to the individual buttons/links on it. EXAMPLES: - Top 20 visitors by time on guide X in the last 30 days - Which accounts are dismissing the onboarding guide most? - How many new vs returning viewers did the walkthrough have this month? - Show me per-visitor completion data for the tooltip guide - Is drop-off at step 3 happening via the CTA or by dismissing the guide? - Which button on the last step of the onboarding guide gets clicked most? NOT FOR: Journey-scoped per-step entrant lists for a guide message step within an Orchestrate journey (use getOrchestrateJourneyStepVisitors). Per-step aggregate guide viewed/clicked counts across all steps (use getOrchestrateJourneyStepMetrics). RETURNS: - meta.dateRange: resolved startDate and endDate (YYYY-MM-DD) - meta.experimentIds: IDs of accessible guide experiments containing this guide - summary: totalViews, completions, dismissals, uniqueVisitors, uniqueAccounts, completionRate, dismissalRate, viewsPerUser, avgTimeOnGuide, medianTimeOnGuide (duration objects {seconds, display}), newViewers, returningViewers, isPoll - summary.polls (poll guides only): per-pollId uniqueResponseCount and totalResponseCount - rows: per-visitor or per-account rows with views, completions, dismissals, daysActive, lastSeen (timestamp object {iso, display}), timeOnGuide (duration object {seconds, display}) (per-account rows also include uniqueVisitors), sorted and limited - steps (only when includeSteps or includeElements is true): per-step array in guide step order, each with stepId, name, uniqueVisitors, viewCount. Single-step guides return one entry; step views include continue-resumed views to match the Pendo step funnel. - steps[].elements (only when includeElements=true): the step's clicked buttons/links, highest clicks first, each with uiElementId, text, type ('Button', 'Close Button', 'Link', 'Task Item', 'Image', 'Swiped Left', 'Swiped Right' or 'Unknown'), actions (what the click does, e.g. 'Next Step', 'Dismiss Guide', 'External URL', 'Go to Step (2)'), clicks, uniqueVisitors, percentOfStepClicks. Compare an element's uniqueVisitors against its step's uniqueVisitors to attribute drop-off. Only clicked elements appear, and elements since removed from the step are still counted. The maximum time range for this tool is 367 days.

Links an existing feedback item to an existing idea, associating the customer evidence with the feature request. Votes from the feedback item are propagated to the idea's vote count. USE FOR: When the user explicitly asks to link, connect, or associate a feedback item with an idea, or vice versa EXAMPLES: - Link feedback abc123 to idea xyz456 - Connect this feedback to that idea - Associate idea xyz456 with feedback abc123 RETURNS: - Confirmation that the idea and feedback item have been linked