MCP Tool Reference - AppSignal Documentation

AppSignal MCP exposes 23 tools across eight product areas: app discovery, error incidents, performance, anomaly detection, check-ins, logging, metrics, and dashboards. A 24th tool, get_more_tools, lets an agent ask for additional capabilities or file feedback about how a task went. You don’t call these tools yourself. You describe what you want in your agent’s chat, for example: “which actions are slowest in production right now?” The agent will pick the appropriate tool and fill in its parameters. This reference is here so you can check whether a capability exists at all, and name a parameter when the agent reaches for the wrong one. For examples of how these tools compose together for a task, see AppSignal MCP workflows.

Tool reference

Most tools take 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. If the name doesn’t match an application you can access, the tool returns an error naming what you asked for and suggesting the closest matches, so the agent can retry with a valid name. Every tool also takes a context string so the agent can say why it is making the call. Agents usually fill that in automatically, so the tables below focus on the task-specific parameters. manage_trigger, manage_log_line_action, and manage_check_in_trigger each cover several operations behind a required action parameter, so which of their fields you need depends on the action you pass. In those tables, yes (upsert) marks a field required on every upsert, and yes (create) one required only when the upsert creates something rather than updating it.

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 task-specific parameters beyond context.

`get_app_resources`

Discover available resources in an AppSignal application — namespaces, dashboards, users, notifiers, log sources, log views, log line actions, deploy markers, and uptime monitors. Particularly useful when setting up triggers, assigning incidents, or understanding the structure of an application.

Parameter	Required	Description
`app_name`	yes	Name of the AppSignal application.
`app_environment`	yes	Environment (e.g. `production`, `staging`).
`sections`	no	Sections to retrieve: `users`, `notifiers`, `namespaces`, `dashboards`, `log_sources`, `log_line_actions`, `log_views`, `deploy_markers`, `uptime_monitors`. Returns all if not specified.
`deploy_marker_namespace`	no	Show only the deploys in this namespace (e.g. `web`).
`deploy_marker_revision`	no	Show only the deploys with this revision. A short prefix works (e.g. `a1b2c3d`).

The deploy_markers section returns up to 100 recent deploys, each with its full revision and the time range it was live. Narrow it with deploy_marker_namespace or deploy_marker_revision. To find the errors a deploy introduced, pass its revision to get_exception_incidents (or use revision: "last" for the most recent deploy). The uptime_monitors section lists each monitored URL and its settings. Uptime itself is not stored — it is computed from metrics, so query the uptime_monitor_error_count counter with get_metrics_timeseries to calculate it.

Check-ins

These two tools cover the same monitors as process monitoring: cron monitors that expect a run on a schedule, and heartbeat monitors that expect a continuous signal.

`get_check_in_triggers`

List check-in (cron and heartbeat) monitors, or inspect one monitor with its recent runs. Use this to see which scheduled jobs or services are expected to report in, check whether they are on time, or find a monitor ID before updating it.

Parameter	Required	Description
`app_name`	yes	Name of the AppSignal application.
`app_environment`	yes	Environment.
`id`	no	Inspect one check-in trigger by ID. Returns that trigger’s configuration and recent runs.
`identifier`	no	Inspect one check-in trigger by identifier, such as `nightly-export`.
`kind`	no	Filter the trigger list by kind: `cron` or `heartbeat`. Ignored when `id` or `identifier` is provided.
`state`	no	Filter one trigger’s recent runs by state: `new`, `started`, `finished`, `missed`, `late`, or `unexpected`.
`page`	no	Page number (1-based, defaults to 1). Paginates either the trigger list or one trigger’s run history.

`manage_check_in_trigger`

Create, update, or delete a check-in monitor. Unlike anomaly detection triggers, check-in monitors are updated in place. When you update one, omitted fields keep their current values.

