MCP Tools Reference

Complete reference guide for all Luciq MCP Server tools. Explore available tools, their parameters, and how to use them for AI-powered debugging.

Luciq MCP provides 35 tools across 16 areas. Most are read-only; four write tools (update_bug, apm_funnel_write, write_alerts, and write_incidents) can modify data in your workspace. All tools use JSON-RPC 2.0 over Streamable HTTP and respect your workspace permissions (RBAC).

Area

Tools

What they cover

App Context

list_applications

Which apps you can work with

Crash-Level Debugging

list_crashes, crash_details, crash_patterns, crash_diagnostics

Crash groups, their details & full debugging payload

Occurrences Deep-dive

list_occurrences_tokens, get_occurrence_details

Single crash instances (per device/session)

Stability Beyond Crashes (App Hangs)

list_app_hangs

App freezes / UI hangs

Performance (APM)

apm_list_groups, apm_group_view, apm_occurrence, apm_funnel_events, apm_funnel_write

Network, launches, screen loads, flows, frame drops, funnels

User-Reported Issues (Bugs)

list_bugs, bug_details, update_bug

User-reported issues via Luciq SDK (read & triage)

User Sentiment & Store Ratings

list_reviews

User reviews and ratings

Surveys

list_surveys, survey_details

In-app surveys, NPS, and their responses

App Health Overview

app_insights

Aggregated cross-product health snapshot

Users

user_summary

One end user's devices, sessions, APM occurrences, crashes & bugs in a single call

Session Replay

list_session_replays

Recorded user sessions with dashboard deep links

Issues & Opportunities

list_issues, ai_issue_details, ai_issue_occurrence_details, list_opportunities, opportunity_details

Unified Issues surface (across crashes, APM, AI-detected issues & bugs) and prioritized Opportunities

Alerts & Rules

read_alerts, write_alerts, read_incidents, write_incidents

Alert rules and the triggered alerts (incidents) they produce

Documentation

search_documentation, get_documentation_page

Search and fetch published Luciq documentation pages

Skills

get_luciq_skills

Step-by-step agent skills that orchestrate the tools above for multi-step workflows

Releases

app_version_adoption

Session and user adoption of app versions, plus daily rollout trend

Read vs. write. Four tools change data: update_bug (a bug's status, priority, tags, or duplicate state), apm_funnel_write (create, update, or delete a funnel), write_alerts (create, update, or delete an alert rule), and write_incidents (resolve or reopen a triggered alert). Every other tool only reads. One read tool, crash_diagnostics, has a side effect: it computes and caches a crash-analysis payload on demand (so it isn't a pure read), but it never changes your crash, bug, or app data. Write actions respect your RBAC permissions and are audit-logged like any dashboard action.

Each tool exposes MCP tool annotations so your client can reason about its behavior. All tools are readOnlyHint: true except the write tools (update_bug, apm_funnel_write, write_alerts, write_incidents, marked readOnlyHint: false) and crash_diagnostics (readOnlyHint: false, destructiveHint: false, because it triggers an on-demand computation). Every tool is scoped to your Luciq workspace and is openWorldHint: false, except search_documentation, get_documentation_page, and get_luciq_skills, which reach outside your workspace — the first two query Luciq's public documentation site, get_luciq_skills serves Luciq's public agent-skills content — and are marked openWorldHint: true.

The details and context for each tool are detailed below.

1. App Context

`1.1 list_applications`

What it does

Returns all applications accessible to your account.

Use this when

Setting up your MCP config and not sure which slug / mode to use.
You work across multiple apps and want a quick list in the IDE.

Parameters

None required.

Optional:

platform: ios, android, react_native, flutter
limit, offset

Key Fields

slug — Identifier used in most tools
name — Display name
token — Needed for the Reviews tool
platform — App platform
mode — App environment
created_at — Timestamp

Usage Examples

“List all my applications.”
“Show only iOS applications.”
“Which apps do I have access to?”

2. Crash-Level Debugging

`2.1 list_crashes`

What it does

Shows crash groups for an app: how often they happen, how many users they affect, and basic cause.

Use this when

You want to know “what should we fix first?”
You’re scanning production for new, recent, or high-impact crashes.

Required

slug application slug
mode beta, production, staging, alpha, qa, development

Useful Filters

