Référence des outils MCP - AppSignal Documentation

AppSignal MCP expose 23 outils répartis sur huit domaines produit : découverte d’applications, incidents d’erreur, performance, Anomaly detection, Check-ins, journalisation, métriques et tableaux de bord. Un 24e outil, get_more_tools, permet à un agent de demander des capacités supplémentaires ou de signaler comment une tâche s’est déroulée. Vous n’appelez pas ces outils vous-même. Vous décrivez ce que vous voulez dans le chat de votre agent, par exemple : « quelles actions sont les plus lentes en production actuellement ? » L’agent choisit l’outil approprié et renseigne ses paramètres. Cette référence existe pour que vous puissiez vérifier si une capacité existe, et nommer un paramètre lorsque l’agent choisit le mauvais. Pour des exemples de la façon dont ces outils se combinent pour une tâche, consultez les flux de travail AppSignal MCP.

Référence des outils

La plupart des outils prennent app_name et app_environment pour identifier l’application cible. Les deux sont mis en correspondance sans tenir compte de la casse, donc MyApp/Production et myapp/production se résolvent vers la même application. Si le nom ne correspond à aucune application à laquelle vous avez accès, l’outil renvoie une erreur qui nomme ce que vous avez demandé et suggère les correspondances les plus proches, afin que l’agent puisse réessayer avec un nom valide. Chaque outil prend également une chaîne context afin que l’agent puisse expliquer pourquoi il effectue l’appel. Les agents la renseignent généralement automatiquement, donc les tableaux ci-dessous se concentrent sur les paramètres spécifiques à la tâche. manage_trigger, manage_log_line_action et manage_check_in_trigger couvrent chacun plusieurs opérations derrière un paramètre action requis, donc les champs dont vous avez besoin dépendent de l’action que vous transmettez. Dans ces tableaux, oui (upsert) signale un champ requis à chaque upsert, et oui (création) un champ requis uniquement lorsque l’upsert crée quelque chose plutôt que de le mettre à jour.

Découverte d’applications

`get_applications`

Obtenez toutes les applications AppSignal auxquelles l’utilisateur a accès. Retourne les applications au format app_name/app_environment. Utilisez-le d’abord pour découvrir les applications disponibles avant d’appeler d’autres outils. Aucun paramètre spécifique à la tâche en dehors de context.

`get_app_resources`

Découvrez les ressources disponibles dans une application AppSignal — namespaces, tableaux de bord, utilisateurs, notifieurs, sources de journaux, vues de journal, actions de ligne de journal, marqueurs de déploiement et moniteurs de disponibilité. Particulièrement utile lors de la configuration de déclencheurs, de l’attribution d’incidents ou de la compréhension de la structure d’une application.

Paramètre	Requis	Description
`app_name`	oui	Nom de l’application AppSignal.
`app_environment`	oui	Environnement (par exemple `production`, `staging`).
`sections`	non	Sections à récupérer : `users`, `notifiers`, `namespaces`, `dashboards`, `log_sources`, `log_line_actions`, `log_views`, `deploy_markers`, `uptime_monitors`. Retourne tout si non spécifié.
`deploy_marker_namespace`	non	N’afficher que les déploiements dans ce namespace (par exemple `web`).
`deploy_marker_revision`	non	N’afficher que les déploiements avec cette révision. Un préfixe court fonctionne (par exemple `a1b2c3d`).

La section deploy_markers retourne jusqu’à 100 déploiements récents, chacun avec sa révision complète et la plage horaire pendant laquelle il était actif. Restreignez-la avec deploy_marker_namespace ou deploy_marker_revision. Pour trouver les erreurs qu’un déploiement a introduites, passez sa révision à get_exception_incidents avec new_only: true. Sans new_only, vous obtenez toutes les erreurs signalées dans ce déploiement. Cela inclut celles observées pour la première fois dans un déploiement antérieur. La section uptime_monitors liste chaque URL surveillée et ses paramètres. La disponibilité elle-même n’est pas stockée — elle est calculée à partir de métriques, donc interrogez le compteur uptime_monitor_error_count avec get_metrics_timeseries pour la calculer. Pour un détail par phase, interrogez uptime_monitor_timing avec un tag phase. Voir temps de requête.

Check-ins

Ces deux outils couvrent les mêmes moniteurs que process monitoring : les moniteurs cron, qui attendent une exécution selon un calendrier, et les moniteurs heartbeat, qui attendent un signal continu.

`get_check_in_triggers`

Répertorie les moniteurs check-in (cron et heartbeat), ou inspecte un moniteur avec ses exécutions récentes. Utilisez ceci pour voir quels jobs ou services planifiés sont censés se signaler, vérifier s’ils sont à l’heure, ou trouver l’ID d’un moniteur avant de le mettre à jour.