Parameter	Required	Description
`app_name`	yes	Name of the AppSignal application.
`app_environment`	yes	Environment.
`action`	yes	`upsert` to create or update, or `delete` to remove a monitor.
`id`	yes (`delete`)	Existing monitor ID. On `delete`, required unless you pass `identifier` instead. On `upsert`, updates that monitor.
`identifier`	yes (create)	Human-facing identifier, such as `nightly-export`. Can also be used to look up or delete an existing monitor.
`kind`	yes (create)	`cron` or `heartbeat`.
`syntax`	yes (cron)	Cron expression, such as `0 0 * * *`. Required whenever the monitor’s `kind` is `cron`, including when an update switches it to `cron`.
`wait_time_minutes`	yes (create)	Grace period before a run is marked missed.
`timezone`	no	Timezone for a cron expression. Defaults to `UTC` on create.
`description`	no	Description of what the monitor tracks.
`notifier_ids`	no	Notifier IDs to alert when a check-in is missed or late. Use `get_app_resources(sections: ["notifiers"])`.

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.

Parameter	Required	Description
`app_name`	yes	Name of the AppSignal application.
`app_environment`	yes	Environment.
`namespaces`	no	Comma-separated list of namespaces to filter by (e.g. `web,background`).
`query`	no	Case-insensitive keyword search across the exception name and action name. Supports `*` wildcards.
`start`	no	Start of time range in ISO 8601 format. Defaults to the most recent deploy if omitted.
`end`	no	End of time range in ISO 8601 format. Required if `start` is provided.
`states`	no	Comma-separated states: `open`, `closed`, `wip`. Returns all states if not specified.
`revision`	no	Scope to a specific deploy. Use `"last"` for the most recent deploy, or pass a revision hash or short prefix. Ignored when `start` and `end` are provided.
`page`	no	Page number (1-based, defaults to 1).
`per_page`	no	Number of incidents per page. Defaults to 50.

`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.

Parameter	Required	Description
`app_name`	yes	Name of the AppSignal application.
`app_environment`	yes	Environment.
`number`	yes	The numeric incident ID shown in AppSignal URLs and incident lists.

`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.

Parameter	Required	Description
`app_name`	yes	Name of the AppSignal application.
`app_environment`	yes	Environment.
`incidents`	no	List of incident numbers to update (e.g. `[123, 456, 789]`).
`state`	no	`open`, `closed`, or `wip` (work in progress).
`severity`	no	`critical`, `high`, `low`, `none`, `informational`, or `untriaged`.
`assign_users`	no	List of user IDs to assign as handlers.
`unassign_users`	no	List of user IDs to remove from the incident.

`manage_incident_note`

Create or update a note on an AppSignal incident. Markdown is supported. Use this to add comments, status updates, investigation findings, or resolution steps. Include a full GitHub issue URL in the note to link that issue to the incident, when the app has GitHub configured.

This tool was previously named create_incident_note. The old name still works as an alias, so existing prompts and configurations keep working.

Parameter	Required	Description
`app_name`	yes	Name of the AppSignal application.
`app_environment`	yes	Environment.
`number`	yes	The numeric incident ID.
`content`	yes	Note content. Markdown formatting is supported.
`id`	no	ID of an existing note to update. Omit to create a new note. You can only edit notes you authored.

Performance

`get_performance`

Performance overview: sample-based performance traces and slow actions from traces. For standard Ruby and Elixir apps, returns sample-based performance traces. 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 traces for a slow action, and update_incidents to change state, severity, or assignees.

Parameter	Required	Description
`app_name`	yes	Name of the AppSignal application.
`app_environment`	yes	Environment.
`namespaces`	no	Comma-separated namespaces. Applies to both performance traces and OpenTelemetry actions.
`start`	no	Start of time range in ISO 8601 format. Defaults to the most recent deploy for sample-based traces, or 24 hours ago for OpenTelemetry actions.
`end`	no	End of time range in ISO 8601 format. Required if `start` is provided.
`states`	no	Comma-separated states: `open`, `closed`, `wip`. Applies to sample-based incidents only.
`revision`	no	Scope to a specific deploy. Use `"last"` for the most recent deploy, or pass a revision hash. Ignored when `start`/`end` is provided. Use `get_app_resources(sections: ["deploy_markers"])` to list available revisions.
`page`	no	Page number for sample-based incidents (1-based, defaults to 1). OpenTelemetry actions are returned as a complete ranked list.
`per_page`	no	Number of incidents per page (defaults to 50). Paginates sample-based incidents only.

