MCP-Tool-Referenz - AppSignal Documentation

AppSignal MCP stellt 24 Tools in sieben Bereichen bereit: Fehlervorfälle, Performance, Anomalieerkennung, Logging, Metriken, Dashboards und App-Discovery. Die Tools umfassen sowohl Lese- als auch Schreibvorgänge.

Workflows

Diese Beispiele zeigen, wie Tools für gängige Aufgaben zusammengesetzt werden.

Untersuchen eines Produktionsfehlers

Aktuelle offene Ausnahmen auflisten: „Show me all open incidents in production from the last 24 hours”
Vollständige Details zu einem bestimmten Vorfall abrufen: „Get the details for incident #847 including the stack trace”
Traces abrufen, um zu sehen, was auf Codeebene passiert ist: „Get the error traces for incident #847”
Ihre Erkenntnisse dokumentieren: „Add a note to incident #847: investigated the database timeout — connection pool was exhausted during peak traffic”
Lösen Sie ihn: „Close incident #847”

Profilieren einer langsamen Aktion

Performance-Überblick abrufen: „Which actions are slowest in the web namespace right now?”
Traces für den schlimmsten Übeltäter abrufen: „Get traces for BlogPostsController#index from the last hour”
Span-Baum untersuchen, um den Engpass zu finden: „Show me the full span tree for trace abc123”
In einen bestimmten Span eintauchen: „Get the details for span def456 in trace abc123”

Triage eines Batches von Vorfällen

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

Durchsuchen von Protokollen während eines Vorfalls

„Find all error logs from the last hour”
„Show me logs where message contains ‘timeout’ on web-1 between 14:00 and 15:00”
„Get fatal logs from the payments source over the last 30 minutes”

Rekonstruieren einer Kunden-Journey

Wenn ein Benutzer meldet, dass etwas schief gelaufen ist, ist die Antwort normalerweise über Protokolle aus mehreren Quellen, Fehler und Traces verstreut. Diese Zeitleiste manuell zusammenzufügen ist die Art von Arbeit, die die Logging-Benutzeroberfläche nicht für Sie erledigen kann, aber ein Agent kann es.

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

Dies greift in einer einzigen Konversation auf get_log_lines, get_exception_incidents und get_traces zu. Der abschließende Zusammenfassungs-Schritt ist, wo MCP seinen Wert beweist — der Agent verfasst die Erzählung, nicht Sie.

Einrichten der Protokollverarbeitung

AppSignal führt Protokollzeilen-Aktionen während der Erfassung in der von Ihnen definierten Reihenfolge aus. Ein gängiges Muster besteht darin, eine Metrik auszugeben, einen Trigger zu erstellen und dann zu filtern — dies stellt sicher, dass AppSignal das Signal erfasst, bevor die Protokollzeile verworfen wird.

Die vorhandenen Protokollzeilen-Aktionen und ihre Reihenfolge überprüfen: Verwenden Sie get_app_resources mit sections: ["log_line_actions"]
„Create a metrics action that counts log lines where severity is error as log.error_count”
„Add a trigger action that fires an alert when severity is fatal”
„Add a filter to drop all health check log lines”
„Reorder those actions so the metrics action runs first, then the trigger, then the filter”

Erstellen eines Anomalieerkennungs-Triggers

Verfügbare Metriken entdecken: „What metrics are available for my production app?”
Verfügbare Tags prüfen: „What tags are available for response_time?”
Den Trigger erstellen: „Create a trigger that fires when mean response time exceeds 500ms for more than 5 minutes, and notify the Slack #alerts channel”
Einen alten Trigger archivieren, sobald er ersetzt wird: Verwenden Sie get_triggers, um zuerst die ID zu finden, dann „Archive the old response_time trigger”

Erstellen eines Monitoring-Dashboards

„What metrics are available for my production app?”
„Create a dashboard called ‘API Health’ in production”
„Add a line chart of p95 response time by action to the API Health dashboard”
„Add an area chart of error rate broken down by namespace”

Tool-Referenz

Jedes Tool benötigt app_name und app_environment, um die anzusprechende Anwendung zu identifizieren. Beide werden ohne Berücksichtigung der Groß-/Kleinschreibung abgeglichen, sodass MyApp/Production und myapp/production zur selben Anwendung aufgelöst werden.

App-Discovery

`get_applications`

Ruft alle AppSignal-Anwendungen ab, auf die der Benutzer Zugriff hat. Gibt Anwendungen im Format app_name/app_environment zurück. Verwenden Sie dies zuerst, um verfügbare Anwendungen zu entdecken, bevor Sie andere Tools aufrufen. Keine Parameter erforderlich.