Paramètre	Requis	Description
`app_name`	oui	Nom de l’application AppSignal.
`app_environment`	oui	Environnement.
`id`	non	Inspecte un déclencheur check-in par ID. Retourne la configuration et les exécutions récentes de ce déclencheur.
`identifier`	non	Inspecte un déclencheur check-in par identifiant, tel que `nightly-export`.
`kind`	non	Filtre la liste des déclencheurs par type : `cron` ou `heartbeat`. Ignoré lorsque `id` ou `identifier` est fourni.
`state`	non	Filtre les exécutions récentes d’un déclencheur par état : `new`, `started`, `finished`, `missed`, `late` ou `unexpected`.
`page`	non	Numéro de page (basé sur 1, par défaut 1). Pagine soit la liste des déclencheurs, soit l’historique d’exécution d’un déclencheur.

`manage_check_in_trigger`

Créer, mettre à jour ou supprimer un moniteur check-in. Contrairement aux déclencheurs de Anomaly detection, les moniteurs check-in sont mis à jour sur place. Lorsque vous en mettez un à jour, les champs omis conservent leurs valeurs actuelles.

Paramètre	Requis	Description
`app_name`	oui	Nom de l’application AppSignal.
`app_environment`	oui	Environnement.
`action`	oui	`upsert` pour créer ou mettre à jour, ou `delete` pour supprimer un moniteur.
`id`	oui (`delete`)	ID d’un moniteur existant. Requis pour `delete`, sauf si vous fournissez `identifier` à la place. Pour `upsert`, met à jour ce moniteur.
`identifier`	oui (création)	Identifiant lisible, tel que `nightly-export`. Peut aussi servir à rechercher ou supprimer un moniteur existant.
`kind`	oui (création)	`cron` ou `heartbeat`.
`syntax`	oui (cron)	Expression cron, telle que `0 0 * * *`. Requise chaque fois que le `kind` du moniteur est `cron`, y compris lorsqu’une mise à jour le fait basculer vers `cron`.
`wait_time_minutes`	oui (création)	Délai de grâce avant qu’une exécution soit marquée comme manquée.
`timezone`	non	Fuseau horaire pour une expression cron. Par défaut `UTC` à la création.
`description`	non	Description de ce que surveille le moniteur.
`notifier_ids`	non	ID des notifieurs à alerter lorsqu’un check-in est manqué ou en retard. Utilisez `get_app_resources(sections: ["notifiers"])`.

Incidents d’erreur

`get_exception_incidents`

Listez et recherchez les exceptions et erreurs AppSignal. Utilisez-le pour obtenir un aperçu des exceptions récentes, rechercher dans une période, trouver des incidents par état, ou vérifier quels incidents nécessitent attention. Retourne 50 incidents par page.

Paramètre	Requis	Description
`app_name`	oui	Nom de l’application AppSignal.
`app_environment`	oui	Environnement.
`namespaces`	non	Liste séparée par des virgules des namespaces à filtrer (par exemple `web,background`).
`query`	non	Recherche par mot-clé insensible à la casse dans le nom de l’exception et le nom de l’action. Prend en charge les caractères génériques `*`.
`start`	non	Début de la plage horaire au format ISO 8601. Par défaut, le déploiement le plus récent si omis.
`end`	non	Fin de la plage horaire au format ISO 8601. Requis si `start` est fourni, sauf si `new_only` vaut `true`.
`states`	non	États séparés par des virgules : `open`, `closed`, `wip`. Retourne tous les états si non spécifié.
`revision`	non	Limiter à un déploiement spécifique. Utilisez `"last"` pour le déploiement le plus récent, ou passez un hash de révision ou un préfixe court. Ignoré lorsque `start` et `end` sont fournis.
`new_only`	non	Lorsque `true`, ne retourne que les erreurs observées pour la première fois dans la fenêtre, et non toutes les erreurs survenues pendant celle-ci. Par défaut `false`.
`page`	non	Numéro de page (basé sur 1, par défaut 1).
`per_page`	non	Nombre d’incidents par page. Par défaut 50.

Pour les invites qui demandent à votre agent les nouvelles erreurs, consultez Vérifier ce qu’un déploiement a cassé.

`get_incident`

Obtenez des informations détaillées sur un incident AppSignal. Retourne l’état actuel, l’attribution, la première et la dernière occurrence, les messages d’erreur, les traces de pile ou les détails de l’alerte d’anomalie. Prend en charge les incidents d’exception et d’anomalie.

Paramètre	Requis	Description
`app_name`	oui	Nom de l’application AppSignal.
`app_environment`	oui	Environnement.
`number`	oui	L’ID numérique de l’incident affiché dans les URL et listes d’incidents AppSignal.

`update_incidents`