`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:

List mode — find traces and get trace IDs. Provide namespace + action_name, or digest.
Tree mode — pass a trace_id to see all spans as a compact tree, along with the root span’s metadata and a duration breakdown. The breakdown reports self time by category: what the spans in each category spent working, rather than waiting on a child.
Span detail mode — pass trace_id and span_id for full span attributes, events, and resource info. Long attribute values are truncated at 500 characters. Database query text is the exception, and comes through in full up to 10,000 characters.

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

Parameter	Required	Description
`app_name`	yes	Name of the AppSignal application.
`app_environment`	yes	Environment.
`namespace`	yes (performance)	The namespace to search in (e.g. `web`, `background`). Not needed for error traces.
`action_name`	yes (performance)	The action name (e.g. `BlogPostsController#index`). Not needed for error traces.
`digest`	yes (error)	The exception incident digest. Switches to error trace mode. Cannot be combined with `namespace` or `action_name`.
`trace_id`	no	Switches to tree mode. Returns all spans for this trace.
`span_id`	no	Switches to span detail mode. Requires `trace_id`.
`include_sensitive`	no	In span detail mode, include HTTP headers, request environment, request parameters, and session data. Defaults to `false`.
`start`	no	Start of time range in ISO 8601 format. Defaults to 24 hours ago. Performance traces only.
`end`	no	End of time range in ISO 8601 format. Defaults to now. Performance traces only.
`min_duration_ms`	no	Filter to traces slower than this threshold in milliseconds. List mode only.
`limit`	no	Maximum number of traces to return (1–100, default 25). List mode only.

Anomaly detection

`get_anomaly_incidents`

List and search AppSignal anomaly detection alerts. Returns 50 alerts per page, including timestamps and values for each alert.

Parameter	Required	Description
`app_name`	yes	Name of the AppSignal application.
`app_environment`	yes	Environment.
`state`	no	`open`, `closed`, `warmup`, `cooldown`, or `archived`. Returns all states if not specified.
`trigger_id`	no	Filter to incidents from a specific trigger. Use `get_triggers` to find trigger IDs.
`page`	no	Page number (1-based, defaults to 1).
`per_page`	no	Number of alerts per page. Defaults to 50.