date_ms (time window, defaults to the last 7 days when omitted)
status_id (1 open, 2 closed, 3 in progress)
devices, os_versions
app_versions
current_views, teams
platform — IOS, ANDROID, DART (Flutter), JAVASCRIPT (React Native)
type — CRASH, ANR, OOM, NON_FATAL (which apply depends on platform: Android supports CRASH, ANR, NON_FATAL; iOS supports CRASH, OOM, NON_FATAL; React Native and Flutter support all four)
subtype — CRITICAL, ERROR, WARNING, INFO (only when NON_FATAL is included in type)
feature_flags — scope to crashes seen under a given feature flag or experiment. Use the bare flag name when no variant was set (e.g. private_mode), or flag_name -> variant when a variant was set (e.g. checkout_flow -> external_request).
user_attributes — filter by custom user attributes reported by the SDK (e.g. Country, Plan). Each attribute name maps to one or more conditions using the operators contain, not_contain, equal, or not_equal; conditions on the same attribute combine, and different attributes are AND-ed together. Attribute-name keys are case-sensitive and must match the SDK-reported name exactly; condition values are matched case-insensitively.
user_uuids — keep only crashes that affected these users, identified as the SDK reported them and matched exactly (up to 100)

Sorting & Pagination

sort_by — last_occurred_at (default), occurrences_counter, affected_users_counter, max_app_version, min_app_version, severity, first_occurred_at
direction — asc or desc (default desc)
limit (default 20, max 50), offset

Key Fields

number — Crash ID
exception — Main exception message
crash_cause — File/function of failure
crash_type — Fatal or non-fatal
occurrences_counter — Total occurrences
affected_users_counter — Unique users affected
app_version — Version where it occurred
last_occurred_at — Latest timestamp
severity / level — Severity indicators

Usage Examples

“Show production crashes for the last 7 days.”
“List crashes for version 3.0.1.”
“Show open crashes only.”
“What are the top Android crashes?”
“Show crashes seen under the checkout_flow feature flag.”
“Show crashes from users in Egypt on the free plan.”

`2.2 crash_details`

What it does

Shows everything we know about a single crash (stack, versions, status, severity).

Use this when

You need to investigate or reproduce the crash.

Required

slug application slug
mode beta, production, staging, alpha, qa, development
number crash number

Key Fields

exception — Full exception
exception_name — Exception class/type
crash_cause — Main file/line
stack_frames[] — Parsed stack trace
min_app_version, max_app_version — Affected versions
crash_type — Fatal/non-fatal
status_id — Current status
team — Assigned team
sdk_version — SDK version
package / ndk_info / path — Platform extra fields

Usage Examples

“Show details for crash #12.”
“Explain the stack trace for crash 45.”
“Which file caused crash #17?”
“What versions are affected by crash 5?”

`2.3 crash_patterns`

What it does

Groups a crash’s occurrences by device, app version, OS, view, etc. to show where it clusters.

Use this when

You want to understand where a crash is concentrated.
You want to answer: “Is this crash mostly on Pixel 8? On Android 14? On version 3.0.4?”

Required

slug application slug
mode beta, production, staging, alpha, qa, development
number crash number

Useful Filters

pattern_key — which dimension to group by: app_versions (default), devices, oses, current_views, app_status, experiments
date_ms (time window)
app_versions, devices, os_versions
sort_by — occurrences_count (default), last_seen, first_seen; direction — asc or desc (default desc)

Key Fields

value — Group label (device, OS, version, etc.)
occurrences_count — Occurrences in that bucket
first_seen, last_seen — Timestamp range

Usage Examples

“Break down crash #20 by device.”
“Show OS patterns for crash #12.”
“Which views are tied to crash #3?”
“Group crash #5 by app versions.”

`2.4 crash_diagnostics`

What it does

Returns the full debugging payload for a single crash in one call: stack trace, device metrics, distributions (OS, device model, app version), and the screen flows leading up to the crash. It’s the fastest way to hand an AI assistant everything it needs to reason about a crash.

Use this when

You ask your assistant to fix, debug, or investigate a specific crash.
You want the stack trace plus the surrounding context (which devices, OS versions, and user journeys are affected) without chaining several calls.

Required

slug application slug
mode beta, production, staging, alpha, qa, development
number crash number

Notes

This analysis is computed on demand. If the response comes back with status: "generating", the payload is still being prepared, simply ask again after a moment and it will return the full result.

Usage Examples

“Help me fix crash #42.”
“Give me the full diagnostics for crash #18.”
“What led up to crash #7 and which devices are hit hardest?”

3. Occurrences Deep Dive

`3.1 list_occurrences_tokens`

What it does

Lists individual occurrences of a crash as ULID tokens, so you can pick specific ones to inspect.

Use this when