Mettez à jour en masse les incidents d’une application AppSignal. Utilisez-le pour modifier l’état d’incidents, mettre à jour la gravité ou attribuer et désattribuer des membres d’équipe sur plusieurs incidents à la fois. Utilisez get_app_resources avec sections: ["users"] pour trouver les ID utilisateur pour l’attribution.

Paramètre	Requis	Description
`app_name`	oui	Nom de l’application AppSignal.
`app_environment`	oui	Environnement.
`incidents`	non	Liste des numéros d’incident à mettre à jour (par exemple `[123, 456, 789]`).
`state`	non	`open`, `closed` ou `wip` (work in progress).
`severity`	non	`critical`, `high`, `low`, `none`, `informational` ou `untriaged`.
`assign_users`	non	Liste des ID utilisateur à attribuer comme gestionnaires.
`unassign_users`	non	Liste des ID utilisateur à retirer de l’incident.

`manage_note`

Créez ou mettez à jour une note sur un incident AppSignal ou sur une action de trace de performance. Markdown est pris en charge. Utilisez ceci pour ajouter des commentaires, mises à jour de statut, conclusions d’enquête ou étapes de résolution. Identifiez la cible avec number pour un incident, ou avec namespace et action_name pour une action de trace de performance. Fournir les deux renvoie une erreur. Une note sur une action de trace de performance est partagée par toutes les traces de cette action. Elle reste après l’expiration des données de trace de l’action. Une note sur un incident de performance est stockée sur l’action de trace de l’incident, pas sur l’incident lui-même. Elle reste disponible après la fermeture de l’incident. Consultez la documentation de la page des traces pour savoir où ces notes apparaissent. Incluez une URL complète d’issue GitHub dans une note d’incident pour lier cette issue à l’incident. Cela nécessite que l’application ait GitHub configuré. La liaison GitHub ne s’applique pas aux notes sur les actions de trace.

Cet outil s’appelait auparavant manage_incident_note, et avant cela create_incident_note. Les deux anciens noms fonctionnent toujours comme alias, afin que les invites et configurations existantes continuent de fonctionner.

Paramètre	Requis	Description
`app_name`	oui	Nom de l’application AppSignal.
`app_environment`	oui	Environnement.
`number`	oui (incident)	L’ID numérique de l’incident. Ne peut pas être combiné avec `namespace` ou `action_name`.
`namespace`	oui (action de trace)	Le namespace de l’action de trace de performance (par exemple `web`, `background`). Nécessite `action_name`.
`action_name`	oui (action de trace)	Le nom de l’action (par exemple `BlogPostsController#index`). Nécessite `namespace`.
`content`	oui	Contenu de la note. Le formatage Markdown est pris en charge.
`id`	non	ID d’une note existante à mettre à jour. Omettez pour créer une nouvelle note. Vous ne pouvez modifier que les notes que vous avez rédigées.

Performance

Pour ajouter une note à une action de trace de performance, utilisez manage_note.

`get_performance`

Aperçu des performances : traces de performance basées sur des échantillons et actions lentes à partir des traces. Pour les applications Ruby et Elixir standard, retourne les traces de performance basées sur des échantillons. Pour les applications qui envoient également des traces OpenTelemetry, retourne en plus une liste classée d’actions avec la durée moyenne, le débit et le taux d’erreur. Les applications en cours de migration vers OpenTelemetry peuvent retourner les deux. Outils de suivi : utilisez get_incident pour inspecter un incident de performance spécifique, get_traces pour récupérer des traces pour une action lente, et update_incidents pour modifier l’état, la gravité ou les attributions.

Paramètre	Requis	Description
`app_name`	oui	Nom de l’application AppSignal.
`app_environment`	oui	Environnement.
`namespaces`	non	Namespaces séparés par des virgules. S’applique à la fois aux traces de performance et aux actions OpenTelemetry.
`start`	non	Début de la plage horaire au format ISO 8601. Par défaut, le déploiement le plus récent pour les traces basées sur des échantillons, ou il y a 24 heures pour les actions OpenTelemetry.
`end`	non	Fin de la plage horaire au format ISO 8601. Requis si `start` est fourni.
`states`	non	États séparés par des virgules : `open`, `closed`, `wip`. S’applique uniquement aux incidents basés sur des échantillons.
`revision`	non	Limiter à un déploiement spécifique. Utilisez `"last"` pour le déploiement le plus récent, ou passez un hash de révision. Ignoré lorsque `start`/`end` est fourni. Utilisez `get_app_resources(sections: ["deploy_markers"])` pour lister les révisions disponibles.
`page`	non	Numéro de page pour les incidents basés sur des échantillons (basé sur 1, par défaut 1). Les actions OpenTelemetry sont retournées sous forme de liste classée complète.
`per_page`	non	Nombre d’incidents par page (par défaut 50). Pagine uniquement les incidents basés sur des échantillons.