`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.

Parameter	Required	Description
`app_name`	yes	Name of the AppSignal application.
`app_environment`	yes	Environment.
`metric_name`	no	Filter by metric name (e.g. `response_time`, `error_rate`).
`kind`	no	Filter by trigger kind.
`tags`	no	Filter by tags, e.g. `[{"key": "hostname", "value": "web-1"}]`.
`page`	no	Page number (1-based, defaults to 1).

`manage_trigger`

Create, update, or archive 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 replacement. 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.

This tool replaces the older archive_trigger flow. The old name still works as a backward-compatibility alias, but manage_trigger is the primary tool.

Parameter	Required	Description
`app_name`	yes	Name of the AppSignal application.
`app_environment`	yes	Environment.
`action`	yes	`upsert` to create or update, or `archive` to stop monitoring and close associated alerts and incidents.
`metric_name`	yes (`upsert`)	The metric this trigger monitors.
`kind`	yes (`upsert`)	Trigger kind. Use `"Advanced"` for custom metrics.
`field`	yes (`upsert`)	Metric field to compare: `gauge`, `mean`, `p90`, `p95`, `counter`, or `count`.
`condition_value`	yes (`upsert`)	Threshold value (e.g. `500.0` for “response time > 500ms”).
`comparison_operator`	yes (`upsert`)	`<`, `>`, `<=`, `>=`, `==`, or `!=`.
`warmup_duration`	yes (`upsert`)	Minutes the condition must be met before an alert opens. Use `0` for immediate.
`cooldown_duration`	yes (`upsert`)	Minutes the condition must no longer be met before an alert closes.
`id`	yes (`archive`) / no (`upsert`)	Existing trigger ID. Required for `archive`. On `upsert`, providing it archives the old trigger and creates a new one.
`notifier_ids`	no	Notifier IDs to send alerts to.
`tags`	no	Tag filters to scope which metrics are included. Supports wildcards (`*`).
`name`	no	Display name. Defaults to the metric name if not provided.
`description`	no	Description of what this trigger monitors and what to do when it fires.
`dashboard_id`	no	Dashboard ID to link in notifications.
`no_match_is_zero`	no	If true, treat missing metric data as 0. Useful for counters that may not report when idle.
`format`	no	Data format of the metric (e.g. `duration`, `size`, `percent`).
`format_input`	no	Input size when `format` is `size` (for example `kilobyte` or `megabyte`).

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. Each line is headed by a 120-character preview of its message. When the message is longer than that, the response adds a separate Message row with the full text, capped at 2000 characters. Query syntax:

Pattern	Example
Exact match	`severity=error`
Contains	`message:timeout`
Does not contain	`message!:debug`
Not equal	`hostname!=web-1`
Numeric comparison	`duration>100`
Boolean logic	`severity=error AND (hostname=web-1 OR hostname=web-2)`
Quoted values	`group="background jobs"`
Nested attributes	`user.id=123`

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

Parameter	Required	Description
`app_name`	yes	Name of the AppSignal application.
`app_environment`	yes	Environment.
`query`	yes	Expression query. Use an empty string to retrieve all logs.
`source_ids`	no	IDs of log sources to query. Queries all sources if not specified. Use `get_app_resources(sections: ["log_sources"])` to find source IDs.
`start`	no	Start of time range in ISO 8601 format. Defaults to one query window ago.
`end`	no	End of time range in ISO 8601 format. Defaults to now.
`limit`	no	Number of log lines to return (1–100, default 50).
`order`	no	`desc` (newest first, default) or `asc` (oldest first).

`manage_log_line_action`

Create, update, reorder, or delete 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. New actions are appended at the end of the execution order.

This tool replaces the older reorder_log_line_actions and delete_log_line_action flows. Those names still work as backward-compatibility aliases, but manage_log_line_action is the primary tool.

Parameter	Required	Description
`app_name`	yes	Name of the AppSignal application.
`app_environment`	yes	Environment.
`action`	yes	`upsert` to create or update, `reorder` to change execution order, or `delete` to remove an action.
`name`	yes (create)	Name of the action (e.g. `"Drop health checks"`, `"Track error count"`).
`query`	yes (create)	Query expression to match against log lines.
`action_type`	yes (create)	`filter`, `trigger`, or `metrics`. Cannot be changed on update.
`id`	yes (`delete`)	Existing action ID. On `upsert`, providing it updates that action instead of creating a new one.
`source_ids`	no	Log source IDs this action applies to. Applies to all sources if not specified.
`log_line_metrics`	no	Metric definitions to extract. Required when creating a `metrics` action. Each metric requires `name` and `metric_type` (`counter`, `gauge`, or `distribution`). `gauge` and `distribution` also require a `field` to extract the value from. When updating, replaces all existing metric definitions.
`action_ids`	yes (`reorder`)	Ordered list of action IDs. Any action IDs not included are appended at the end in their current relative order.

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:<dashboard_id> reference to show metrics used in a specific dashboard.

Parameter	Required	Description
`app_name`	yes	Name of the AppSignal application.
`app_environment`	yes	Environment.
`metric_subject`	no	Metric category name (e.g. `performance_metrics`, `host_metrics`) or `dashboard:<dashboard_id>`.

`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.

Parameter	Required	Description
`app_name`	yes	Name of the AppSignal application.
`app_environment`	yes	Environment.

`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.

Parameter	Required	Description
`app_name`	yes	Name of the AppSignal application.
`app_environment`	yes	Environment.
`metric_name`	yes	Name of the metric. Use `get_metric_names` to find available metrics.

`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 *.

Parameter	Required	Description
`app_name`	yes	Name of the AppSignal application.
`app_environment`	yes	Environment.
`metric_name`	yes	Name of the metric.
`metric_type`	yes	`count`, `counter`, `gauge`, `mean`, `p90`, or `p95`. Use `get_metric_tags` to find the valid type.
`start`	yes	Start of time range in ISO 8601 format.
`end`	yes	End of time range in ISO 8601 format.
`tags`	no	Tag filters, e.g. `[{"key": "hostname", "value": "web"}]`. Supports `` wildcards.