You want to inspect or debug specific sessions.
You want to drill down from a crash group to specific user/device sessions.

Required

slug application slug
mode beta, production, staging, alpha, qa, development
number crash number

Useful Filters

app_status (foreground / background)
devices
os_versions
app_versions
experiments
current_views
date_ms (date range, defaults to the last 7 days when omitted)
user_uuids — keep only occurrences from these users, identified as the SDK reported them and matched exactly (up to 100). Useful for narrowing a crash down to the occurrences a specific user hit, so the returned tokens resolve to that user's device, OS, and logs.

Key Fields

states_tokens[] — ULIDs for occurrences
total_occurrences — Count of matches

Usage Examples

“List all occurrences for crash #28.”
“Show only foreground occurrences.”
“Which iOS 17 devices experienced crash 5?”
“List occurrences from Pixel devices.”

`3.2 get_occurrence_details`

What it does

Shows the exact context of one crash occurrence: device, OS, memory, storage, app status, user, and log URLs.

Use this when

You need to reproduce or understand a single session.

Required

slug application slug
mode beta, production, staging, alpha, qa, development
number crash number
ulid state/occurrence ULID token (obtained from list_occurrences_tokens)

Key Fields

state.fields:

app_version — Version at crash moment
device, os — Device info
current_view — Active screen
app_status — Foreground/background
memory, storage — Resource usage
country, city — Location
screen_size, density — Display metrics
reported_at — Timestamp
email, user_name — User identity

logs:

Downloadable compressed logs
Experiment logs

user:

Email, UUID, name

exception_message:

Exception for this specific occurrence

Usage Examples

“Show occurrence details for token X.”
“Which device caused this occurrence?”
“Show logs for the earliest occurrence of crash #8.”
“What view was active during this crash?”

4. Stability Beyond Crashes (App Hangs)

`4.1 list_app_hangs`

What it does

Shows grouped hang events (UI freezes) for your application.

The server automatically chooses:

FATAL_UI_HANG for iOS
ANDROID_FATAL_HANG for Android
Both for cross-platform apps

Use this when

You want to find “the app froze for me” issues, not just crashes.

Required

slug application slug
mode beta, production, staging, alpha, qa, development

Useful Filters

date_ms (defaults to the last 7 days when omitted), status_id (1 open, 2 closed, 3 in progress)
app_versions, devices, os_versions
platform — IOS, ANDROID, DART, JAVASCRIPT
current_views, teams
user_uuids — keep only hangs that affected these users, identified as the SDK reported them and matched exactly (up to 100)
sort_by — last_occurred_at (default), occurrences_counter, affected_users_counter, max_app_version, min_app_version, severity, first_occurred_at; direction — asc/desc (default desc)

The hang type (FATAL_UI_HANG / ANDROID_FATAL_HANG) is chosen automatically by platform, you don't pass it. Unlike list_crashes, hangs don't take type, subtype, or feature_flags filters.

Key Fields

number — Hang ID
crash_type — Hang classification
exception — Hang summary
crash_cause — Where it froze
occurrences_counter — Total hangs
affected_users_counter — Unique impacted users
platform, app_version
last_occurred_at — Recent hang timestamp

Usage Examples

“Show hangs in production for the last 14 days.”
“List iOS hangs only.”
“Which hangs are still open?”
“What views cause most UI hangs?”

5. Performance (APM)

The APM tools cover the full Application Performance Monitoring surface. Every APM tool takes a required metric parameter that selects the performance domain:

network — network requests
launch — app launches (cold/warm)
flows — custom traces / flows
screen_loading — screen load times
frame_drop — UI frame drops
funnels — multi-step conversion funnels (apm_list_groups / apm_group_view only)

The first three tools form a drill-down: rank groups (apm_list_groups) → inspect one group’s panels (apm_group_view) → inspect individual occurrences (apm_occurrence). The two funnel tools manage funnels themselves: discover pickable events (apm_funnel_events) → create, update, or delete a funnel (apm_funnel_write). Filters and sort keys are scoped per metric, the server rejects a key that doesn't apply to the chosen metric (e.g. failure-rate filters are network-only). Your AI assistant picks valid combinations from the schema, so you can describe what you want in plain language.

`5.1 apm_list_groups`

What it does

Ranks APM groups worst-first for an app (e.g. slowest endpoints, slowest launches, slowest screens), paginated and filtered.

Use this when

You want to know “what’s our worst-performing endpoint / screen / launch?”
You’re scanning for performance regressions in a release.

Required