`get_app_resources`

Entdeckt verfügbare Ressourcen in einer AppSignal-Anwendung — Namespaces, Dashboards, Benutzer, Notifier, Protokollquellen, Protokollzeilen-Aktionen, Deploy Markers und Uptime-Monitore. Besonders nützlich beim Einrichten von Triggern, Zuweisen von Vorfällen oder beim Verständnis der Struktur einer Anwendung.

Parameter	Erforderlich	Beschreibung
`app_name`	ja	Name der AppSignal-Anwendung.
`app_environment`	ja	Umgebung (z. B. `production`, `staging`).
`sections`	nein	Abzurufende Sektionen: `users`, `notifiers`, `namespaces`, `dashboards`, `log_sources`, `log_line_actions`, `log_views`, `deploy_markers`, `uptime_monitors`. Gibt alle zurück, falls nicht angegeben.
`deploy_marker_namespace`	nein	Nur die Deploys in diesem Namespace anzeigen (z. B. `web`).
`deploy_marker_revision`	nein	Nur die Deploys mit dieser Revision anzeigen. Ein kurzer Präfix funktioniert (z. B. `a1b2c3d`).

Die Sektion deploy_markers gibt bis zu 100 aktuelle Deploys zurück, jeweils mit ihrer vollständigen Revision und dem Zeitraum, in dem sie aktiv waren. Grenzen Sie sie mit deploy_marker_namespace oder deploy_marker_revision ein. Um die Fehler zu finden, die ein Deploy verursacht hat, übergeben Sie dessen Revision an get_exception_incidents (oder verwenden Sie revision: "last" für den letzten Deploy). Die Sektion uptime_monitors listet jede überwachte URL und ihre Einstellungen auf. Die Uptime selbst wird nicht gespeichert — sie wird aus Metriken berechnet. Fragen Sie also den Counter uptime_monitor_error_count mit get_metrics_timeseries ab, um sie zu berechnen.

Fehlervorfälle

`get_exception_incidents`

Listet AppSignal-Ausnahmen und -Fehler auf und durchsucht sie. Verwenden Sie dies, um einen Überblick über aktuelle Ausnahmen zu erhalten, innerhalb eines Zeitraums zu suchen, Vorfälle nach Zustand zu finden oder zu prüfen, welche Vorfälle Aufmerksamkeit benötigen. Gibt 50 Vorfälle pro Seite zurück.

Parameter	Erforderlich	Beschreibung
`app_name`	ja	Name der AppSignal-Anwendung.
`app_environment`	ja	Umgebung.
`namespaces`	nein	Komma-separierte Liste der zu filternden Namespaces (z. B. `web,background`).
`start`	nein	Beginn des Zeitbereichs im ISO-8601-Format. Standardmäßig der letzte Deploy, wenn ausgelassen.
`end`	nein	Ende des Zeitbereichs im ISO-8601-Format. Erforderlich, wenn `start` angegeben wird.
`states`	nein	Komma-separierte Zustände: `open`, `closed`, `wip`. Gibt alle Zustände zurück, falls nicht angegeben.
`page`	nein	Seitennummer (1-basiert, Standard 1).

`get_incident`

Ruft detaillierte Informationen über einen AppSignal-Vorfall ab. Gibt den aktuellen Zustand, die Zuweisung, das erste und letzte Auftreten, Fehlermeldungen, Stack-Traces oder Details zur Anomaliebenachrichtigung zurück. Unterstützt Ausnahme- und Anomalievorfälle.

Parameter	Erforderlich	Beschreibung
`app_name`	ja	Name der AppSignal-Anwendung.
`app_environment`	ja	Umgebung.
`number`	ja	Die numerische Vorfall-ID, die in AppSignal-URLs und Vorfalllisten angezeigt wird.

`update_incidents`

Aktualisiert Vorfälle für eine AppSignal-Anwendung in einem Batch. Verwenden Sie dies, um den Vorfallzustand zu ändern, die Schweregradstufe zu aktualisieren oder Teammitglieder bei mehreren Vorfällen gleichzeitig zuzuweisen oder zu entfernen. Verwenden Sie get_app_resources mit sections: ["users"], um Benutzer-IDs für die Zuweisung zu finden.

