> For the complete documentation index, see [llms.txt](https://docs.luciq.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.luciq.ai/product-guides-and-integrations/product-guides/ai-features/luciq-mcp-server/use-cases-and-workflows.md).

# Use Cases & Workflows

Real-world workflows for mobile debugging with Luciq MCP. Each workflow is a sequence of natural language prompts you can use directly in your IDE.

***

## Investigate a Production Crash

When a crash spikes in production, go from alert to root cause without leaving your editor.

**Prompt sequence:**

1. "Show me the top 5 crashes in production this week"
2. "Get details for crash #\[number] - show me the stack trace"
3. "Show crash patterns by device for this crash"
4. "List the most recent occurrences"
5. "Show occurrence details for \[token] - what device and OS?"

{% embed url="<https://streamable.com/ekvoh8>" %}

**Tools used:** `list_crashes` > `crash_details` > `crash_patterns` > `list_occurrences_tokens` > `get_occurrence_details`

**What you get:** The full picture - from which crashes matter most, to the exact stack trace, to which devices and OS versions are affected, down to the specific session that triggered it.

***

## Diagnose and Fix a Crash

When you want your assistant to actually help fix a crash, hand it the full debugging payload in one shot.

**Prompt sequence:**

1. "Show me the top crashes in production this week"
2. "Help me fix crash #\[number] - give me the full diagnostics"
3. "Based on the stack trace and affected screens, what's the likely root cause?"

**Tools used:** `list_crashes` > `crash_diagnostics`

**What you get:** `crash_diagnostics` returns the stack trace, device metrics, distributions (OS, device model, app version), and the screen flows leading up to the crash in a single call, so your assistant can reason about root cause without chaining multiple queries.

***

## Investigate a Performance Regression

A screen or endpoint got slower after a release. Find the worst offenders and drill in.

**Prompt sequence:**

1. "List my worst app launches this release" (or "slowest network endpoints", "slowest screen loads")
2. "Show me the breakdown for the worst one"
3. "Show me the single worst occurrence in that group"

**Tools used:** `apm_list_groups` > `apm_group_view` > `apm_occurrence`

**What you get:** A performance drill-down across any APM metric (`network`, `launch`, `screen_loading`, `flows`, `frame_drop`) - from ranked groups, to a single group's panels, down to the individual slowest sample.

***

## Daily App Health Check

Start your morning with a quick stability check across all your apps.

**Prompt sequence:**

1. "List my applications"
2. "Give me a health overview for \[app name] this week" (one `app_insights` call returns crashes, bugs, APM, and stability rates together)
3. "Drill into the crashes from that overview, show me the worst ones"
4. "Show me recent 1-star reviews"

**Tools used:** `list_applications` > `app_insights` > `list_crashes` > `list_reviews`

**What you get:** A fast overview of crashes, hangs, performance, and user sentiment - the `app_insights` snapshot is a single call that pulls every product's key metrics at once, so you can spot what moved before drilling in.

***

## Triage by User Impact (Issues & Opportunities)

Instead of scanning crashes, APM, and bugs separately, start from the unified, impact-ranked view.

**Prompt sequence:**

1. "Show me the top issues for \[app name] this week, ranked by Apdex impact"
2. "Focus on the crash and APM issues only"
3. "Now show my open opportunities, highest priority first"
4. "Give me the full details for opportunity \[id] - what signals does it group and who owns it?"

**Tools used:** `list_issues` > `list_opportunities` > `opportunity_details`

**What you get:** A single cross-source list of what's hurting the app most (crashes, APM, AI-detected visual issues and broken functionality, and bugs), then the prioritized Opportunities that group those signals into trackable, owned items. Which sources appear depends on what your plan enables.

***

## Regression Check After a Release

Just shipped a new version? Verify nothing broke.

**Prompt sequence:**

1. "Show crashes for version \[X.Y.Z] in production"
2. "Are any of these crashes new to this version?"
3. "Show crash patterns by app version for crash #\[number]"
4. "Are there any app hangs specific to version \[X.Y.Z]?"
5. "Show 1-2 star reviews for version \[X.Y.Z]"

**Tools used:** `list_crashes` (with version filter) > `crash_patterns` > `list_app_hangs` > `list_reviews`

**What you get:** A release-specific stability report showing whether your new version introduced regressions or new crash patterns.

***

## Triage User-Reported Bugs

Review and prioritize bug reports submitted by your users through the Luciq SDK.

**Prompt sequence:**

1. "Show me open bugs for \[app name] sorted by priority"
2. "Get details for bug #\[number]"
3. "What device and OS was the user on?"
4. "Are there any crashes related to the same screen or view?"
5. "Set bug #\[number] to Major priority and tag it `checkout`, `regression`"
6. "Close bug #\[number]" or "Mark bug #\[number] as a duplicate of bug #\[other]"

**Tools used:** `list_bugs` > `bug_details` > `list_crashes` (cross-reference by view) > `update_bug`

**What you get:** Full bug context including device info, user steps, and whether the bug correlates with known crashes - then you act on it without leaving the IDE. `update_bug` is a write tool: it changes the bug's state in your workspace (status, priority, tags, or duplicate), respects your RBAC permissions, and is audit-logged.

***

## Analyze App Store Sentiment

Monitor what users are saying about your app and correlate feedback with stability data.

**Prompt sequence:**

1. "Show me recent app store reviews"
2. "Filter to 1-2 star reviews from the last month"
3. "Are there any crashes that could explain the negative reviews?"
4. "Show me reviews for version \[X.Y.Z] specifically"

**Tools used:** `list_reviews` > `list_crashes` (cross-reference)

**What you get:** User sentiment tied to app versions, with the ability to cross-reference negative reviews against crash data.

***

## Read NPS and Survey Feedback

Pull what users actually said in your in-app surveys, without opening the dashboard.

**Prompt sequence:**

1. "List my published surveys"
2. "Show me the responses for my NPS survey"
3. "What are the detractor comments (scores 0-6)?"
4. "Filter those to the last 30 days and version \[X.Y.Z]"

**Tools used:** `list_surveys` > `survey_details`

**What you get:** A survey's questions, response stats, and individual verbatims, filterable by NPS score, version, device, and date, so your assistant can summarize themes from raw responses.

***

## Device-Specific Investigation

A QA engineer reports issues on a specific device model. Investigate with MCP.

**Prompt sequence:**

1. "Show crashes on Samsung Galaxy S24 in production"
2. "Break down crash #\[number] by OS version"
3. "Show occurrence details for a Galaxy S24 occurrence"
4. "Are there app hangs on this device?"

**Tools used:** `list_crashes` (with device filter) > `crash_patterns` > `get_occurrence_details` > `list_app_hangs`

**What you get:** A device-specific stability profile showing which crashes and hangs concentrate on that hardware.

***

## Pre-Release QA Check

Before pushing to production, check the stability of your beta or staging builds.

**Prompt sequence:**

1. "Show crashes in the beta environment for the last 7 days"
2. "Are there any app hangs in staging?"
3. "Show me bug reports from beta testers this week"
4. "What are the top crashes by occurrence count in beta?"

**Tools used:** `list_crashes` (beta/staging mode) > `list_app_hangs` > `list_bugs`

**What you get:** A pre-release stability snapshot so you can catch issues before they reach production.

***

## Manage Alerts and Rules

Create, edit, and delete alerts (rules) directly from your IDE, without a trip to the dashboard. Describe the alert you want in natural language and let the agent author a valid rule, groom noisy ones, or fill coverage gaps.

**Example prompts:**

* "Notify me whenever a new bug is reported by any user on Luciq"
* "Alert me when any crash gets more than 50 occurrences within an hour on Luciq"
* "I'm getting too many triggered alerts from Luciq, groom my alerts to reduce noise"
* "Analyze my app's health, and set up the missing alerts in Luciq that I need to maintain the app's health"

**Tools used:** `read_alerts` > `write_alerts` (plus `read_incidents` / `write_incidents` for triggered-alert cleanup)

**What you get:** The agent reads your app's alert catalog before writing, so it never guesses an id, threshold, or unstated value, and confirms before any state-changing operation.

{% hint style="success" %}
To get the best results managing alerts, install our latest [Agent Skills](/product-guides-and-integrations/product-guides/ai-features/agent-skills.md), which include [`luciq-alert-config`](/product-guides-and-integrations/product-guides/ai-features/agent-skills/luciq-alert-config.md), [`luciq-alert-gaps`](/product-guides-and-integrations/product-guides/ai-features/agent-skills/luciq-alert-gaps.md), and [`luciq-alert-noise`](/product-guides-and-integrations/product-guides/ai-features/agent-skills/luciq-alert-noise.md). They greatly improve the agent's performance on alert and rule prompts.
{% endhint %}

***

## Get Answers from the Docs

Ask your assistant SDK integration or feature questions and get answers grounded in the current published documentation instead of the assistant's training data.

**Prompt sequence:**

1. "How do I mask network data on Android?"
2. "Show me the full page on network logging"
3. "Now show me the equivalent guide for iOS"

**Tools used:** `search_documentation` > `get_documentation_page`

**What you get:** Answers grounded in the live docs.luciq.ai content - search finds the relevant pages with previews, and fetching the full page gives your assistant the complete markdown to work from (steps, code samples, and all).

***

## Tips for Better Results

{% hint style="info" %}
**Be specific about time ranges.** "Last 7 days" or "since March 1" gives more targeted results than "recent."

**Specify the environment.** "Production" vs "beta" vs "staging" helps target the right data.

**Use app names.** If you have multiple apps, mention which one by name or slug.

**Chain your queries.** Start broad (`list_crashes`) then narrow (`crash_details` > `crash_patterns` > occurrence). Each answer gives you context for the next question.

**Ask follow-up questions.** MCP tools work well in conversation. Your AI assistant retains context from previous queries in the same session.
{% endhint %}

***

## What's Next?

* [**Tools Reference**](/product-guides-and-integrations/product-guides/ai-features/luciq-mcp-server/mcp-tools-reference.md) - Full documentation for all 29 tools with parameters and response fields
* [**FAQ & Troubleshooting**](/product-guides-and-integrations/product-guides/ai-features/luciq-mcp-server/faq-and-troubleshooting.md) - Common issues and how to resolve them


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.luciq.ai/product-guides-and-integrations/product-guides/ai-features/luciq-mcp-server/use-cases-and-workflows.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.