> ## Documentation Index
> Fetch the complete documentation index at: https://docs.appsignal.com/llms.txt
> Use this file to discover all available pages before exploring further.

# AppSignal MCP workflows

These examples show how AppSignal MCP tools compose together for common tasks. For each tool's parameters, see the [MCP Tool Reference](/mcp/reference).

<h3 id="investigating-a-production-error">
  Investigating a production error
</h3>

1. List recent open exceptions: *"Show me all open incidents in production from the last 24 hours"*
2. Get full details on a specific incident: *"Get the details for incident #847 including the stack trace"*
3. Pull traces to see what happened at the code level: *"Get the error traces for incident #847"*
4. Document your findings: *"Add a note to incident #847: investigated the database timeout — connection pool was exhausted during peak traffic"*
5. Resolve it: *"Close incident #847"*

<h3 id="profiling-a-slow-action">
  Profiling a slow action
</h3>

1. Get a performance overview: *"Which actions are slowest in the web namespace right now?"*
2. Pull traces for the worst offender: *"Get traces for BlogPostsController#index from the last hour"*
3. Inspect the span tree to find the bottleneck: *"Show me the full span tree for trace abc123"*
4. Drill into a specific span: *"Get the details for span def456 in trace abc123"*

<h3 id="triaging-a-batch-of-incidents">
  Triaging a batch of incidents
</h3>

1. *"Find all open incidents in the background namespace from the last week"*
2. *"Mark incidents #120, #121, and #122 as work in progress and assign them to Jana"*
3. *"Close all incidents related to ActionMailer — they were fixed in the last deploy"*

<h3 id="searching-logs-during-an-incident">
  Searching logs during an incident
</h3>

1. *"Find all error logs from the last hour"*
2. *"Show me logs where message contains 'timeout' on web-1 between 14:00 and 15:00"*
3. *"Get fatal logs from the payments source over the last 30 minutes"*

<h3 id="reconstructing-a-customer-journey">
  Reconstructing a customer journey
</h3>

When a user reports a problem, the answer is usually scattered across logs, errors, and traces from multiple sources. An agent can stitch that timeline together for you.

1. *"Get all logs for user.id=4321 from production over the last 24 hours, across every source"*
2. *"Narrow that to the window between 14:00 and 15:30 UTC and group the results by source"*
3. *"List any open exception incidents from production in that same window — anything tagged with user.id=4321?"*
4. *"For incident #903, pull the error traces and walk the span tree"*
5. *"Summarize what happened: which actions did this user hit, what failed, and where did the error originate?"*

This pulls from `get_log_lines`, `get_exception_incidents`, and `get_traces` in a single conversation. The final summary step is where MCP earns its keep — the agent composes the narrative, not you.

<h3 id="setting-up-log-processing">
  Setting up log processing
</h3>

AppSignal executes log line actions during ingestion, in the order you define. A common pattern is to emit a metric, create a trigger, then filter — this ensures AppSignal captures the signal before discarding the log line.

1. Check the existing log line actions and their order: use `get_app_resources` with `sections: ["log_line_actions"]`
2. *"Create a metrics action that counts log lines where severity is error as log.error\_count"*
3. *"Add a trigger action that fires an alert when severity is fatal"*
4. *"Add a filter to drop all health check log lines"*
5. *"Reorder those actions so the metrics action runs first, then the trigger, then the filter"*

<h3 id="creating-an-anomaly-detection-trigger">
  Creating an anomaly detection trigger
</h3>

1. Discover available metrics: *"What metrics are available for my production app?"*
2. Check available tags: *"What tags are available for response\_time?"*
3. Create the trigger: *"Create a trigger that fires when mean response time exceeds 500ms for more than 5 minutes, and notify the Slack #alerts channel"*
4. Archive an old trigger once replaced: use `get_triggers` to find the ID first, then *"Archive the old response\_time trigger"*

<h3 id="building-a-monitoring-dashboard">
  Building a monitoring dashboard
</h3>

1. *"What metrics are available for my production app?"*
2. *"Create a dashboard called 'API Health' in production"*
3. *"Add a line chart of p95 response time by action to the API Health dashboard"*
4. *"Add an area chart of error rate broken down by namespace"*
5. *"Add a Big Number tile showing the mean of response\_time, formatted as a duration"*

***