Parameter	Erforderlich	Beschreibung
`app_name`	ja	Name der AppSignal-Anwendung.
`app_environment`	ja	Umgebung.
`incidents`	nein	Liste der zu aktualisierenden Vorfallnummern (z. B. `[123, 456, 789]`).
`state`	nein	`open`, `closed` oder `wip` (work in progress).
`severity`	nein	`critical`, `high`, `low`, `none`, `informational` oder `untriaged`.
`assign_users`	nein	Liste der Benutzer-IDs, die als Bearbeiter zugewiesen werden sollen.
`unassign_users`	nein	Liste der Benutzer-IDs, die vom Vorfall entfernt werden sollen.

`manage_incident_note`

Erstellt oder aktualisiert eine Notiz zu einem AppSignal-Vorfall. Markdown wird unterstützt. Verwenden Sie dies, um Kommentare, Statusaktualisierungen, Untersuchungsergebnisse oder Lösungsschritte hinzuzufügen. Fügen Sie eine vollständige GitHub-Issue-URL in die Notiz ein, um dieses Issue mit dem Vorfall zu verknüpfen, sofern die App mit GitHub konfiguriert ist.

Dieses Tool hieß zuvor create_incident_note. Der alte Name funktioniert weiterhin als Alias, sodass bestehende Prompts und Konfigurationen weiter funktionieren.

Parameter	Erforderlich	Beschreibung
`app_name`	ja	Name der AppSignal-Anwendung.
`app_environment`	ja	Umgebung.
`number`	ja	Die numerische Vorfall-ID.
`content`	ja	Notizinhalt. Markdown-Formatierung wird unterstützt.
`id`	nein	ID einer vorhandenen Notiz zum Aktualisieren. Weglassen, um eine neue Notiz zu erstellen. Sie können nur Notizen bearbeiten, die Sie selbst verfasst haben.

Performance

`get_performance`

Performance-Überblick: Sample-basierte Performance-Vorfälle und langsame Aktionen aus Traces. Für Standard-Ruby- und Elixir-Apps gibt sample-basierte Performance-Vorfälle zurück. Für Apps, die auch OpenTelemetry-Traces senden, gibt zusätzlich eine sortierte Liste von Aktionen mit mittlerer Dauer, Durchsatz und Fehlerquote zurück. Apps, die zu OpenTelemetry migriert werden, können beides zurückgeben. Folge-Tools: Verwenden Sie get_incident, um einen bestimmten Performance-Vorfall zu untersuchen, get_traces, um Sample-Traces für eine langsame Aktion abzurufen, und update_incidents, um Zustand, Schweregradstufe oder Zuständige zu ändern.

Parameter	Erforderlich	Beschreibung
`app_name`	ja	Name der AppSignal-Anwendung.
`app_environment`	ja	Umgebung.
`namespaces`	nein	Komma-separierte Namespaces. Gilt sowohl für Performance-Vorfälle als auch für OpenTelemetry-Aktionen.
`start`	nein	Beginn des Zeitbereichs im ISO-8601-Format. Standardmäßig der letzte Deploy für sample-basierte Vorfälle oder vor 24 Stunden für OpenTelemetry-Aktionen.
`end`	nein	Ende des Zeitbereichs im ISO-8601-Format. Erforderlich, wenn `start` angegeben wird.
`states`	nein	Komma-separierte Zustände: `open`, `closed`, `wip`. Gilt nur für sample-basierte Vorfälle.
`revision`	nein	Auf einen bestimmten Deploy beschränken. Verwenden Sie `"last"` für den letzten Deploy oder übergeben Sie einen Revisions-Hash. Ignoriert, wenn `start`/`end` angegeben wird. Verwenden Sie `get_app_resources(sections: ["deploy_markers"])`, um verfügbare Revisionen aufzulisten.
`page`	nein	Seitennummer für sample-basierte Vorfälle (1-basiert, Standard 1). OpenTelemetry-Aktionen werden als vollständige sortierte Liste zurückgegeben.

`get_traces`

Performance- und Fehler-Traces abfragen, Span-Bäume untersuchen und Span-Details anzeigen. Unterstützt zwei Trace-Typen:

Performance traces — identifiziert durch Namespace und action_name. Verwenden Sie diese, um langsame Anfragen zu untersuchen.
Error traces — identifiziert durch Digest. Holen Sie sich den Digest aus get_incident oder get_exception_incidents, und verwenden Sie ihn dann hier, um die tatsächlichen Fehler-Traces zu sehen.

Jeder Trace-Typ unterstützt drei Modi:

Listenmodus — Traces finden und Trace-IDs abrufen. Geben Sie Namespace + action_name oder digest an.
Baummodus — Übergeben Sie eine trace_id, um alle Spans als kompakten Baum anzuzeigen.
Span-Detailmodus — Übergeben Sie trace_id und span_id für vollständige Span-Attribute, -Ereignisse und -Ressourceninformationen.

