MCP-Tool-Referenz - AppSignal Documentation

AppSignal MCP stellt 23 Tools in acht Produktbereichen bereit: App-Discovery, Fehlervorfälle, Performance, Anomaly detection, Check-ins, Logging, Metriken und Dashboards. Ein 24. Tool, get_more_tools, ermöglicht es einem Agenten, nach zusätzlichen Fähigkeiten zu fragen oder Feedback dazu zu geben, wie eine Aufgabe verlaufen ist. Sie rufen diese Tools nicht selbst auf. Sie beschreiben im Chat Ihres Agenten, was Sie möchten, zum Beispiel: „Welche Aktionen sind gerade in der Produktion am langsamsten?” Der Agent wählt das passende Tool aus und füllt dessen Parameter aus. Diese Referenz gibt es, damit Sie prüfen können, ob eine Fähigkeit überhaupt existiert, und einen Parameter benennen können, wenn der Agent den falschen wählt. Beispiele dafür, wie diese Tools für eine Aufgabe zusammenwirken, finden Sie unter den AppSignal MCP-Workflows.

Tool-Referenz

Die meisten Tools benötigen 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. Wenn der Name nicht mit einer Anwendung übereinstimmt, auf die Sie Zugriff haben, gibt das Tool einen Fehler zurück, der nennt, wonach Sie gefragt haben, und die naheliegendsten Übereinstimmungen vorschlägt, sodass der Agent es mit einem gültigen Namen erneut versuchen kann. Jedes Tool nimmt außerdem eine context-Zeichenkette entgegen, mit der der Agent begründen kann, warum er den Aufruf tätigt. Agenten füllen dieses Feld normalerweise automatisch aus, daher konzentrieren sich die folgenden Tabellen auf die aufgabenspezifischen Parameter. manage_trigger, manage_log_line_action und manage_check_in_trigger decken jeweils mehrere Operationen hinter einem erforderlichen action-Parameter ab, sodass die benötigten Felder davon abhängen, welche Aktion Sie übergeben. In diesen Tabellen kennzeichnet ja (upsert) ein Feld, das bei jedem Upsert erforderlich ist, und ja (create) eines, das nur erforderlich ist, wenn der Upsert etwas erstellt, statt es zu aktualisieren.

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 aufgabenspezifischen Parameter außer context.

`get_app_resources`

Entdeckt verfügbare Ressourcen in einer AppSignal-Anwendung — Namespaces, Dashboards, Benutzer, Notifier, Protokollquellen, Log Views, 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 mit new_only: true. Ohne new_only erhalten Sie jeden Fehler, der in diesem Deploy gemeldet wurde. Das schließt Fehler ein, die erstmals in einem früheren Deploy aufgetreten sind. 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. Für eine Aufschlüsselung nach Phasen fragen Sie uptime_monitor_timing mit einem phase-Tag ab. Siehe Request-Timing.

Check-ins

Diese beiden Tools decken dieselben Monitore ab wie Process monitoring: Cron-Monitore, die eine Ausführung nach Zeitplan erwarten, und Heartbeat-Monitore, die ein kontinuierliches Signal erwarten.

`get_check_in_triggers`

Listet Check-in-Monitore (Cron und Heartbeat) auf oder untersucht einen Monitor mit seinen letzten Ausführungen. Verwenden Sie dies, um zu sehen, welche geplanten Jobs oder Dienste sich melden sollen, zu prüfen, ob sie pünktlich sind, oder eine Monitor-ID zu finden, bevor Sie sie aktualisieren.

Parameter	Erforderlich	Beschreibung
`app_name`	ja	Name der AppSignal-Anwendung.
`app_environment`	ja	Umgebung.
`id`	nein	Untersucht einen Check-in-Trigger anhand der ID. Gibt die Konfiguration und die letzten Ausführungen dieses Triggers zurück.
`identifier`	nein	Untersucht einen Check-in-Trigger anhand seines Identifiers, z. B. `nightly-export`.
`kind`	nein	Filtert die Trigger-Liste nach Art: `cron` oder `heartbeat`. Wird ignoriert, wenn `id` oder `identifier` angegeben ist.
`state`	nein	Filtert die letzten Ausführungen eines Triggers nach Zustand: `new`, `started`, `finished`, `missed`, `late` oder `unexpected`.
`page`	nein	Seitennummer (1-basiert, Standard 1). Paginiert entweder die Trigger-Liste oder den Ausführungsverlauf eines Triggers.