`get_traces`

Interrogez les traces de performance et d’erreur, inspectez les arbres de spans et consultez les détails des spans. Prend en charge deux types de traces :

Traces de performance — identifiées par le namespace et action_name. Utilisez-les pour enquêter sur des requêtes lentes.
Traces d’erreur — identifiées par digest. Obtenez le digest depuis get_incident ou get_exception_incidents, puis utilisez-le ici pour voir les traces d’erreur réelles.

Chaque type de trace prend en charge trois modes :

Mode liste — trouvez des traces et obtenez les ID de trace. Fournissez le namespace + action_name, ou digest.
Mode arbre — passez un trace_id pour voir tous les spans sous forme d’arbre compact, ainsi que les métadonnées du span racine et une répartition de la durée. La répartition indique le temps propre par catégorie : ce sur quoi les spans de chaque catégorie ont réellement travaillé, plutôt que d’attendre un enfant.
Mode détail de span — passez trace_id et span_id pour les attributs de span complets, les événements et les informations de ressource. Les valeurs d’attribut longues sont tronquées à 500 caractères. Le texte des requêtes de base de données fait exception et est transmis en entier jusqu’à 10 000 caractères.

Le flux de travail typique est : lister les traces → inspecter un arbre de trace → plonger dans un span.

Paramètre	Requis	Description
`app_name`	oui	Nom de l’application AppSignal.
`app_environment`	oui	Environnement.
`namespace`	oui (performance)	L’namespace dans lequel rechercher (par exemple `web`, `background`). Non nécessaire pour les traces d’erreur.
`action_name`	oui (performance)	Le nom de l’action (par exemple `BlogPostsController#index`). Non nécessaire pour les traces d’erreur.
`digest`	oui (erreur)	Le digest de l’incident d’exception. Bascule en mode trace d’erreur. Ne peut pas être combiné avec `namespace` ou `action_name`.
`trace_id`	non	Bascule en mode arbre. Retourne tous les spans pour cette trace.
`span_id`	non	Bascule en mode détail de span. Nécessite `trace_id`.
`include_sensitive`	non	En mode détail de span, inclut les en-têtes HTTP, l’environnement de la requête, les paramètres de requête et les données de session. Par défaut `false`.
`start`	non	Début de la plage horaire au format ISO 8601. Par défaut, il y a 24 heures. Traces de performance uniquement.
`end`	non	Fin de la plage horaire au format ISO 8601. Par défaut, maintenant. Traces de performance uniquement.
`min_duration_ms`	non	Filtrer les traces plus lentes que ce seuil en millisecondes. Mode liste uniquement.
`limit`	non	Nombre maximum de traces à retourner (1–100, par défaut 25). Mode liste uniquement.

Anomaly detection

`get_anomaly_incidents`

Listez et recherchez les alertes de Anomaly detection AppSignal. Retourne 50 alertes par page, y compris les horodatages et valeurs pour chaque alerte.

Paramètre	Requis	Description
`app_name`	oui	Nom de l’application AppSignal.
`app_environment`	oui	Environnement.
`state`	non	`open`, `closed`, `warmup`, `cooldown` ou `archived`. Retourne tous les états si non spécifié.
`trigger_id`	non	Filtrer les incidents d’un déclencheur spécifique. Utilisez `get_triggers` pour trouver les ID de déclencheur.
`page`	non	Numéro de page (basé sur 1, par défaut 1).
`per_page`	non	Nombre d’alertes par page. Par défaut 50.

`get_triggers`

Listez les déclencheurs de Anomaly detection pour une application AppSignal. Retourne les déclencheurs actifs (non archivés) avec leur configuration complète — conditions, notifieurs et liens vers les tableaux de bord. Utilisez-le pour trouver les ID de déclencheur avant d’appeler manage_trigger.

Paramètre	Requis	Description
`app_name`	oui	Nom de l’application AppSignal.
`app_environment`	oui	Environnement.
`metric_name`	non	Filtrer par nom de métrique (par exemple `response_time`, `error_rate`).
`kind`	non	Filtrer par type de déclencheur.
`tags`	non	Filtrer par tags, par exemple `[{"key": "hostname", "value": "web-1"}]`.
`page`	non	Numéro de page (basé sur 1, par défaut 1).

`manage_trigger`

Créer, mettre à jour ou archiver un déclencheur de Anomaly detection. Les déclencheurs sont immuables. Lorsque vous mettez à jour un déclencheur, AppSignal archive celui existant, ferme toutes ses alertes et incidents, et en crée un remplaçant. Fournissez tous les champs pour les opérations de création et de mise à jour. Utilisez get_metric_names et get_metric_tags pour découvrir les métriques et champs disponibles. Utilisez get_app_resources(sections: ["notifiers"]) pour trouver les ID de notifieur.