Der typische Workflow ist: Traces auflisten → einen Trace-Baum untersuchen → in einen Span eintauchen.

Parameter	Erforderlich	Beschreibung
`app_name`	ja	Name der AppSignal-Anwendung.
`app_environment`	ja	Umgebung.
`namespace`	ja (performance)	Der Namespace, in dem gesucht werden soll (z. B. `web`, `background`). Bei Fehler-Traces nicht erforderlich.
`action_name`	ja (performance)	Der Aktionsname (z. B. `BlogPostsController#index`). Bei Fehler-Traces nicht erforderlich.
`digest`	ja (error)	Der Ausnahme-Vorfall-Digest. Wechselt in den Fehler-Trace-Modus. Kann nicht mit `namespace` oder `action_name` kombiniert werden.
`trace_id`	nein	Wechselt in den Baummodus. Gibt alle Spans für diesen Trace zurück.
`span_id`	nein	Wechselt in den Span-Detailmodus. Erfordert `trace_id`.
`start`	nein	Beginn des Zeitbereichs im ISO-8601-Format. Standardmäßig vor 24 Stunden. Nur Performance-Traces.
`end`	nein	Ende des Zeitbereichs im ISO-8601-Format. Standardmäßig jetzt. Nur Performance-Traces.
`min_duration_ms`	nein	Filtert auf Traces, die langsamer sind als dieser Schwellenwert in Millisekunden. Nur Listenmodus.
`limit`	nein	Maximale Anzahl der zurückzugebenden Traces (1–100, Standard 25). Nur Listenmodus.

Anomalieerkennung

`get_anomaly_incidents`

Listet AppSignal-Anomalieerkennungs-Alerts auf und durchsucht sie. Gibt 50 Alerts pro Seite zurück, einschließlich Zeitstempel und Werten für jeden Alert.

Parameter	Erforderlich	Beschreibung
`app_name`	ja	Name der AppSignal-Anwendung.
`app_environment`	ja	Umgebung.
`state`	nein	`open`, `closed`, `warmup`, `cooldown` oder `archived`. Gibt alle Zustände zurück, falls nicht angegeben.
`trigger_id`	nein	Auf Vorfälle eines bestimmten Triggers filtern. Verwenden Sie `get_triggers`, um Trigger-IDs zu finden.
`page`	nein	Seitennummer (1-basiert, Standard 1).

`get_triggers`

Listet die Anomalieerkennungs-Trigger für eine AppSignal-Anwendung auf. Gibt aktive (nicht archivierte) Trigger mit ihrer vollständigen Konfiguration zurück — Bedingungen, Notifier und Dashboard-Links. Verwenden Sie dies, um Trigger-IDs zu finden, bevor Sie manage_trigger oder archive_trigger aufrufen.

Parameter	Erforderlich	Beschreibung
`app_name`	ja	Name der AppSignal-Anwendung.
`app_environment`	ja	Umgebung.
`metric_name`	nein	Nach Metriknamen filtern (z. B. `response_time`, `error_rate`).
`kind`	nein	Nach Trigger-Art filtern.
`tags`	nein	Nach Tags filtern, z. B. `[{"key": "hostname", "value": "web-1"}]`.
`page`	nein	Seitennummer (1-basiert, Standard 1).

`manage_trigger`

Erstellt oder aktualisiert einen Anomalieerkennungs-Trigger. Trigger sind unveränderlich. Wenn Sie einen Trigger aktualisieren, archiviert AppSignal den vorhandenen (schließt alle zugehörigen Alerts und Vorfälle) und erstellt einen neuen mit einer Versionsketten-Referenz. Geben Sie alle Felder sowohl für Erstellungs- als auch für Aktualisierungsvorgänge an. Verwenden Sie get_metric_names und get_metric_tags, um verfügbare Metriken und Felder zu entdecken. Verwenden Sie get_app_resources(sections: ["notifiers"]), um Notifier-IDs zu finden.