`manage_check_in_trigger`

Erstellt, aktualisiert oder löscht einen Check-in-Monitor. Anders als Anomaly detections-Trigger werden Check-in-Monitore direkt aktualisiert. Wenn Sie einen aktualisieren, behalten ausgelassene Felder ihre aktuellen Werte.

Parameter	Erforderlich	Beschreibung
`app_name`	ja	Name der AppSignal-Anwendung.
`app_environment`	ja	Umgebung.
`action`	ja	`upsert` zum Erstellen oder Aktualisieren, oder `delete` zum Entfernen eines Monitors.
`id`	ja (`delete`)	ID eines vorhandenen Monitors. Bei `delete` erforderlich, sofern nicht stattdessen `identifier` angegeben wird. Bei `upsert` aktualisiert dies den betreffenden Monitor.
`identifier`	ja (Erstellung)	Für Menschen lesbarer Identifier, z. B. `nightly-export`. Kann auch verwendet werden, um einen vorhandenen Monitor nachzuschlagen oder zu löschen.
`kind`	ja (Erstellung)	`cron` oder `heartbeat`.
`syntax`	ja (cron)	Cron-Ausdruck, z. B. `0 0 * * *`. Erforderlich, wann immer der `kind` des Monitors `cron` ist, auch wenn eine Aktualisierung ihn auf `cron` umstellt.
`wait_time_minutes`	ja (Erstellung)	Karenzzeit, bevor eine Ausführung als verpasst markiert wird.
`timezone`	nein	Zeitzone für einen Cron-Ausdruck. Standardmäßig `UTC` bei der Erstellung.
`description`	nein	Beschreibung dessen, was der Monitor verfolgt.
`notifier_ids`	nein	Notifier-IDs, die benachrichtigt werden, wenn ein Check-in verpasst wird oder zu spät kommt. Verwenden Sie `get_app_resources(sections: ["notifiers"])`.

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`).
`query`	nein	Groß-/Kleinschreibung wird bei der Stichwortsuche über den Ausnahmenamen und den Aktionsnamen nicht berücksichtigt. Unterstützt `*`-Platzhalter.
`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, es sei denn, `new_only` ist `true`.
`states`	nein	Komma-separierte Zustände: `open`, `closed`, `wip`. Gibt alle Zustände zurück, falls nicht angegeben.
`revision`	nein	Auf einen bestimmten Deploy beschränken. Verwenden Sie `"last"` für den letzten Deploy, oder übergeben Sie einen Revisions-Hash oder einen kurzen Präfix. Wird ignoriert, wenn `start` und `end` angegeben werden.
`new_only`	nein	Wenn `true`, werden nur die Fehler zurückgegeben, die im Zeitfenster erstmals aufgetreten sind, nicht jeder Fehler, der darin aufgetreten ist. Standardmäßig `false`.
`page`	nein	Seitennummer (1-basiert, Standard 1).
`per_page`	nein	Anzahl der Vorfälle pro Seite. Standard 50.

Für Prompts, die Ihren Agenten nach neuen Fehlern fragen, siehe Prüfen, was ein Deploy kaputt gemacht hat.

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

Erstellt oder aktualisiert eine Notiz zu einem AppSignal-Vorfall oder zu einer Performance-Trace-Aktion. Markdown wird unterstützt. Verwenden Sie dies, um Kommentare, Statusaktualisierungen, Untersuchungsergebnisse oder Lösungsschritte hinzuzufügen. Identifizieren Sie das Ziel mit number für einen Vorfall, oder mit namespace und action_name für eine Performance-Trace-Aktion. Werden beide angegeben, gibt es einen Fehler. Eine Notiz zu einer Performance-Trace-Aktion wird von jedem Trace dieser Aktion gemeinsam genutzt. Sie bleibt bestehen, nachdem die Trace-Daten der Aktion abgelaufen sind. Eine Notiz zu einem Performance-Vorfall wird bei der Trace-Aktion des Vorfalls gespeichert, nicht beim Vorfall selbst. Sie bleibt verfügbar, nachdem der Vorfall geschlossen wurde. Wo diese Notizen erscheinen, erfahren Sie in der Dokumentation zur Trace-Seite. Fügen Sie einer Vorfall-Notiz eine vollständige GitHub-Issue-URL hinzu, um dieses Issue mit dem Vorfall zu verknüpfen. Dies erfordert, dass die App mit GitHub konfiguriert ist. Die GitHub-Verknüpfung gilt nicht für Notizen zu Trace-Aktionen.