slug application slug
mode beta, production, staging, alpha, qa, development
metric network, launch, flows, screen_loading, frame_drop, funnels

Useful Filters

date_ms (defaults to the last 7 days when omitted), app_version, platform (ios, android)
apdex, apdex_change, count, dissat_count (numeric ranges; not applicable to launch)
95th_percentile_ms, 50th_percentile_ms (not applicable to launch or frame_drop)
total_failure_rate, client_failure_rate, server_failure_rate (network only)
view_type (screen_loading only), teams (screen_loading / frame_drop), key_metric, group_name, user_attributes
user_uuids — keep only groups with occurrences from these users, identified as the SDK reported them and matched exactly (up to 100)
occurrence_classification — restrict to occurrences in these Apdex classes: satisfying, tolerable, frustrating (rejected for funnels; use session_classification there instead)

Sorting & Pagination

sort by one key, direction asc/desc. Valid keys: apdex, apdex_change, occurrences, dissat_count (all metrics); p95, p50 (all except frame_drop); failure_rate (network only); frozen_frames_percent, slow_frames_percent (frame_drop only)
limit (default 5, max 100), offset

Usage Examples

“List my worst app launches.”
“Show the slowest network endpoints this week.”
“Which screens have the lowest Apdex?”

`5.2 apm_group_view`

What it does

Fetches the panels for a single APM group (charts, tables, and summary) in one call.

Use this when

You’ve identified a problem group and want the full breakdown (trends, distributions, summary metrics).

Required

slug, mode, metric
views — which panels to return. Available panels (which apply depends on the metric): summary, apdex_chart, throughput_chart, spans_table, dimensions (all metrics); outliers (all except frame_drop); failure_rate (network only); stages_breakdown (launch, screen_loading); web_vitals (screen_loading only); frames_distribution, delayed_frames (frame_drop only). Panels not valid for the metric are dropped and reported back in ignored_views.
A group identifier: either group_uuid (preferred, from apm_list_groups) or group_url (with optional method for network endpoints)

Useful Filters

date_ms (defaults to the last 7 days when omitted)
user_uuids — match only occurrences from these users, identified as the SDK reported them and matched exactly (up to 100). Not supported by the spans_table / frames_distribution views, which return error: filter_unsupported_for_view instead.
occurrence_classification — restrict to occurrences in these Apdex classes: satisfying, tolerable, frustrating (rejected for funnels; use session_classification there instead). Same spans_table / frames_distribution limit as user_uuids.

Usage Examples

“Show me the breakdown for the slowest endpoint.”
“Give me the summary panel for this screen-load group.”

`5.3 apm_occurrence`

What it does

Inspects individual occurrences within an APM group: the single worst occurrence, a specific occurrence by token, or a paginated list.

Use this when

You want the concrete, individual sample behind an aggregate, e.g. the exact slowest request or launch.

Required

slug, mode, metric
selector — worst, by_token, or list
A group identifier: group_uuid (preferred) or group_url (+ optional method)
token when selector=by_token

Useful Filters

date_ms (defaults to the last 7 days when omitted)
user_uuids — match only occurrences from these users, identified as the SDK reported them and matched exactly (up to 100)
occurrence_classification — restrict to occurrences in these Apdex classes: satisfying, tolerable, frustrating

Usage Examples

“Show me the single worst occurrence for this endpoint.”
“List the slowest launches in this group.”

`5.4 apm_funnel_events`

What it does

Lists the pickable events (network and screen-loading groups) you can use as steps when building or editing a funnel.

Use this when

You’re about to create or update a funnel and need the valid step candidates and their identifiers.

Required

slug, mode

Optional:

event_type — restrict the picker to network or screen_loading; when omitted, returns the top results across both types
q — case-insensitive substring filter on the event name
limit — per-type cap on returned events (default 20, max 25)

Usage Examples

“What events can I build a funnel from?”
“Find checkout-related network events I can use as funnel steps.”

`5.5 apm_funnel_write`

What it does

Creates, updates, or deletes a funnel, chosen via the operation parameter. Each step can be an OR group of up to 5 events — a session completes the step when any of them matches. This is a write tool.

Use this when

You want to define or maintain a conversion funnel without leaving your IDE — then analyze it with apm_list_groups / apm_group_view using metric=funnels.

Required

slug, mode
operation — create, update, or delete
For create: name + steps (2–20 ordered steps)
For update: ulid and at least one of name / steps (when steps is given it replaces the full ordered set of steps)
For delete: ulid