Parameter	Erforderlich	Beschreibung
`app_name`	ja	Name der AppSignal-Anwendung.
`app_environment`	ja	Umgebung.
`metric_name`	ja	Die Metrik, die dieser Trigger überwacht.
`kind`	ja	Trigger-Art. Verwenden Sie `"Advanced"` für benutzerdefinierte Metriken.
`field`	ja	Zu vergleichendes Metrikfeld: `gauge`, `mean`, `p90`, `p95`, `counter` oder `count`.
`condition_value`	ja	Schwellenwert (z. B. `500.0` für „response time > 500ms”).
`comparison_operator`	ja	`<`, `>`, `<=`, `>=`, `==` oder `!=`.
`warmup_duration`	ja	Minuten, in denen die Bedingung erfüllt sein muss, bevor ein Alert geöffnet wird. `0` für sofort.
`cooldown_duration`	ja	Minuten, in denen die Bedingung nicht mehr erfüllt sein darf, bevor ein Alert geschlossen wird.
`id`	nein	ID eines vorhandenen Triggers zum Aktualisieren. Falls angegeben, wird der alte Trigger archiviert und ein neuer erstellt.
`notifier_ids`	nein	Notifier-IDs, an die Alerts gesendet werden.
`tags`	nein	Tag-Filter, um festzulegen, welche Metriken einbezogen werden. Unterstützt Platzhalter (`*`).
`name`	nein	Anzeigename. Standardmäßig der Metrikname, falls nicht angegeben.
`description`	nein	Beschreibung dessen, was dieser Trigger überwacht und was zu tun ist, wenn er ausgelöst wird.
`dashboard_id`	nein	Dashboard-ID, die in Benachrichtigungen verlinkt werden soll.
`no_match_is_zero`	nein	Wenn true, fehlende Metrikdaten als 0 behandeln. Nützlich für Counter, die im Leerlauf möglicherweise nicht melden.
`format`	nein	Datenformat der Metrik (z. B. `duration`, `size`, `percent`).

`archive_trigger`

Archiviert einen Anomalieerkennungs-Trigger und schließt alle zugehörigen Alerts und Vorfälle. Idempotent — keine Wirkung, wenn der Trigger bereits archiviert ist. Verwenden Sie get_triggers, um die Trigger-ID zu finden.

Parameter	Erforderlich	Beschreibung
`app_name`	ja	Name der AppSignal-Anwendung.
`app_environment`	ja	Umgebung.
`id`	ja	ID des zu archivierenden Triggers.

Logging

`get_log_lines`

Fragt Protokollzeilen mit der Ausdruckssyntax von AppSignal ab. Unterstützt exakte Übereinstimmung, enthält, Negation, numerische Vergleiche, Boolean-Logik und verschachtelte Attribute. Gibt bis zu 100 Zeilen pro Aufruf zurück, standardmäßig neueste zuerst. Bei großen Zeitbereichen in mehrere Aufrufe aufteilen und vorwärts iterieren. Abfragesyntax:

Muster	Beispiel
Exakte Übereinstimmung	`severity=error`
Enthält	`message:timeout`
Enthält nicht	`message!:debug`
Nicht gleich	`hostname!=web-1`
Numerischer Vergleich	`duration>100`
Boolean-Logik	`severity=error AND (hostname=web-1 OR hostname=web-2)`
Quotierte Werte	`group="background jobs"`
Verschachtelte Attribute	`user.id=123`

Verfügbare Felder: severity, hostname, group, message und beliebige benutzerdefinierte Attribute.

Parameter	Erforderlich	Beschreibung
`app_name`	ja	Name der AppSignal-Anwendung.
`app_environment`	ja	Umgebung.
`query`	ja	Ausdrucks-Abfrage. Verwenden Sie eine leere Zeichenkette, um alle Protokolle abzurufen.
`source_ids`	nein	IDs der Protokollquellen, die abgefragt werden sollen. Fragt alle Quellen ab, falls nicht angegeben. Verwenden Sie `get_app_resources(sections: ["log_sources"])`, um Quell-IDs zu finden.
`start`	nein	Beginn des Zeitbereichs im ISO-8601-Format. Standardmäßig ein Abfragefenster zurück.
`end`	nein	Ende des Zeitbereichs im ISO-8601-Format. Standardmäßig jetzt.
`limit`	nein	Anzahl der zurückzugebenden Protokollzeilen (1–100, Standard 50).
`order`	nein	`desc` (neueste zuerst, Standard) oder `asc` (älteste zuerst).

`manage_log_line_action`

Erstellt oder aktualisiert eine Protokollzeilen-Aktion. Protokollzeilen-Aktionen werden während der Protokollerfassung in der von Ihnen definierten Reihenfolge ausgeführt. Es gibt drei Typen:

filter — verwirft übereinstimmende Protokollzeilen, sodass sie nie gespeichert oder weiterverarbeitet werden
trigger — löst Alerts und Vorfälle aus, wenn die Abfrage übereinstimmt
metrics — extrahiert Counter-, Gauge- oder Distribution-Metriken aus übereinstimmenden Protokollzeilen