`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.

Parameter	Required	Description
`app_name`	yes	Name of the AppSignal application.
`app_environment`	yes	Environment.
`metric_name`	yes	Name of the metric.
`metric_type`	yes	`count`, `counter`, `gauge`, `mean`, `p90`, or `p95`.
`start`	yes	Start of time range in ISO 8601 format.
`end`	yes	End of time range in ISO 8601 format.
`tags`	no	Tag filters, e.g. `[{"key": "hostname", "value": "frontend1"}]`.

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. MCP adds and updates, but does not remove. To delete a chart or a whole dashboard, open your app’s dashboards on AppSignal.

Parameter	Required	Description
`app_name`	yes	Name of the AppSignal application.
`app_environment`	yes	Environment.
`title`	yes	Dashboard title.
`description`	no	Description of the dashboard’s purpose and contents.
`id`	no	Dashboard ID for updating an existing dashboard. Omit to create a new one.

`create_dashboard_visual`

Add a new chart to an existing dashboard. Two visual types are available:

timeseries (default) — a line or area graph plotting one or more metrics over time.
number — a Big Number tile showing a single aggregated metric, useful for a total, the latest reading, or a mean at a glance.

Both render exactly as they would if you built them in the chart builder. For what each chart type is for, see dashboard chart types. Use discover_metrics or get_metrics_list to find available metrics first. These parameters apply to both visual types:

Parameter	Required	Description
`app_name`	yes	Name of the AppSignal application.
`app_environment`	yes	Environment.
`dashboard_id`	yes	ID of the dashboard to add the visual to.
`title`	yes	Chart title.
`type`	no	`timeseries` (default) or `number`.
`description`	no	Additional context about the visual.
`format`	no	Value format: `number`, `percent`, `duration`, `throughput`, or `size`.
`format_input`	no	Unit of the incoming value: `bit`, `byte`, `kilobit`, `kilobyte`, or `megabyte`. Only applies when `format` is `size`.

These parameters apply to timeseries visuals only:

Parameter	Required	Description
`metrics`	yes	Array of metrics to plot. Each takes `name`, `fields` (an array of objects such as `[{"field": "mean"}]`, where the field is `mean`, `p90`, `p95`, `count`, `gauge`, or `counter`), and optional `tags`.
`display`	no	`line` (default), `area`, or `area_relative`.
`line_label`	no	Custom label for chart lines. Supports `%name%`, `%field%`, and `%tag%` replacements.
`draw_null_as_zero`	no	Whether to draw missing data points as zero. Default: `false`.
`min_y_axis`	no	Minimum Y-axis value.
`tags`	no	Global tags applied to every metric in this visual.

These parameters apply to number visuals only:

Parameter	Required	Description
`metric`	yes	The single metric to display. Takes `name`, `field` (`mean`, `p90`, `p95`, `count`, `gauge`, or `counter`), `aggregate` (`max`, `min`, `avg`, `sum`, `first`, or `last`), and optional `tags`.

A Big Number tile takes one metric and one aggregation across the dashboard’s selected time range. Ask for it in plain language:

Text

Add a Big Number chart to the "API Health" dashboard showing the mean
of request_latency_ms over the selected time range, formatted as a duration.

The agent translates that into a create_dashboard_visual call:

{
  "app_name": "MyApp",
  "app_environment": "production",
  "dashboard_id": "<DASHBOARD_ID>",
  "title": "Mean request latency",
  "type": "number",
  "format": "duration",
  "metric": {
    "name": "request_latency_ms",
    "field": "mean",
    "aggregate": "avg"
  }
}

MCP authors the visual; it does not ingest metrics. The metric you point a chart at has to be flowing into AppSignal already. See custom metrics for how to send them from your application.

`update_dashboard_visual`

Update an existing chart on a dashboard. This works for both timeseries and Big Number visuals — the type is read from the existing visual, so you don’t pass type. All fields are optional except the identifiers, and unspecified fields keep their current values. Passing metrics or metric replaces the whole metric definition on that visual rather than merging into it.

Parameter	Required	Description
`app_name`	yes	Name of the AppSignal application.
`app_environment`	yes	Environment.
`visual_id`	yes	ID of the visual to update.
`title`	no	New title.
`description`	no	New description. Set to an empty string to remove it.
`format`	no	Value format: `number`, `percent`, `duration`, `throughput`, or `size`.
`format_input`	no	Unit of the incoming value: `bit`, `byte`, `kilobit`, `kilobyte`, or `megabyte`. Only applies when `format` is `size`.
`metrics`	no	Timeseries visuals only. Replaces the entire metrics array.
`display`	no	Timeseries visuals only. `line`, `area`, or `area_relative`.
`line_label`	no	Timeseries visuals only. Supports `%name%`, `%field%`, and `%tag%` replacements.
`draw_null_as_zero`	no	Timeseries visuals only. Whether to draw missing data points as zero.
`min_y_axis`	no	Timeseries visuals only. Minimum Y-axis value.
`tags`	no	Timeseries visuals only. Global tags. Replaces existing global tags if provided.
`metric`	no	Big Number visuals only. Replaces the entire metric definition. Same shape as in `create_dashboard_visual`.

Read and write tools

Every tool either only reads your data or can change it, and its name tells you which: get_ and discover_ tools only read, while create_, update_, and manage_ tools write. Deleting sits inside the manage_ tools rather than in tools of its own, manage_log_line_action removes an action, manage_check_in_trigger removes a monitor, and manage_trigger archives one. This split is what MCP clients group by, so you can configure in your agent which tools to allow, which to approve case by case, and which to block.

Token permissions

Each MCP token is scoped to specific applications and to the tools you expose on that token. If you want a narrower setup for an agent, this is where you limit it. For example, you might expose only get_applications, get_app_resources, and get_exception_incidents for an incident-triage agent, or get_log_lines and manage_log_line_action for log-ingestion work. You can also set a token to automatically expose new tools as they are added later. For the steps to create one, see Authentication.

Missing a tool?

Alongside the product areas above, AppSignal MCP exposes get_more_tools, a discovery and feedback tool. It does two jobs:

Log a request for a capability you could not find
File feedback about how a task or tool call went

It does not unlock hidden tools today. Its value is that the request or feedback is logged against your account so the AppSignal team can see where agents hit a wall. get_more_tools takes these parameters:

Parameter	Required	Description
`context`	yes	Why the agent is calling the tool. Bookkeeping only — it does not change the response.
`description`	no	The capability you’re looking for, in plain language. Logged as a tool request when provided.
`notes`	no	What happened, in enough detail for a human to act on. Required when filing feedback.
`outcome`	no	Optional result for feedback: `success`, `partial`, or `failed`.

Most agents will not reach for it on their own, so ask explicitly: “Use the AppSignal get_more_tools tool to request a way to bulk-export incidents to CSV.” Or, when a task partially worked: “Use the AppSignal get_more_tools tool to file feedback that get_log_lines found the right logs, but I still needed a second step to summarize them.”

Hit a wall with the current toolset? Ask your agent to call get_more_tools, then post the same request in the Discord community so the AppSignal team can weigh it.

​Tool reference

​App discovery

​get_applications

​get_app_resources

​Check-ins

​get_check_in_triggers

​manage_check_in_trigger

​Error incidents

​get_exception_incidents

​get_incident

​update_incidents

​manage_incident_note

​Performance

​get_performance

​get_traces

​Anomaly detection

​get_anomaly_incidents

​get_triggers

​manage_trigger

​Logging

​get_log_lines

​manage_log_line_action

​Metrics

​discover_metrics

​get_metric_names

​get_metric_tags

​get_metrics_timeseries

​get_metrics_list

​Dashboards

​manage_dashboard

​create_dashboard_visual

​update_dashboard_visual

​Read and write tools

​Token permissions

​Missing a tool?

Tool reference

App discovery

`get_applications`

`get_app_resources`

Check-ins

`get_check_in_triggers`

`manage_check_in_trigger`

Error incidents

`get_exception_incidents`

`get_incident`

`update_incidents`

`manage_incident_note`

Performance

`get_performance`

`get_traces`

Anomaly detection

`get_anomaly_incidents`

`get_triggers`

`manage_trigger`

Logging

`get_log_lines`

`manage_log_line_action`

Metrics

`discover_metrics`

`get_metric_names`

`get_metric_tags`

`get_metrics_timeseries`

`get_metrics_list`

Dashboards

`manage_dashboard`

`create_dashboard_visual`

`update_dashboard_visual`

Read and write tools

Token permissions

Missing a tool?