Cet outil remplace l’ancien flux archive_trigger. L’ancien nom continue de fonctionner comme alias de rétrocompatibilité, mais manage_trigger est l’outil principal.

Paramètre	Requis	Description
`app_name`	oui	Nom de l’application AppSignal.
`app_environment`	oui	Environnement.
`action`	oui	`upsert` pour créer ou mettre à jour, ou `archive` pour arrêter la surveillance et fermer les alertes et incidents associés.
`metric_name`	oui (`upsert`)	La métrique que ce déclencheur surveille.
`kind`	oui (`upsert`)	Type de déclencheur. Utilisez `"Advanced"` pour les métriques personnalisées.
`field`	oui (`upsert`)	Champ de métrique à comparer : `gauge`, `mean`, `p90`, `p95`, `counter` ou `count`.
`condition_value`	oui (`upsert`)	Valeur seuil (par exemple `500.0` pour « response time > 500ms »).
`comparison_operator`	oui (`upsert`)	`<`, `>`, `<=`, `>=`, `==` ou `!=`.
`warmup_duration`	oui (`upsert`)	Minutes pendant lesquelles la condition doit être remplie avant qu’une alerte ne s’ouvre. Utilisez `0` pour immédiat.
`cooldown_duration`	oui (`upsert`)	Minutes pendant lesquelles la condition ne doit plus être remplie avant qu’une alerte ne se ferme.
`id`	oui (`archive`) / non (`upsert`)	ID d’un déclencheur existant. Requis pour `archive`. Pour `upsert`, le fournir archive l’ancien déclencheur et en crée un nouveau.
`notifier_ids`	non	ID des notifieurs vers lesquels envoyer les alertes.
`tags`	non	Filtres de tags pour limiter quelles métriques sont incluses. Prend en charge les caractères génériques (`*`).
`name`	non	Nom d’affichage. Par défaut, le nom de la métrique si non fourni.
`description`	non	Description de ce que ce déclencheur surveille et de ce qu’il faut faire lorsqu’il se déclenche.
`dashboard_id`	non	ID du tableau de bord à lier dans les notifications.
`no_match_is_zero`	non	Si vrai, traiter les données métriques manquantes comme 0. Utile pour les compteurs qui peuvent ne pas signaler lorsqu’ils sont inactifs.
`format`	non	Format des données de la métrique (par exemple `duration`, `size`, `percent`).
`format_input`	non	Taille d’entrée lorsque `format` vaut `size` (par exemple `kilobyte` ou `megabyte`).

Journalisation

`get_log_lines`

Interrogez les lignes de journal en utilisant la syntaxe d’expression d’AppSignal. Prend en charge la correspondance exacte, contient, la négation, les comparaisons numériques, la logique booléenne et les attributs imbriqués. Retourne jusqu’à 100 lignes par appel, du plus récent au plus ancien par défaut. Pour les grandes plages horaires, divisez en plusieurs appels et itérez vers l’avant. Chaque ligne commence par un aperçu de 120 caractères de son message. Si le message est plus long, la réponse ajoute une ligne Message distincte avec le texte complet, limité à 2 000 caractères. Syntaxe de requête :

Modèle	Exemple
Correspondance exacte	`severity=error`
Contient	`message:timeout`
Ne contient pas	`message!:debug`
Non égal	`hostname!=web-1`
Comparaison numérique	`duration>100`
Logique booléenne	`severity=error AND (hostname=web-1 OR hostname=web-2)`
Valeurs entre guillemets	`group="background jobs"`
Attributs imbriqués	`user.id=123`

Champs disponibles : severity, hostname, group, message et tout attribut personnalisé.

Paramètre	Requis	Description
`app_name`	oui	Nom de l’application AppSignal.
`app_environment`	oui	Environnement.
`query`	oui	Requête d’expression. Utilisez une chaîne vide pour récupérer tous les journaux.
`source_ids`	non	ID des sources de journaux à interroger. Interroge toutes les sources si non spécifié. Utilisez `get_app_resources(sections: ["log_sources"])` pour trouver les ID de source.
`start`	non	Début de la plage horaire au format ISO 8601. Par défaut, une fenêtre de requête plus tôt.
`end`	non	Fin de la plage horaire au format ISO 8601. Par défaut, maintenant.
`limit`	non	Nombre de lignes de journal à retourner (1–100, par défaut 50).
`order`	non	`desc` (du plus récent au plus ancien, par défaut) ou `asc` (du plus ancien au plus récent).

`manage_log_line_action`

Créer, mettre à jour, réorganiser ou supprimer une action de ligne de journal. Les actions de ligne de journal s’exécutent pendant l’ingestion des journaux, dans l’ordre que vous définissez. Il existe trois types :