Die Ausführungsreihenfolge ist wichtig: Wenn ein Filter eine Protokollzeile verwirft, sehen nachfolgende Aktionen sie nie. Ein gängiges Muster besteht darin, Metrik- und Trigger-Aktionen vor Filter-Aktionen zu platzieren. Verwenden Sie reorder_log_line_actions, um die Reihenfolge nach der Erstellung zu ändern. Neue Aktionen werden am Ende der Ausführungsreihenfolge angehängt.

Parameter	Erforderlich	Beschreibung
`app_name`	ja	Name der AppSignal-Anwendung.
`app_environment`	ja	Umgebung.
`name`	ja (Erstellung)	Name der Aktion (z. B. `"Drop health checks"`, `"Track error count"`).
`query`	ja (Erstellung)	Abfrageausdruck, der mit den Protokollzeilen abgeglichen werden soll.
`action_type`	ja (Erstellung)	`filter`, `trigger` oder `metrics`. Kann bei Aktualisierung nicht geändert werden.
`id`	nein	ID einer vorhandenen Aktion zum Aktualisieren. Falls weggelassen, wird eine neue Aktion erstellt.
`source_ids`	nein	Protokollquellen-IDs, auf die diese Aktion angewendet wird. Gilt für alle Quellen, falls nicht angegeben.
`log_line_metrics`	nein	Zu extrahierende Metrikdefinitionen. Erforderlich beim Erstellen einer `metrics`-Aktion. Jede Metrik benötigt `name` und `metric_type` (`counter`, `gauge` oder `distribution`). `gauge` und `distribution` benötigen auch ein `field`, aus dem der Wert extrahiert wird. Beim Aktualisieren werden alle vorhandenen Metrikdefinitionen ersetzt.

`reorder_log_line_actions`

Ändert die Ausführungsreihenfolge der Protokollzeilen-Aktionen. Geben Sie die Aktion-IDs in der gewünschten Reihenfolge an. Alle Aktion-IDs, die nicht enthalten sind, werden in ihrer aktuellen relativen Reihenfolge am Ende angehängt. Verwenden Sie get_app_resources(sections: ["log_line_actions"]), um IDs zu finden und die aktuelle Reihenfolge anzuzeigen.

Parameter	Erforderlich	Beschreibung
`app_name`	ja	Name der AppSignal-Anwendung.
`app_environment`	ja	Umgebung.
`action_ids`	ja	Geordnete Liste der Protokollzeilen-Aktion-IDs. Die erste ID in der Liste wird während der Erfassung zuerst ausgeführt.

`delete_log_line_action`

Löscht eine Protokollzeilen-Aktion dauerhaft. Verwenden Sie get_app_resources(sections: ["log_line_actions"]), um zuerst die Aktion-ID zu finden.

Parameter	Erforderlich	Beschreibung
`app_name`	ja	Name der AppSignal-Anwendung.
`app_environment`	ja	Umgebung.
`id`	ja	ID der zu löschenden Protokollzeilen-Aktion.

Metriken

`discover_metrics`

Entdeckt verfügbare Metrikkategorien und ihre Metriken für die Überwachung. Verwenden Sie dies, um einen Überblick darüber zu erhalten, was Sie überwachen können, oder um in eine bestimmte Kategorie einzutauchen. Akzeptiert auch eine dashboard:id-Referenz, um Metriken anzuzeigen, die in einem bestimmten Dashboard verwendet werden.

Parameter	Erforderlich	Beschreibung
`app_name`	ja	Name der AppSignal-Anwendung.
`app_environment`	ja	Umgebung.
`metric_subject`	nein	Metrikkategoriename (z. B. `performance_metrics`, `host_metrics`) oder eine `dashboard:id`-Referenz.

`get_metric_names`

Ruft die Namen aller Metriken für die angegebene Anwendung ab. Gibt Metriknamen als komma-separierte Zeichenkette zurück. Verwenden Sie diese als Eingabe für get_metric_tags, get_metrics_timeseries und get_metrics_list.

Parameter	Erforderlich	Beschreibung
`app_name`	ja	Name der AppSignal-Anwendung.
`app_environment`	ja	Umgebung.

`get_metric_tags`

Ruft die Tags und den Metriktyp (Gauge, Counter usw.) für eine bestimmte Metrik ab. Verwenden Sie die Ergebnisse, um gültige Abfragen mit get_metrics_timeseries und get_metrics_list zu erstellen.

Parameter	Erforderlich	Beschreibung
`app_name`	ja	Name der AppSignal-Anwendung.
`app_environment`	ja	Umgebung.
`metric_name`	ja	Name der Metrik. Verwenden Sie `get_metric_names`, um verfügbare Metriken zu finden.

