MCP Tool Reference

AppSignal MCP exposes 24 tools across seven areas: error incidents, performance, anomaly detection, logging, metrics, dashboards, and app discovery. Tools include both read and write operations.

Workflows

These examples show how tools compose together for common tasks.

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 something went wrong, the answer is usually scattered across logs from multiple sources, plus errors and traces. Stitching that timeline together by hand is the kind of work the logging UI can't do for you, but an agent can.

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"

Tool reference

Every tool takes app_name and app_environment to identify which application to target. Both are matched case-insensitively, so MyApp/Production and myapp/production resolve to the same application.

App discovery

get_applications

Get all AppSignal applications the user has access to.

Returns applications in app_name/app_environment format. Use this first to discover available applications before calling other tools.

No parameters required.

get_app_resources

Discover available resources in an AppSignal application — namespaces, dashboards, users, notifiers, log sources, log line actions, and deploy markers.

Particularly useful when setting up triggers, assigning incidents, or understanding the structure of an application.

Error incidents

get_exception_incidents

List and search AppSignal exceptions and errors.

Use this to get an overview of recent exceptions, search within a time period, find incidents by state, or check which incidents need attention. Returns 50 incidents per page.

get_incident

Get detailed information about an AppSignal incident.

Returns current state, assignment, first and last occurrence, error messages, stack traces, or anomaly alert details. Supports exception and anomaly incidents.

update_incidents

Bulk update incidents for an AppSignal application.

Use this to change incident state, update severity, or assign and unassign team members across multiple incidents at once. Use get_app_resources with sections: ["users"] to find user IDs for assignment.

create_incident_note

Create a note on an AppSignal incident. Markdown is supported.

Use this to add comments, status updates, investigation findings, or resolution steps.

Performance

get_performance

Performance overview: sample-based performance incidents and slow actions from traces.

For standard Ruby and Elixir apps, returns sample-based performance incidents. For apps that also send OpenTelemetry traces, additionally returns a ranked list of actions with mean duration, throughput, and error rate. Apps being migrated to OpenTelemetry may return both.

Follow-up tools: use get_incident to inspect a specific performance incident, get_traces to pull sample traces for a slow action, and update_incidents to change state, severity, or assignees.

get_traces

Query performance and error traces, inspect span trees, and view span details.

Supports two trace types:

• Performance traces — identified by namespace and action_name. Use these to investigate slow requests.
• Error traces — identified by digest. Get the digest from get_incident or get_exception_incidents, then use it here to see the actual error traces.

Each trace type supports three modes:

1. List mode — find traces and get trace IDs. Provide namespace + action_name, or digest.
2. Tree mode — pass a trace_id to see all spans as a compact tree.
3. Span detail mode — pass trace_id and span_id for full span attributes, events, and resource info.

The typical workflow is: list traces → inspect a trace tree → drill into a span.

Anomaly detection

get_anomaly_incidents

List and search AppSignal anomaly detection alerts.

Returns 50 alerts per page, including timestamps and values for each alert.

get_triggers

List anomaly detection triggers for an AppSignal application.

Returns active (non-archived) triggers with their complete configuration — conditions, notifiers, and dashboard links. Use this to find trigger IDs before calling manage_trigger or archive_trigger.

manage_trigger

Create or update an anomaly detection trigger.

Triggers are immutable. When you update a trigger, AppSignal archives the existing one (closing all its alerts and incidents) and creates a new one with a version chain reference. Provide all fields for both create and update operations.

Use get_metric_names and get_metric_tags to discover available metrics and fields. Use get_app_resources(sections: ["notifiers"]) to find notifier IDs.

archive_trigger

Archive an anomaly detection trigger and close all associated alerts and incidents.

Idempotent — no-ops if the trigger is already archived. Use get_triggers to find the trigger ID.

Logging

get_log_lines

Query log lines using AppSignal's expression syntax.

Supports exact match, contains, negation, numeric comparisons, boolean logic, and nested attributes. Returns up to 100 lines per call, newest-first by default. For large time ranges, split into multiple calls and iterate forward.

Query syntax:

Available fields: severity, hostname, group, message, and any custom attributes.

manage_log_line_action

Create or update a log line action.

Log line actions run during log ingestion, in the order you define. There are three types:

• filter — discards matching log lines so they are never stored or processed further
• trigger — fires alerts and incidents when the query matches
• metrics — extracts counter, gauge, or distribution metrics from matching log lines

Execution order matters: if a filter discards a log line, subsequent actions never see it. A common pattern is to place metric and trigger actions before any filter actions. Use reorder_log_line_actions to change the order after creation.

New actions are appended at the end of the execution order.

reorder_log_line_actions

Change the execution order of log line actions.

Provide action IDs in the desired sequence. Any action IDs not included are appended at the end in their current relative order. Use get_app_resources(sections: ["log_line_actions"]) to find IDs and see the current order.

delete_log_line_action

Permanently delete a log line action.

Use get_app_resources(sections: ["log_line_actions"]) to find the action ID first.

Metrics

discover_metrics

Discover available metric categories and their metrics for monitoring.

Use this to get an overview of what you can monitor, or drill into a specific category. Also accepts a dashboard:id reference to show metrics used in a specific dashboard.

get_metric_names

Get the names of all metrics for the given application.

Returns metric names as a comma-separated string. Use these as input to get_metric_tags, get_metrics_timeseries, and get_metrics_list.

get_metric_tags

Get the tags and metric type (Gauge, Counter, etc.) for a specific metric.

Use the results to build valid queries with get_metrics_timeseries and get_metrics_list.

get_metrics_timeseries

Get a timeseries for a metric in the given application.

Returns point-by-point data for a given time range, metric type, and tag combination. Tag values support wildcard matching with *.

get_metrics_list

Get an aggregated value for a metric over a time range.

Returns a single aggregated value rather than a point-by-point timeseries. Useful for summary views.

Dashboards

manage_dashboard

Create or update an AppSignal dashboard.

This tool manages dashboard metadata only (title and description). Use create_dashboard_visual and update_dashboard_visual to add charts.

create_dashboard_visual

Add a new chart or graph to an existing dashboard.

Use discover_metrics or get_metrics_list to find available metrics first.

update_dashboard_visual

Update an existing chart or graph on a dashboard.

All fields are optional except the identifiers. Unspecified fields keep their current values. If metrics is provided, it replaces all existing metrics on that visual.

Token permissions

Each MCP token has configurable permissions by toolset: app, exceptions, performance, metrics, anomalies, dashboards, logging. Each toolset can be set to read, write, or disabled.

Tokens can also be scoped to specific applications and set to automatically expose new tools as they are added.

To generate a token:

1. Select your profile icon.
2. Go to Account Settings.
3. Select MCP Tokens to create a new token.

Missing a tool?