steps is an ordered array of 2–20 steps. Each step is an array of 1–5 event objects — an OR group where the step completes as soon as any one of its events occurs. Each event has a type (user_event, network, or screen_loading); for type=user_event, provide name, and for network / screen_loading, provide the group ulid obtained from apm_funnel_events.

Usage Examples

“Create a funnel from login → add to cart → checkout.”
“Create an ‘add to cart’ step that matches whether it happened from the product page or the cart drawer.”
“Replace the last step of this funnel with the new payment screen.”
“Delete the old onboarding funnel.”

6. User-Reported Issues

`6.1 list_bugs`

What it does

Shows user-reported bugs (reported via Luciq’s SDK), with simple filtering.

Use this when

You want to see user-submitted issues.
You’re scanning for new or high-priority bugs in a release.

Required

slug application slug
mode beta, production, staging, alpha, qa, development

Useful Filters

status_id: 1 New, 2 Closed, 3 In Progress
priority_id: -1 N/A, 1 Trivial, 2 Minor, 3 Major, 4 Blocker
app_version, os_versions, devices
platform: ios, android (cross-platform apps only)
device_class: high, medium, low (Android apps only)
category / no_category, tag / no_tag (include/exclude; each filter is a list of OR-groups that are AND-ed together)
type, experiments, email (with an equal / not_equal / contain / not_contain operator)
duplicate_type: single, manual_master, automatic_master, manual_duplicate, automatic_duplicate — omitted defaults to single + masters only (merged duplicates hidden); pass all 5 values to include them
forwarded_to / not_forwarded_to (e.g. jira)
reported_at (range, in Unix epoch milliseconds; defaults to the last 7 days when omitted), title (free-text search)
has_description: true only bugs with a description, false only bugs without one
user_uuids — keep only bugs reported by these users, identified as the SDK reported them and matched exactly (up to 100). To search by reporter email use email instead.
user_attributes filters by custom user attributes attached to the reporter. Keys are attribute names as set by the SDK (e.g. plan), and each maps to one condition using the operators contain, not_contain, equal, or not_equal. Attributes are AND-ed together, and attributes the application has never reported are ignored rather than rejected. There is no call that lists an app's available attribute names, so filter by one you already know.

Sorting & Pagination

sort_by (default reported_at), direction asc/desc (default desc)
limit (default 20, max 50), offset

Key Fields

number — Bug ID
title — User-entered title
email — Reporter
priority_id, status_id
reported_at, last_activity
categories
duplicated_bugs_count

Usage Examples

“Show new bugs for version 3.3.”
“List all open bugs.”
“Show bugs reported today.”
“Which bugs are highest priority?”

`6.2 bug_details`

What it does

Returns detailed bug information including logs, user data, and device metadata.

Use this when

You need full context to reproduce the bug.

Required

slug application slug
mode beta, production, staging, alpha, qa, development
number bug number

Key Fields

Top-level:

title, type — Bug title & type
priority_id, status_id — Bug priority & status
reported_at, last_activity — When it was reported, last update time
email, tags — Reporter’s email, tags
categories, team — Assigned categories, team

state.fields (context):

os, device, country, city
app_version, sdk_version
current_view
screen_size, density
bundle_id
user_attributes
duration (session length)

state.logs:

user_steps, network_log, sessions_profiler, etc. with url and is_empty_array.

Usage Examples

“Show details for bug #468.”
“What steps did the user take?”
“Which device was used?”
“Show the network log for this bug.”

`6.3 update_bug`

This is a write tool. It changes the state of a bug in your workspace, exactly as if you’d edited it in the dashboard. It respects your RBAC permissions and is audit-logged. It’s the only Luciq MCP tool that modifies data.

What it does

Updates a bug’s status, priority, or tags, or marks/unmarks it as a duplicate of another bug, directly from your IDE. This lets you complete bug triage end-to-end without switching to the dashboard.

Use this when

You’ve investigated a bug (via bug_details) and want to act on it: close it, reopen it, reprioritize it, retag it, fold it into another bug as a duplicate, or detach it from its master.

Required

slug application slug
mode beta, production, staging, alpha, qa, development
number bug number

Optional (provide at least one of `status_id`, `priority_id`, `tags`, or `action`)