`get_metrics_timeseries`

Ruft eine Zeitreihe für eine Metrik in der angegebenen Anwendung ab. Gibt Punkt-für-Punkt-Daten für einen bestimmten Zeitbereich, Metriktyp und eine Tag-Kombination zurück. Tag-Werte unterstützen Platzhalterabgleich mit *.

Parameter	Erforderlich	Beschreibung
`app_name`	ja	Name der AppSignal-Anwendung.
`app_environment`	ja	Umgebung.
`metric_name`	ja	Name der Metrik.
`metric_type`	ja	`COUNT`, `COUNTER`, `GAUGE`, `MEAN`, `P90` oder `P95`. Verwenden Sie `get_metric_tags`, um den gültigen Typ zu finden.
`start`	ja	Beginn des Zeitbereichs im ISO-8601-Format.
`end`	ja	Ende des Zeitbereichs im ISO-8601-Format.
`tags`	nein	Tag-Filter, z. B. `[{"key": "hostname", "value": "web"}]`. Unterstützt ``-Platzhalter.

`get_metrics_list`

Ruft einen aggregierten Wert für eine Metrik über einen Zeitbereich ab. Gibt einen einzelnen aggregierten Wert anstelle einer Punkt-für-Punkt-Zeitreihe zurück. Nützlich für Übersichtsansichten.

Parameter	Erforderlich	Beschreibung
`app_name`	ja	Name der AppSignal-Anwendung.
`app_environment`	ja	Umgebung.
`metric_name`	ja	Name der Metrik.
`metric_type`	ja	`COUNT`, `COUNTER`, `GAUGE`, `MEAN`, `P90` oder `P95`.
`start`	ja	Beginn des Zeitbereichs im ISO-8601-Format.
`end`	ja	Ende des Zeitbereichs im ISO-8601-Format.
`tags`	nein	Tag-Filter, z. B. `[{"key": "hostname", "value": "frontend1"}]`.

Dashboards

`manage_dashboard`

Erstellt oder aktualisiert ein AppSignal-Dashboard. Dieses Tool verwaltet nur Dashboard-Metadaten (Titel und Beschreibung). Verwenden Sie create_dashboard_visual und update_dashboard_visual, um Diagramme hinzuzufügen.

Parameter	Erforderlich	Beschreibung
`app_name`	ja	Name der AppSignal-Anwendung.
`app_environment`	ja	Umgebung.
`title`	ja	Dashboard-Titel.
`description`	nein	Beschreibung von Zweck und Inhalt des Dashboards.
`id`	nein	Dashboard-ID zum Aktualisieren eines vorhandenen Dashboards. Weglassen, um ein neues zu erstellen.

`create_dashboard_visual`

Fügt einem vorhandenen Dashboard ein neues Diagramm oder einen Graphen hinzu. Verwenden Sie zuerst discover_metrics oder get_metrics_list, um verfügbare Metriken zu finden.

Parameter	Erforderlich	Beschreibung
`app_name`	ja	Name der AppSignal-Anwendung.
`app_environment`	ja	Umgebung.
`dashboard_id`	ja	ID des Dashboards, dem das Visual hinzugefügt werden soll.
`title`	ja	Diagrammtitel.
`metrics`	ja	Array von anzuzeigenden Metriken. Jede benötigt `name`, `fields` (z. B. `mean`, `p90`, `p95`, `count`) und optional `tags`.
`description`	nein	Zusätzlicher Kontext über das Visual.
`display`	nein	`line` (Standard), `area` oder `area_relative`.
`line_label`	nein	Benutzerdefiniertes Label für Diagrammlinien. Unterstützt `%name%`, `%field%` und `%tag%`-Ersetzungen.
`format`	nein	Wertformat, z. B. `duration`, `size`, `percentage`.
`draw_null_as_zero`	nein	Ob fehlende Datenpunkte als Null gezeichnet werden sollen. Standard: `false`.
`min_y_axis`	nein	Minimaler Y-Achsen-Wert.
`tags`	nein	Globale Tags, die auf alle Metriken in diesem Visual angewendet werden.

`update_dashboard_visual`

Aktualisiert ein vorhandenes Diagramm oder einen Graphen in einem Dashboard. Alle Felder sind optional außer den Identifikatoren. Nicht angegebene Felder behalten ihre aktuellen Werte. Wenn metrics angegeben ist, ersetzt es alle vorhandenen Metriken in diesem Visual.