filter — écarte les lignes de journal correspondantes afin qu’elles ne soient jamais stockées ni traitées
trigger — déclenche des alertes et incidents lorsque la requête correspond
metrics — extrait des métriques de compteur, jauge ou distribution à partir des lignes de journal correspondantes

L’ordre d’exécution est important : si un filtre écarte une ligne de journal, les actions suivantes ne la verront jamais. Un modèle courant consiste à placer les actions de métriques et de déclencheurs avant toute action de filtre. Les nouvelles actions sont ajoutées à la fin de l’ordre d’exécution.

Cet outil remplace les anciens flux reorder_log_line_actions et delete_log_line_action. Ces noms continuent de fonctionner comme alias de rétrocompatibilité, mais manage_log_line_action est l’outil principal.

Paramètre	Requis	Description
`app_name`	oui	Nom de l’application AppSignal.
`app_environment`	oui	Environnement.
`action`	oui	`upsert` pour créer ou mettre à jour, `reorder` pour changer l’ordre d’exécution, ou `delete` pour supprimer une action.
`name`	oui (création)	Nom de l’action (par exemple `"Drop health checks"`, `"Track error count"`).
`query`	oui (création)	Expression de requête à comparer aux lignes de journal.
`action_type`	oui (création)	`filter`, `trigger` ou `metrics`. Ne peut pas être modifié lors d’une mise à jour.
`id`	oui (`delete`)	ID d’une action existante. Pour `upsert`, le fournir met à jour cette action au lieu d’en créer une nouvelle.
`source_ids`	non	ID des sources de journaux auxquelles cette action s’applique. S’applique à toutes les sources si non spécifié.
`log_line_metrics`	non	Définitions de métriques à extraire. Requis lors de la création d’une action `metrics`. Chaque métrique requiert `name` et `metric_type` (`counter`, `gauge` ou `distribution`). `gauge` et `distribution` requièrent également un `field` pour extraire la valeur. Lors d’une mise à jour, remplace toutes les définitions de métriques existantes.
`action_ids`	oui (`reorder`)	Liste ordonnée des ID d’actions. Les ID d’action non inclus sont ajoutés à la fin dans leur ordre relatif actuel.

Métriques

`discover_metrics`

Découvrez les catégories de métriques disponibles et leurs métriques pour la surveillance. Utilisez-le pour obtenir un aperçu de ce que vous pouvez surveiller, ou pour explorer une catégorie spécifique. Accepte également une référence dashboard:<dashboard_id> pour afficher les métriques utilisées dans un tableau de bord spécifique.

Paramètre	Requis	Description
`app_name`	oui	Nom de l’application AppSignal.
`app_environment`	oui	Environnement.
`metric_subject`	non	Nom de la catégorie de métrique (par exemple `performance_metrics`, `host_metrics`) ou `dashboard:<dashboard_id>`.

`get_metric_names`

Obtenez les noms de toutes les métriques pour l’application donnée. Retourne les noms des métriques sous forme de chaîne séparée par des virgules. Utilisez-les comme entrée pour get_metric_tags, get_metrics_timeseries et get_metrics_list.

Paramètre	Requis	Description
`app_name`	oui	Nom de l’application AppSignal.
`app_environment`	oui	Environnement.

`get_metric_tags`

Obtenez les tags et le type de métrique (Gauge, Counter, etc.) pour une métrique spécifique. Utilisez les résultats pour construire des requêtes valides avec get_metrics_timeseries et get_metrics_list.

Paramètre	Requis	Description
`app_name`	oui	Nom de l’application AppSignal.
`app_environment`	oui	Environnement.
`metric_name`	oui	Nom de la métrique. Utilisez `get_metric_names` pour trouver les métriques disponibles.

`get_metrics_timeseries`

Obtenez une série chronologique pour une métrique dans l’application donnée. Retourne des données point par point pour une plage horaire, un type de métrique et une combinaison de tags donnés. Les valeurs des tags prennent en charge la correspondance par caractère générique avec *.

Paramètre	Requis	Description
`app_name`	oui	Nom de l’application AppSignal.
`app_environment`	oui	Environnement.
`metric_name`	oui	Nom de la métrique.
`metric_type`	oui	`count`, `counter`, `gauge`, `mean`, `p90` ou `p95`. Utilisez `get_metric_tags` pour trouver le type valide.
`start`	oui	Début de la plage horaire au format ISO 8601.
`end`	oui	Fin de la plage horaire au format ISO 8601.
`tags`	non	Filtres de tags, par exemple `[{"key": "hostname", "value": "web"}]`. Prend en charge les caractères génériques ``.

`get_metrics_list`