Dieses Tool hieß zuvor manage_incident_note, und davor create_incident_note. Beide alten Namen funktionieren weiterhin als Aliase, sodass bestehende Prompts und Konfigurationen weiter funktionieren.

Parameter	Erforderlich	Beschreibung
`app_name`	ja	Name der AppSignal-Anwendung.
`app_environment`	ja	Umgebung.
`number`	ja (Vorfall)	Die numerische Vorfall-ID. Kann nicht mit `namespace` oder `action_name` kombiniert werden.
`namespace`	ja (Trace-Aktion)	Der Namespace der Performance-Trace-Aktion (z. B. `web`, `background`). Erfordert `action_name`.
`action_name`	ja (Trace-Aktion)	Der Aktionsname (z. B. `BlogPostsController#index`). Erfordert `namespace`.
`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

Um einer Performance-Trace-Aktion eine Notiz hinzuzufügen, verwenden Sie manage_note.

`get_performance`

Performance-Überblick: Sample-basierte Performance-Traces und langsame Aktionen aus Traces. Für Standard-Ruby- und Elixir-Apps gibt sample-basierte Performance-Traces 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 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-Traces als auch für OpenTelemetry-Aktionen.
`start`	nein	Beginn des Zeitbereichs im ISO-8601-Format. Standardmäßig der letzte Deploy für sample-basierte Traces 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. Wird 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.
`per_page`	nein	Anzahl der Vorfälle pro Seite (Standard 50). Paginiert nur sample-basierte Vorfälle.

`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, zusammen mit den Metadaten des Root-Spans und einer Aufschlüsselung der Dauer. Die Aufschlüsselung zeigt die Eigenzeit nach Kategorie: womit die Spans in jeder Kategorie tatsächlich beschäftigt waren, statt auf ein Child zu warten.
Span-Detailmodus — Übergeben Sie trace_id und span_id für vollständige Span-Attribute, -Ereignisse und -Ressourceninformationen. Lange Attributwerte werden bei 500 Zeichen abgeschnitten. Eine Ausnahme bildet der Text von Datenbankabfragen, der bis zu 10.000 Zeichen vollständig durchkommt.

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`.
`include_sensitive`	nein	Im Span-Detailmodus HTTP-Header, Request-Umgebung, Request-Parameter und Session-Daten einbeziehen. Standardmäßig `false`.
`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.

Anomaly detection

`get_anomaly_incidents`

Listet AppSignal-Anomaly detections-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).
`per_page`	nein	Anzahl der Alerts pro Seite. Standard 50.

`get_triggers`

Listet die Anomaly detections-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 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, aktualisiert oder archiviert einen Anomaly detections-Trigger. Trigger sind unveränderlich. Wenn Sie einen Trigger aktualisieren, archiviert AppSignal den vorhandenen, schließt all seine Alerts und Vorfälle und erstellt einen Ersatz. 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.

Dieses Tool ersetzt den älteren archive_trigger-Ablauf. Der alte Name funktioniert weiterhin als Alias zur Abwärtskompatibilität, aber manage_trigger ist das primäre Tool.