Parameter	Erforderlich	Beschreibung
`app_name`	ja	Name der AppSignal-Anwendung.
`app_environment`	ja	Umgebung.
`visual_id`	ja	ID der zu aktualisierenden Visual-Komponente.
`title`	nein	Neuer Titel. Aktueller Titel wird beibehalten, falls nicht angegeben.
`description`	nein	Neue Beschreibung. Auf leere Zeichenkette setzen, um sie zu entfernen.
`metrics`	nein	Aktualisiertes Metriken-Array. Ersetzt alle vorhandenen Metriken, falls angegeben.
`display`	nein	`line`, `area` oder `area_relative`.
`line_label`	nein	Benutzerdefiniertes Label für Diagrammlinien. Unterstützt `%name%`, `%field%` und `%tag%`-Ersetzungen.
`format`	nein	Wertformat, z. B. `duration`, `size`, `percentage`.
`draw_null_as_zero`	nein	Ob fehlende Datenpunkte als Null gezeichnet werden sollen.
`min_y_axis`	nein	Minimaler Y-Achsen-Wert.
`tags`	nein	Globale Tags. Ersetzt vorhandene globale Tags, falls angegeben.

Token-Berechtigungen

Jedes MCP-Token hat konfigurierbare Berechtigungen nach Toolset: app, exceptions, performance, metrics, anomalies, dashboards, logging. Jedes Toolset kann auf read, write oder deaktiviert gesetzt werden. Tokens können auch auf bestimmte Anwendungen beschränkt und so eingestellt werden, dass neue Tools automatisch verfügbar werden, sobald sie hinzugefügt werden. So generieren Sie ein Token:

Wählen Sie Ihr Profilsymbol aus.
Gehen Sie zu Account Settings.
Wählen Sie MCP Tokens aus, um ein neues Token zu erstellen.

Fehlt ein Tool?

Wenn Ihr KI-Agent oder Editor etwas nicht erreichen kann, was Sie erwartet hätten, lassen Sie es ihn wissen. AppSignal MCP enthält einen integrierten Feedback-Mechanismus, der Anfragen für noch nicht vorhandene Funktionen protokolliert — dies hilft dem AppSignal-Team, zu priorisieren, was als Nächstes gebaut werden soll. Sie können auch Feature- Anfragen in der Discord-Community posten.

​Workflows

​Untersuchen eines Produktionsfehlers

​Profilieren einer langsamen Aktion

​Triage eines Batches von Vorfällen

​Durchsuchen von Protokollen während eines Vorfalls

​Rekonstruieren einer Kunden-Journey

​Einrichten der Protokollverarbeitung

​Erstellen eines Anomalieerkennungs-Triggers

​Erstellen eines Monitoring-Dashboards

​Tool-Referenz

​App-Discovery

​get_applications

​get_app_resources

​Fehlervorfälle

​get_exception_incidents

​get_incident

​update_incidents

​manage_incident_note

​Performance

​get_performance

​get_traces

​Anomalieerkennung

​get_anomaly_incidents

​get_triggers

​manage_trigger

​archive_trigger

​Logging

​get_log_lines

​manage_log_line_action

​reorder_log_line_actions

​delete_log_line_action

​Metriken

​discover_metrics

​get_metric_names

​get_metric_tags

​get_metrics_timeseries

​get_metrics_list

​Dashboards

​manage_dashboard

​create_dashboard_visual

​update_dashboard_visual

​Token-Berechtigungen

​Fehlt ein Tool?

Workflows

Untersuchen eines Produktionsfehlers

Profilieren einer langsamen Aktion

Triage eines Batches von Vorfällen

Durchsuchen von Protokollen während eines Vorfalls

Rekonstruieren einer Kunden-Journey

Einrichten der Protokollverarbeitung

Erstellen eines Anomalieerkennungs-Triggers

Erstellen eines Monitoring-Dashboards

Tool-Referenz

App-Discovery

`get_applications`

`get_app_resources`

Fehlervorfälle

`get_exception_incidents`

`get_incident`

`update_incidents`

`manage_incident_note`

Performance

`get_performance`

`get_traces`

Anomalieerkennung

`get_anomaly_incidents`

`get_triggers`

`manage_trigger`

`archive_trigger`

Logging

`get_log_lines`

`manage_log_line_action`

`reorder_log_line_actions`

`delete_log_line_action`

Metriken

`discover_metrics`

`get_metric_names`

`get_metric_tags`

`get_metrics_timeseries`

`get_metrics_list`

Dashboards

`manage_dashboard`

`create_dashboard_visual`

`update_dashboard_visual`

Token-Berechtigungen

Fehlt ein Tool?