status_id: 1 New, 2 Closed, 3 In Progress
priority_id: -1 N/A, 1 Trivial, 2 Minor, 3 Major, 4 Blocker
tags: the tags to apply. How they are applied is controlled by tag_action (default append). By default the listed tags are added while your existing tags are kept — the call no longer replaces the full set, so you don’t need to read and re-send the current tags to add or remove one. (Setting tags requires an additional bugs.tags.modify permission.)
tag_action: append (default), replace, or remove — controls how tags is applied. Only meaningful together with tags.
- append — add the listed tags, keeping existing ones.
- remove — remove only the listed tags, keeping the rest.
- replace — set tags as the full list, removing any existing tag not listed. Pass [] with replace to clear all tags.
action: mark_as_duplicate or unmark_as_duplicate.
- mark_as_duplicate merges this bug into a master, requires original_bug_number. Side effect: this bug’s occurrences move into the parent group and its status/priority are overwritten by the parent’s.
- unmark_as_duplicate detaches this bug from its master, restoring it to a standalone bug.
- action cannot be combined with status_id or priority_id in the same call.
original_bug_number: the master bug’s number. Required when action is mark_as_duplicate; ignored otherwise.

Usage Examples

“Close bug #468.”
“Set bug #51 to Major priority and tag it checkout, regression.”
“Add the needs-info tag to bug #77.” (appends, keeping existing tags)
“Remove the stale tag from bug #77.”
“Replace bug #90’s tags with just triaged.”
“Reopen bug #120.”
“Mark bug #205 as a duplicate of bug #198.”
“Unmark bug #205 as a duplicate.”

7. User Sentiment & Store Ratings

`7.1 list_reviews`

What it does

Lists app reviews (e.g., from store/native/custom prompts) with filters for rating, version, country, etc.

Use this when

You want to correlate user feedback with app stability.
You want to see 1–2 star reviews for a release.
You’re checking if a performance or crash issue shows up in user feedback.

Required

slug application slug
mode beta, production, staging, alpha, qa, development

Useful Filters

date_ms.gte / lte
app_version
rating – array of star ratings [1–5]
country
prompt_type – custom, native, app_store
os (for cross-platform)

Key Fields

title, body — Review content
star_rating — 1–5 stars
username, country
app_version, device
date
has_suspected_sessions — Linked to stability issues
has_custom_suspected_sessions

Usage Examples

“Show 1-star reviews for version 3.0.”
“List negative reviews from the US.”
“Show native prompt reviews only.”
“What are the most recent app store reviews?”

8. Surveys

`8.1 list_surveys`

What it does

Lists the surveys configured for an app (custom surveys, NPS, and app-store prompts), newest-first, with their status.

Use this when

You want to see which surveys are live, paused, or in draft.
You’re looking up a survey’s id before pulling its responses.

Required

slug application slug
mode beta, production, staging, alpha, qa, development

Useful Filters

status: 0 Draft, 1 Published, 2 Paused
type: 0 Custom, 1 NPS, 2 App Store

Usage Examples

“List my published surveys.”
“Show all NPS surveys.”
“Which surveys are currently paused?”

`8.2 survey_details`

What it does

Returns a survey’s questions, response statistics, and a page of individual responses (filterable and paginated, mirroring the dashboard).

Use this when

You want to read what users answered, e.g. NPS scores and verbatims for a specific survey.

Required

slug application slug
mode beta, production, staging, alpha, qa, development
id survey id (from list_surveys)

Useful Filters

nps (filter by NPS score 0–10)
search_words (free-text search across response values, name, and email)
response_status: 0 Open, 1 Closed
app_versions, devices, os_versions, countries, platforms, locale
date_ms

Notes

Responses are paginated at 25 responses per page via the page parameter.

Usage Examples

“Show me the responses for survey 312.”
“What are the NPS detractor comments on my NPS survey?”
“Show survey responses from the last 30 days.”

9. App Health Overview

`9.1 app_insights`

What it does

Returns an aggregated, cross-product health snapshot for one app in a single call. Each section is returned under its own key:

crashes — non-fatal crash counts
bugs — bug report totals
apm — APM key metrics (network, launches, screen loads, flows)
monitoring — stability rates (crash-free sessions, ANR, OOM, app hangs)

A section whose product isn't included in your plan is omitted entirely (its key is absent). A section that is enabled but temporarily unavailable (e.g. a data-retention limit or a failing service) returns an error object instead of data, while the other sections still return.

Use this when

You want a fast “how healthy is this app right now?” overview before drilling into a specific area.

Required

slug application slug
mode beta, production, staging, alpha, qa, development

Optional

filters.date_ms (time window)
filters.app_version

Usage Examples

“Give me a health overview for my app.”
“How is the app doing this week, crashes, bugs, and performance?”
“Show app insights for version 3.4.”

10. Users

`10.1 user_summary`

What it does