Parameter	Erforderlich	Beschreibung
`app_name`	ja	Name der AppSignal-Anwendung.
`app_environment`	ja	Umgebung.
`action`	ja	`upsert` zum Erstellen oder Aktualisieren, oder `archive`, um die Überwachung zu beenden und zugehörige Alerts und Vorfälle zu schließen.
`metric_name`	ja (`upsert`)	Die Metrik, die dieser Trigger überwacht.
`kind`	ja (`upsert`)	Trigger-Art. Verwenden Sie `"Advanced"` für benutzerdefinierte Metriken.
`field`	ja (`upsert`)	Zu vergleichendes Metrikfeld: `gauge`, `mean`, `p90`, `p95`, `counter` oder `count`.
`condition_value`	ja (`upsert`)	Schwellenwert (z. B. `500.0` für „response time > 500ms”).
`comparison_operator`	ja (`upsert`)	`<`, `>`, `<=`, `>=`, `==` oder `!=`.
`warmup_duration`	ja (`upsert`)	Minuten, in denen die Bedingung erfüllt sein muss, bevor ein Alert geöffnet wird. `0` für sofort.
`cooldown_duration`	ja (`upsert`)	Minuten, in denen die Bedingung nicht mehr erfüllt sein darf, bevor ein Alert geschlossen wird.
`id`	ja (`archive`) / nein (`upsert`)	ID eines vorhandenen Triggers. Für `archive` erforderlich. Bei `upsert` archiviert die Angabe den alten Trigger und erstellt einen neuen.
`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`).
`format_input`	nein	Eingabegröße, wenn `format` gleich `size` ist (z. B. `kilobyte` oder `megabyte`).

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. Jede Zeile beginnt mit einer 120 Zeichen langen Vorschau ihrer Nachricht. Ist die Nachricht länger, fügt die Antwort eine separate Message-Zeile mit dem vollständigen Text hinzu, begrenzt auf 2.000 Zeichen. 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, aktualisiert, ordnet neu an oder löscht 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. Neue Aktionen werden am Ende der Ausführungsreihenfolge angehängt.

Dieses Tool ersetzt die älteren Abläufe reorder_log_line_actions und delete_log_line_action. Diese Namen funktionieren weiterhin als Aliase zur Abwärtskompatibilität, aber manage_log_line_action ist das primäre Tool.

Parameter	Erforderlich	Beschreibung
`app_name`	ja	Name der AppSignal-Anwendung.
`app_environment`	ja	Umgebung.
`action`	ja	`upsert` zum Erstellen oder Aktualisieren, `reorder` zum Ändern der Ausführungsreihenfolge, oder `delete` zum Entfernen einer Aktion.
`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`	ja (`delete`)	ID einer vorhandenen Aktion. Bei `upsert` aktualisiert die Angabe diese Aktion, statt eine neue zu erstellen.
`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.
`action_ids`	ja (`reorder`)	Geordnete Liste von Aktion-IDs. Alle nicht enthaltenen Aktion-IDs werden in ihrer aktuellen relativen Reihenfolge am Ende angehängt.

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:<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 `dashboard:<dashboard_id>`.

`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. MCP fügt hinzu und aktualisiert, entfernt aber nichts. Um ein Diagramm oder ein ganzes Dashboard zu löschen, öffnen Sie die Dashboards Ihrer App in AppSignal.

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 hinzu. Es stehen zwei Visual-Typen zur Verfügung:

timeseries (Standard) — ein Linien- oder Flächendiagramm, das eine oder mehrere Metriken über die Zeit darstellt.
number — eine Big-Number-Kachel, die eine einzelne aggregierte Metrik zeigt, nützlich für eine Summe, den letzten Messwert oder einen Durchschnitt auf einen Blick.

Beide werden exakt so gerendert, wie Sie sie im Diagramm-Builder erstellen würden. Wofür welcher Diagrammtyp gedacht ist, erfahren Sie unter Dashboard-Diagrammtypen. Verwenden Sie zuerst discover_metrics oder get_metrics_list, um verfügbare Metriken zu finden. Diese Parameter gelten für beide Visual-Typen:

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.
`type`	nein	`timeseries` (Standard) oder `number`.
`description`	nein	Zusätzlicher Kontext über das Visual.
`format`	nein	Wertformat: `number`, `percent`, `duration`, `throughput` oder `size`.
`format_input`	nein	Einheit des eingehenden Werts: `bit`, `byte`, `kilobit`, `kilobyte` oder `megabyte`. Gilt nur, wenn `format` gleich `size` ist.

Diese Parameter gelten nur für timeseries-Visuals:

Parameter	Erforderlich	Beschreibung
`metrics`	ja	Array der darzustellenden Metriken. Jede benötigt `name`, `fields` (ein Array von Objekten wie `[{"field": "mean"}]`, wobei das Feld `mean`, `p90`, `p95`, `count`, `gauge` oder `counter` ist) und optional `tags`.
`display`	nein	`line` (Standard), `area` oder `area_relative`.
`line_label`	nein	Benutzerdefiniertes Label für Diagrammlinien. Unterstützt `%name%`, `%field%` und `%tag%`-Ersetzungen.
`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 jede Metrik in diesem Visual angewendet werden.

Diese Parameter gelten nur für number-Visuals:

Parameter	Erforderlich	Beschreibung
`metric`	ja	Die einzelne anzuzeigende Metrik. Nimmt `name`, `field` (`mean`, `p90`, `p95`, `count`, `gauge` oder `counter`), `aggregate` (`max`, `min`, `avg`, `sum`, `first` oder `last`) und optional `tags`.

Eine Big-Number-Kachel nimmt eine Metrik und eine Aggregation über den ausgewählten Zeitbereich des Dashboards. Fragen Sie in natürlicher Sprache danach:

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.

Der Agent übersetzt das in einen create_dashboard_visual-Aufruf:

{
  "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 erstellt das Visual; es erfasst keine Metriken. Die Metrik, auf die Sie ein Diagramm richten, muss bereits in AppSignal einlaufen. Wie Sie sie aus Ihrer Anwendung senden, erfahren Sie unter Benutzerdefinierte Metriken.

`update_dashboard_visual`

Aktualisiert ein vorhandenes Diagramm in einem Dashboard. Dies funktioniert sowohl für Timeseries- als auch für Big-Number-Visuals — der Typ wird aus dem vorhandenen Visual gelesen, sodass Sie type nicht übergeben müssen. Alle Felder sind optional außer den Identifikatoren, und nicht angegebene Felder behalten ihre aktuellen Werte. Wenn Sie metrics oder metric übergeben, wird die gesamte Metrikdefinition dieses Visuals ersetzt, statt hineinzumischen.

Parameter	Erforderlich	Beschreibung
`app_name`	ja	Name der AppSignal-Anwendung.
`app_environment`	ja	Umgebung.
`visual_id`	ja	ID des zu aktualisierenden Visuals.
`title`	nein	Neuer Titel.
`description`	nein	Neue Beschreibung. Auf eine leere Zeichenkette setzen, um sie zu entfernen.
`format`	nein	Wertformat: `number`, `percent`, `duration`, `throughput` oder `size`.
`format_input`	nein	Einheit des eingehenden Werts: `bit`, `byte`, `kilobit`, `kilobyte` oder `megabyte`. Gilt nur, wenn `format` gleich `size` ist.
`metrics`	nein	Nur Timeseries-Visuals. Ersetzt das gesamte Metriken-Array.
`display`	nein	Nur Timeseries-Visuals. `line`, `area` oder `area_relative`.
`line_label`	nein	Nur Timeseries-Visuals. Unterstützt `%name%`, `%field%` und `%tag%`-Ersetzungen.
`draw_null_as_zero`	nein	Nur Timeseries-Visuals. Ob fehlende Datenpunkte als Null gezeichnet werden sollen.
`min_y_axis`	nein	Nur Timeseries-Visuals. Minimaler Y-Achsen-Wert.
`tags`	nein	Nur Timeseries-Visuals. Globale Tags. Ersetzt vorhandene globale Tags, falls angegeben.
`metric`	nein	Nur Big-Number-Visuals. Ersetzt die gesamte Metrikdefinition. Gleiche Form wie in `create_dashboard_visual`.

Lese- und Schreib-Tools

Jedes Tool liest entweder nur Ihre Daten oder kann sie ändern, und sein Name verrät, welches: get_- und discover_-Tools lesen nur, während create_-, update_- und manage_-Tools schreiben. Löschen ist Teil der manage_-Tools und hat kein eigenes Tool: manage_log_line_action entfernt eine Aktion, manage_check_in_trigger entfernt einen Monitor, und manage_trigger archiviert einen. Nach genau dieser Aufteilung gruppieren MCP-Clients, sodass Sie in Ihrem Agenten festlegen können, welche Tools erlaubt sind, welche Sie im Einzelfall genehmigen und welche Sie blockieren.

Token-Berechtigungen

Jedes MCP-Token ist auf bestimmte Anwendungen und auf die Tools beschränkt, die Sie für dieses Token freigeben. Wenn Sie eine engere Einrichtung für einen Agenten möchten, schränken Sie sie hier ein. Zum Beispiel könnten Sie für einen Agenten zur Vorfall-Triage nur get_applications, get_app_resources und get_exception_incidents freigeben, oder get_log_lines und manage_log_line_action für Arbeiten an der Protokollerfassung. Sie können ein Token auch so einstellen, dass neue Tools automatisch freigegeben werden, sobald sie später hinzugefügt werden. Die Schritte zum Erstellen finden Sie unter Authentifizierung.

Fehlt ein Tool?

Neben den oben genannten Produktbereichen stellt AppSignal MCP get_more_tools bereit, ein Tool für Discovery und Feedback. Es erledigt zwei Aufgaben:

Protokolliert eine Anfrage für eine Fähigkeit, die Sie nicht finden konnten
Erfasst Feedback dazu, wie eine Aufgabe oder ein Tool-Aufruf verlaufen ist

Es schaltet heute keine versteckten Tools frei. Sein Wert liegt darin, dass die Anfrage oder das Feedback gegen Ihr Konto protokolliert wird, sodass das AppSignal-Team sehen kann, wo Agenten an ihre Grenzen stoßen. get_more_tools nimmt diese Parameter entgegen:

Parameter	Erforderlich	Beschreibung
`context`	ja	Warum der Agent das Tool aufruft. Nur zur Dokumentation — es ändert die Antwort nicht.
`description`	nein	Die gesuchte Fähigkeit, in einfacher Sprache. Wird, sofern angegeben, als Tool-Anfrage protokolliert.
`notes`	nein	Was passiert ist, detailliert genug, damit ein Mensch handeln kann. Beim Einreichen von Feedback erforderlich.
`outcome`	nein	Optionales Ergebnis für Feedback: `success`, `partial` oder `failed`.

Die meisten Agenten greifen von sich aus nicht danach, also fragen Sie explizit: „Verwende das AppSignal-Tool get_more_tools, um nach einer Möglichkeit zu fragen, Vorfälle im Batch als CSV zu exportieren.” Oder, wenn eine Aufgabe teilweise funktioniert hat: „Verwende das AppSignal-Tool get_more_tools, um Feedback einzureichen, dass get_log_lines die richtigen Protokolle gefunden hat, ich aber noch einen zweiten Schritt brauchte, um sie zusammenzufassen.”

Stoßen Sie mit dem aktuellen Toolset an eine Grenze? Bitten Sie Ihren Agenten, get_more_tools aufzurufen, und posten Sie dieselbe Anfrage anschließend in der Discord-Community, damit das AppSignal-Team sie abwägen kann.

​Tool-Referenz

​App-Discovery

​get_applications

​get_app_resources

​Check-ins

​get_check_in_triggers

​manage_check_in_trigger

​Fehlervorfälle

​get_exception_incidents

​get_incident

​update_incidents

​manage_note

​Performance

​get_performance

​get_traces

​Anomaly detection

​get_anomaly_incidents

​get_triggers

​manage_trigger

​Logging

​get_log_lines

​manage_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

​Lese- und Schreib-Tools

​Token-Berechtigungen

​Fehlt ein Tool?

Tool-Referenz

App-Discovery

`get_applications`

`get_app_resources`

Check-ins

`get_check_in_triggers`

`manage_check_in_trigger`

Fehlervorfälle

`get_exception_incidents`

`get_incident`

`update_incidents`

`manage_note`

Performance

`get_performance`

`get_traces`

Anomaly detection

`get_anomaly_incidents`

`get_triggers`

`manage_trigger`

Logging

`get_log_lines`

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

Lese- und Schreib-Tools

Token-Berechtigungen

Fehlt ein Tool?