Obtenez une valeur agrégée pour une métrique sur une plage horaire. Retourne une seule valeur agrégée plutôt qu’une série chronologique point par point. Utile pour les vues récapitulatives.

Paramètre	Requis	Description
`app_name`	oui	Nom de l’application AppSignal.
`app_environment`	oui	Environnement.
`metric_name`	oui	Nom de la métrique.
`metric_type`	oui	`count`, `counter`, `gauge`, `mean`, `p90` ou `p95`.
`start`	oui	Début de la plage horaire au format ISO 8601.
`end`	oui	Fin de la plage horaire au format ISO 8601.
`tags`	non	Filtres de tags, par exemple `[{"key": "hostname", "value": "frontend1"}]`.

Tableaux de bord

`manage_dashboard`

Créer ou mettre à jour un tableau de bord AppSignal. Cet outil gère uniquement les métadonnées du tableau de bord (titre et description). Utilisez create_dashboard_visual et update_dashboard_visual pour ajouter des graphiques. MCP ajoute et met à jour, mais ne supprime pas. Pour supprimer un graphique ou un tableau de bord entier, ouvrez les tableaux de bord de votre application sur AppSignal.

Paramètre	Requis	Description
`app_name`	oui	Nom de l’application AppSignal.
`app_environment`	oui	Environnement.
`title`	oui	Titre du tableau de bord.
`description`	non	Description de l’objectif et du contenu du tableau de bord.
`id`	non	ID du tableau de bord pour mettre à jour un tableau de bord existant. Omettez pour en créer un nouveau.

`create_dashboard_visual`

Ajoutez un nouveau graphique à un tableau de bord existant. Deux types de visuels sont disponibles :

timeseries (par défaut) — un graphique en ligne ou en aire traçant une ou plusieurs métriques au fil du temps.
number — une tuile Big Number affichant une seule métrique agrégée, utile pour un total, la dernière lecture ou une moyenne en un coup d’œil.

Les deux s’affichent exactement comme si vous les aviez créés dans le constructeur de graphiques. Pour savoir à quoi sert chaque type de graphique, consultez les types de graphiques du tableau de bord. Utilisez discover_metrics ou get_metrics_list pour trouver d’abord les métriques disponibles. Ces paramètres s’appliquent aux deux types de visuels :

Paramètre	Requis	Description
`app_name`	oui	Nom de l’application AppSignal.
`app_environment`	oui	Environnement.
`dashboard_id`	oui	ID du tableau de bord auquel ajouter le visuel.
`title`	oui	Titre du graphique.
`type`	non	`timeseries` (par défaut) ou `number`.
`description`	non	Contexte supplémentaire sur le visuel.
`format`	non	Format de valeur : `number`, `percent`, `duration`, `throughput` ou `size`.
`format_input`	non	Unité de la valeur entrante : `bit`, `byte`, `kilobit`, `kilobyte` ou `megabyte`. S’applique uniquement lorsque `format` vaut `size`.

Ces paramètres s’appliquent uniquement aux visuels timeseries :

Paramètre	Requis	Description
`metrics`	oui	Tableau des métriques à tracer. Chacune prend `name`, `fields` (un tableau d’objets tel que `[{"field": "mean"}]`, où le champ est `mean`, `p90`, `p95`, `count`, `gauge` ou `counter`) et optionnellement `tags`.
`display`	non	`line` (par défaut), `area` ou `area_relative`.
`line_label`	non	Étiquette personnalisée pour les lignes du graphique. Prend en charge les remplacements `%name%`, `%field%` et `%tag%`.
`draw_null_as_zero`	non	Indique s’il faut dessiner les points de données manquants comme zéro. Par défaut : `false`.
`min_y_axis`	non	Valeur minimale de l’axe Y.
`tags`	non	Tags globaux appliqués à chaque métrique de ce visuel.

Ces paramètres s’appliquent uniquement aux visuels number :

Paramètre	Requis	Description
`metric`	oui	La métrique unique à afficher. Prend `name`, `field` (`mean`, `p90`, `p95`, `count`, `gauge` ou `counter`), `aggregate` (`max`, `min`, `avg`, `sum`, `first` ou `last`) et optionnellement `tags`.

Une tuile Big Number prend une métrique et une agrégation sur la plage horaire sélectionnée du tableau de bord. Demandez-la en langage naturel :

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.

L’agent traduit cela en un appel create_dashboard_visual :