Returns a single end user's summary for an app in one call: devices, OS versions, and app versions seen; sessions and session replays; per-metric APM occurrences split by satisfying/tolerable/frustrating; and the crashes and bug reports that user hit.

Use this when

You're investigating one person's experience end-to-end instead of scanning aggregate data.
Someone reports a problem and you want their devices, crashes, bugs, and performance in a single call rather than chaining several tools.

Required

slug application slug
mode beta, production, staging, alpha, qa, development
user_uuid the user ID as reported by the SDK, matched exactly

Optional

period_days — length of the window ending now, in days (default 7, max 56)

Key Fields

user_identifier, identifier_type — The ID you queried and how it's classified upstream
has_data — false with zeroed counts means the ID matched no user, not that the user has no activity
period — gte_ms, lte_ms, days for the resolved window
overview — app_versions, devices, os_versions seen, plus per-combination profiles
sessions — count, with_session_replay
performance — Per-metric occurrence counts split by Apdex class (e.g. network.frustrating)
crashes — occurrences, distinct
bugs — occurrences, distinct

Notes

user_uuid is matched exactly against the SDK-reported ID. It only resolves an email if the app reports emails as user IDs — to look someone up by email, use list_session_replays with filters.user instead.

Usage Examples

“Give me a summary for user abc-123 over the last 30 days.”
“What crashes and bugs has this user hit?”
“Show devices, OS versions, and sessions for user xyz-789.”

11. Session Replay

`11.1 list_session_replays`

What it does

Lists recorded sessions for an app, newest first. Every row carries a session_replay_url deep link into the dashboard.

Use this when

You want to browse or filter recorded sessions instead of jumping straight to a specific crash or bug.
You're looking up a user by email — this is the only tool that resolves emails directly (user_summary and list_bugs match the reported user ID instead).

Required

slug application slug
mode beta, production, staging, alpha, qa, development

Useful Filters

Filters mirror the dashboard's Session Replay filters; every filter is AND-ed with the others, values inside one filter are OR-ed.

filters.user — end users whose sessions to return, identified by user ID or email (the dashboard's "Search by User ID, Email" filter). Mix both freely, e.g. ["user-1234", "[email protected]"]; any value containing @ is matched against the user's email instead of their ID (up to 50 values).
filters.date_ms (session start time; defaults to the last 7 days when omitted)
filters.app_versions — REQUIRED format "<version> (<build>)", e.g. "4.1.2 (5)"; a bare "4.1.2" is rejected
filters.devices, filters.os_versions
filters.session_class — Apdex classification of the whole session: satisfying, tolerable, frustrating, crashing
filters.issues — ai_issues, fatal_crash, ndk_crash, anr, oom, fatal_hang, app_termination, non_fatal_crash
filters.countries (use "N/A" for sessions with no country)
filters.experiments — feature-flag/experiment value, e.g. private_mode or checkout_flow -> external_request
filters.user_attributes — custom user attributes reported by the SDK; each attribute maps to one equal/not_equal condition (not an array, unlike list_crashes), and attributes are AND-ed together

Sorting & Pagination

Results are always newest-first; there's no sort_by.
pagination_size (default 20, max 50), pagination_token — pass the previous response's pagination_token verbatim for the next page; an empty pagination_token in a response means there are no more sessions. Keep filters identical between pages.

Key Fields

session_id — Session identifier
user — name, email as reported by the SDK
session_type — Apdex classification of the session
app_version, device, os, platform
start_time, duration
ui — anrs, app_hangs counts for the session
session_replay_url — Dashboard deep link; always surface it. Absent on rows without a session_id.
pagination_token, count

Usage Examples

“Show me recent frustrating sessions in production.”
“Find the session replay for [email protected].”
“List sessions on iPhone 11 that hit a fatal crash.”
“Show sessions for app version 4.1.2 (5).”

12. Issues & Opportunities

These tools cover Luciq's product qualitative surface, mirroring the dashboard. Issues is the unified view of everything affecting your app across sources (crashes, APM, AI-detected visual issues and broken functionality, and bugs), ranked by Apdex impact. Opportunities group related signals into prioritized, actionable items you can track to closure.

`12.1 list_issues`

What it does

Lists an app's Issues, a unified surface that spans crashes, APM, AI-detected visual issues, broken functionality, and bugs in one ranked list. Results are ranked by Apdex impact by default. Which sources appear depends on the app's plan: each source is only included when the plan enables it.

Use this when

You want a single, cross-source view of “what's hurting this app the most?” rather than scanning crashes, APM, and bugs separately.
You're triaging by user impact and want issues ranked by Apdex.

Required

slug application slug
mode beta, production, staging, alpha, qa, development

Useful Filters

date_ms (time window; the range between gte and lte must be at least 24 hours)
search_tokens (free-text, e.g. exception text or group name)
app_version
teams
platform — IOS, ANDROID, DART (Flutter), JAVASCRIPT (React Native)
apm_types — networks, traces, launches, screen_loadings, frame_drops
crashes_types — CRASH, ANR, OOM, NON_FATAL
ai_issues_types — visual_issue, broken_functionality
bugs_types — accepted but not currently enforced by the backend
apdex_severity — high, medium, low, no_impact

Sorting: sort_by (apdex_impact, occurrences_counter) and sort_direction (asc, desc). Set top_issues: true to return a smaller curated list of the most impactful issues.

Key Fields

source — Which surface the issue came from (crash, APM, visual issue, broken functionality, bug)
apdex_impact — Apdex impact used for ranking
apdex_severity — high, medium, low, no_impact
occurrences_counter — Total occurrences
app_version — Version where it occurred
platform — Issue platform

Notes

This tool uses per-source pagination: the response returns a pagination token for each source (APM, crashes, visual issues, broken functionality, bugs). Pass those tokens back in the pagination object to fetch the next page per source.
When a result's source is a visual_issue or broken_functionality AI-detected issue, drill into it with ai_issue_details (and then ai_issue_occurrence_details for a specific occurrence's screenshots).

