Skip to main content
These examples show how AppSignal MCP tools compose together for common tasks. For each tool’s parameters, see the MCP Tool Reference.

​
Investigating a production error

  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”

​
Profiling a slow action

  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”

​
Triaging a batch of incidents

  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”

​
Searching logs during an incident

  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”

​
Reconstructing a customer journey

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.

​
Setting up log processing

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”

​
Creating an anomaly detection trigger

  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”

​
Building a monitoring dashboard

  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”