{
  "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 crée le visuel ; il n’ingère pas de métriques. La métrique à laquelle vous pointez un graphique doit déjà circuler vers AppSignal. Consultez les métriques personnalisées pour savoir comment les envoyer depuis votre application.

`update_dashboard_visual`

Mettez à jour un graphique existant sur un tableau de bord. Cela fonctionne à la fois pour les visuels timeseries et Big Number — le type est lu depuis le visuel existant, vous n’avez donc pas besoin de passer type. Tous les champs sont facultatifs sauf les identifiants, et les champs non spécifiés conservent leurs valeurs actuelles. Passer metrics ou metric remplace toute la définition de métrique de ce visuel plutôt que de la fusionner.

Paramètre	Requis	Description
`app_name`	oui	Nom de l’application AppSignal.
`app_environment`	oui	Environnement.
`visual_id`	oui	ID du visuel à mettre à jour.
`title`	non	Nouveau titre.
`description`	non	Nouvelle description. Définir sur une chaîne vide pour la supprimer.
`format`	non	Format de valeur : `number`, `percent`, `duration`, `throughput` ou `size`.
`format_input`	non	Unité de la valeur entrante : `bit`, `byte`, `kilobit`, `kilobyte` ou `megabyte`. S’applique uniquement lorsque `format` vaut `size`.
`metrics`	non	Visuels timeseries uniquement. Remplace tout le tableau de métriques.
`display`	non	Visuels timeseries uniquement. `line`, `area` ou `area_relative`.
`line_label`	non	Visuels timeseries uniquement. Prend en charge les remplacements `%name%`, `%field%` et `%tag%`.
`draw_null_as_zero`	non	Visuels timeseries uniquement. Indique s’il faut dessiner les points de données manquants comme zéro.
`min_y_axis`	non	Visuels timeseries uniquement. Valeur minimale de l’axe Y.
`tags`	non	Visuels timeseries uniquement. Tags globaux. Remplace les tags globaux existants si fourni.
`metric`	non	Visuels Big Number uniquement. Remplace toute la définition de métrique. Même forme que dans `create_dashboard_visual`.

Outils de lecture et d’écriture

Chaque outil lit uniquement vos données ou peut les modifier, et son nom indique lequel : les outils get_ et discover_ ne font que lire, tandis que les outils create_, update_ et manage_ écrivent. La suppression se trouve à l’intérieur des outils manage_ plutôt que dans des outils qui lui sont propres : manage_log_line_action supprime une action, manage_check_in_trigger supprime un moniteur, et manage_trigger archive un déclencheur. C’est cette répartition que les clients MCP utilisent pour regrouper les outils, afin que vous puissiez configurer dans votre agent quels outils autoriser, lesquels approuver au cas par cas, et lesquels bloquer.

Permissions des tokens

Chaque token MCP est limité à des applications spécifiques et aux outils que vous exposez sur ce token. Si vous voulez une configuration plus restreinte pour un agent, c’est ici que vous la limitez. Par exemple, vous pourriez exposer uniquement get_applications, get_app_resources et get_exception_incidents pour un agent de tri des incidents, ou get_log_lines et manage_log_line_action pour le travail d’ingestion de journaux. Vous pouvez également configurer un token pour exposer automatiquement les nouveaux outils au fur et à mesure qu’ils sont ajoutés par la suite. Pour connaître les étapes de création, consultez Authentification.

Un outil manquant ?

En complément des domaines produit ci-dessus, AppSignal MCP expose get_more_tools, un outil de découverte et de retour d’expérience. Il remplit deux fonctions :

Journaliser une demande pour une capacité que vous n’avez pas trouvée
Signaler comment une tâche ou un appel d’outil s’est déroulé

Il ne débloque aucun outil caché aujourd’hui. Sa valeur réside dans le fait que la demande ou le retour est journalisé sur votre compte, afin que l’équipe AppSignal puisse voir où les agents se heurtent à un mur. get_more_tools prend ces paramètres :

Paramètre	Requis	Description
`context`	oui	Pourquoi l’agent appelle l’outil. Suivi interne uniquement — cela ne change pas la réponse.
`description`	non	La capacité que vous recherchez, en langage naturel. Journalisée comme demande d’outil si fournie.
`notes`	non	Ce qui s’est passé, avec assez de détails pour qu’un humain puisse agir. Requis lors du signalement d’un retour.
`outcome`	non	Résultat facultatif pour un retour : `success`, `partial` ou `failed`.

La plupart des agents n’y auront pas recours d’eux-mêmes, il faut donc demander explicitement : « Utilise l’outil AppSignal get_more_tools pour demander un moyen d’exporter en masse les incidents au format CSV. » Ou, lorsqu’une tâche a partiellement fonctionné : « Utilise l’outil AppSignal get_more_tools pour signaler que get_log_lines a trouvé les bons journaux, mais qu’il m’a fallu une seconde étape pour les résumer. »

Vous butez sur les limites du jeu d’outils actuel ? Demandez à votre agent d’appeler get_more_tools, puis publiez la même demande dans la communauté Discord afin que l’équipe AppSignal puisse l’évaluer.