Usage Examples

“Show me the top issues for my app this week.”
“List the highest-Apdex-impact issues in production.”
“Show only crash and APM issues for version 3.4.”
“What are the most impactful issues right now?”

`12.2 ai_issue_details`

What it does

Gets the details of a single AI-detected visual_issue or broken_functionality issue: the group summary plus a page of the occurrences grouped under it. The issue's description comes from the group's first occurrence.

Use this when

You've spotted an AI-detected issue in list_issues and want its full occurrence history.
You're paging through occurrences for one AI-detected issue.

Required

slug application slug
mode beta, production, staging, alpha, qa, development
issue_type visual_issue or broken_functionality
id AI issue id (uuid), obtained from list_issues

Sorting & Pagination

occurrences_limit — maximum occurrences to return per page (default 20)
occurrences_pagination_token — opaque token for the next page; omit on the first call, then pass back the value from the previous response unchanged

Key Fields

occurrences — Returned newest first, metadata only (no screenshots); each carries a number to pass to ai_issue_occurrence_details

Usage Examples

“Show me the occurrences for this AI-detected issue.”
“Get details for the broken functionality issue with id [uuid].”
“Show the next page of occurrences for this visual issue.”

`12.3 ai_issue_occurrence_details`

What it does

Gets a single visual_issue or broken_functionality occurrence's details together with its screenshots.

Use this when

You've found an occurrence via ai_issue_details and want to see what happened, screenshots included.

Required

slug application slug
mode beta, production, staging, alpha, qa, development
issue_type visual_issue or broken_functionality
number occurrence number, obtained from ai_issue_details (only unique within an issue_type)

Key Fields

Screenshots are returned directly in the tool result as images, in capture order, not embedded in the text payload.

Usage Examples

“Show me the screenshots for occurrence 12 of this visual issue.”
“What happened in this broken-functionality occurrence?”

`12.4 list_opportunities`

What it does

Lists an app's Opportunities with their status, ranked by priority (highest first), then by recency. Opportunities group related signals into prioritized, actionable items.

Use this when

You want to see the prioritized, actionable items for an app rather than raw issues.
You're reviewing what's open, in progress, or already handled.

Required

slug application slug
mode beta, production, staging, alpha, qa, development

Useful Filters

status — open, in_progress, closed, dismissed
priority — 1, 2, 3, 4, unset
team_id — Team ULID, or unassigned

Pagination via limit (default 20, max 50) and offset.

Key Fields

id — Opportunity ID (use with opportunity_details)
status — open, in_progress, closed, dismissed
priority — Priority level
team — Assigned team

Usage Examples

“List my open opportunities.”
“Show the highest-priority opportunities first.”
“Which opportunities are assigned to my team?”
“Show unassigned opportunities.”

`12.5 opportunity_details`

What it does

Returns a single opportunity's details: status, priority, source counts, assigned team, and its timeline. Use the id from list_opportunities.

Use this when

You've spotted an opportunity in list_opportunities and want the full context: what it groups, who owns it, and how it has progressed.