mirror of
https://github.com/hanzoai/insights.git
synced 2026-11-03 00:52:32 +00:00
zeekay
1b367e2b62
The tree was a debranded snapshot of upstream taken around 2026-02-20, and upstream has moved about five months since. This replaces it with upstream master, mechanically re-derived: bin/debrand does the rename, and the pipeline and squashed migrations are restored from the shipped tree. Not a merge. The previous import replaced the tree wholesale in a single commit, so there is no shared content history to merge against. Reproducing the rename on the new tree is what actually converges. What survives: .hanzo/workflows, the Dockerfiles and bin/docker* entrypoints, compose files, LLM.md, and insights/migrations. The squashed initial migration is load-bearing — the live database records it by name, so upstream's ~918 individual migrations cannot come back. Nine products are dropped as unreferenced. Twenty-one more that we do not run are kept anyway because the core app still imports them; unpicking those is a refactor and does not belong in a rebase. This base does not build yet, and the reasons are not in the rename: upstream now wants Python 3.13.13 against our 3.12.12 and Django 5.2 against our 4.2, and the dependency manifests still name upstream packages that we republish under our own names. Those are decisions, not renames.
167 lines
8.8 KiB
YAML
167 lines
8.8 KiB
YAML
# MCP tool definition — tool entries are scaffolded from the OpenAPI schema.
|
|
# The tool list and operation IDs are kept in sync automatically:
|
|
# pnpm --filter=@hanzo/mcp run scaffold-yaml -- --sync-all
|
|
#
|
|
# To enable a tool, set enabled: true and add required scopes + annotations.
|
|
# All other fields (title, description, enrich_url, etc.) are yours to configure.
|
|
category: Alerts
|
|
feature: alerts
|
|
url_prefix: /alerts
|
|
ui_apps: {}
|
|
tools:
|
|
alert-create:
|
|
operation: alerts_create
|
|
enabled: true
|
|
scopes:
|
|
- alert:write
|
|
annotations:
|
|
readOnly: false
|
|
destructive: false
|
|
idempotent: false
|
|
enrich_url: ?alert_type=insights&alert_id={id}
|
|
title: Create alert
|
|
description: >
|
|
Create a new alert on an insight. Alerts can use either threshold-based conditions or anomaly detection. For
|
|
threshold alerts: set condition (absolute_value, relative_increase, relative_decrease) and threshold
|
|
configuration with bounds — at least one of lower or upper is required (omit detector_config). For anomaly
|
|
detection: set detector_config with a detector type (zscore, mad, iqr, threshold, copod, ecod, hbos,
|
|
isolation_forest, knn, lof, ocsvm, pca) and parameters like threshold (sensitivity 0-1, default 0.9) and
|
|
window size. Ensemble detectors combine 2+ sub-detectors with AND/OR logic. Requires an insight ID and at
|
|
least one subscribed user.
|
|
|
|
The config type must match the insight kind. Trends insights: TrendsAlertConfig (series_index,
|
|
check_ongoing_interval). SQL/InsightsQL insights: InsightsQLAlertConfig — column picks which result column to evaluate
|
|
(defaults to the single numeric column), evaluation is required and selects how rows are read: 'last_row'
|
|
(query ordered oldest->newest, the last row is the current value), 'first_row' (query ordered
|
|
newest->oldest, the first row is the current value — pair with a LIMIT, and it is unaffected by result
|
|
truncation), or 'any_row' (every row is checked and the alert fires if any value breaches; absolute_value
|
|
condition only). label_column names the evaluated row(s) in breach messages in every evaluation mode
|
|
(defaults to the first non-evaluated column). Label values appear in delivered notifications — avoid label
|
|
columns containing PII. Funnel insights: FunnelsAlertConfig — funnel_step picks the step to monitor (null
|
|
for the overall last step), metric is 'conversion_from_start' or 'conversion_from_previous', and
|
|
check_ongoing_interval (historical-trend funnels: also evaluate the current in-progress period). Steps
|
|
funnels support only absolute_value conditions; historical-trend funnels also support
|
|
relative_increase/relative_decrease. Anomaly detection (detector_config) is supported for trends and SQL
|
|
insights (not funnels).
|
|
|
|
Note: subscribed_users only controls email recipients. For Slack, HTTPS webhook, or Discord delivery, see
|
|
the recipe on cdp-functions-create — it covers integration lookup (integrations-channels-retrieve), dedupe
|
|
(cdp-functions-list filtered by alert id, limit=1000), and the exact filters/inputs shape to pass.
|
|
exclude_params:
|
|
- state
|
|
- last_notified_at
|
|
- last_checked_at
|
|
- next_check_at
|
|
- last_value
|
|
alert-delete:
|
|
operation: alerts_destroy
|
|
enabled: true
|
|
scopes:
|
|
- alert:write
|
|
annotations:
|
|
readOnly: false
|
|
destructive: true
|
|
idempotent: true
|
|
title: Delete alert
|
|
description: >
|
|
Delete an alert by ID. This permanently removes the alert and all its check history. Subscribed users will
|
|
no longer receive notifications.
|
|
alert-get:
|
|
operation: alerts_retrieve
|
|
enabled: true
|
|
scopes:
|
|
- alert:read
|
|
annotations:
|
|
readOnly: true
|
|
destructive: false
|
|
idempotent: true
|
|
enrich_url: ?alert_type=insights&alert_id={id}
|
|
title: Get alert
|
|
description: >
|
|
Get a specific alert by ID. Returns the full alert configuration including check results, threshold
|
|
settings, detector_config (for anomaly detection alerts), and subscribed users. Check results include
|
|
anomaly_scores, triggered_points, and triggered_dates for detector-based alerts. By default returns the last
|
|
5 checks. Use checks_date_from and checks_date_to (e.g. '-24h', '-7d') to get checks within a time window,
|
|
and checks_limit to control the maximum returned (default 5, max 500). When date filters are provided
|
|
without checks_limit, up to 500 checks are returned. Check history is retained for 14 days.
|
|
alert-simulate:
|
|
operation: alerts_simulate_create
|
|
enabled: true
|
|
scopes:
|
|
- alert:read
|
|
annotations:
|
|
readOnly: true
|
|
destructive: false
|
|
idempotent: true
|
|
title: Simulate detector on insight
|
|
description: >
|
|
Run an anomaly detector on an insight's historical data without creating any alert or check records. Use
|
|
this to preview how a detector configuration would perform before saving it as an alert. Requires an insight
|
|
ID and a detector_config object with a type (zscore, mad, iqr, copod, ecod, hbos, isolation_forest, knn,
|
|
lof, ocsvm, pca, or ensemble). Optionally specify date_from (e.g. '-48h', '-30d') to control how far back to
|
|
simulate, and series_index to pick which series to analyze. Returns data values, anomaly scores per point,
|
|
triggered indices and dates, and for ensemble detectors, per-sub-detector score breakdowns.
|
|
alert-update:
|
|
operation: alerts_partial_update
|
|
enabled: true
|
|
scopes:
|
|
- alert:write
|
|
annotations:
|
|
readOnly: false
|
|
destructive: false
|
|
idempotent: true
|
|
enrich_url: ?alert_type=insights&alert_id={id}
|
|
title: Update alert
|
|
description: >
|
|
Update an existing alert by ID. Can update name, threshold, condition, config, detector_config, subscribed
|
|
users, enabled state, calculation interval, and weekend skipping. Set detector_config to switch to anomaly
|
|
detection (trends and SQL insights), or set it to null to switch back to threshold mode (threshold mode
|
|
requires at least one of lower or upper in threshold.configuration.bounds). For SQL-insight alerts the
|
|
config is InsightsQLAlertConfig (column, evaluation 'last_row'/'first_row'/'any_row', label_column). To snooze an
|
|
alert, set snoozed_until to a relative date string (e.g. '2h', '1d'). To unsnooze, set snoozed_until to
|
|
null.
|
|
|
|
Note: Slack/webhook/Discord delivery for this alert lives as a InsightsFunction. See the recipe on
|
|
cdp-functions-create for the dedupe-and-create flow; to change or remove an existing destination, find it
|
|
via cdp-functions-list (type=internal_destination, limit=1000) by matching filters.properties value against
|
|
this alert's id, then use cdp-functions-partial-update or cdp-functions-delete.
|
|
exclude_params:
|
|
- state
|
|
- last_notified_at
|
|
- last_checked_at
|
|
- next_check_at
|
|
- last_value
|
|
alerts-list:
|
|
operation: alerts_list
|
|
enabled: true
|
|
scopes:
|
|
- alert:read
|
|
annotations:
|
|
readOnly: true
|
|
destructive: false
|
|
idempotent: true
|
|
enrich_url: ?alert_type=insights&alert_id={id}
|
|
list: true
|
|
title: List alerts
|
|
description: >
|
|
List all insight alerts in the project. Returns alerts with their current state, threshold or detector
|
|
configuration, timing information, and firing check history. Supports filtering by insight ID
|
|
(`insight_id`), fuzzy name search (`search`), and creator (`created_by` user UUID). Alerts can use either
|
|
threshold-based conditions (absolute_value, relative_increase, relative_decrease) or anomaly detection via
|
|
detector_config (zscore, mad, iqr, isolation_forest, knn, etc.).
|
|
alerts-simulate-create:
|
|
operation: alerts_simulate_create
|
|
enabled: false
|
|
alerts-test-delivery-create:
|
|
operation: alerts_test_delivery_create
|
|
enabled: false
|
|
alerts-update:
|
|
operation: alerts_update
|
|
enabled: false
|
|
insights-thresholds-list:
|
|
operation: insights_thresholds_list
|
|
enabled: false
|
|
insights-thresholds-retrieve:
|
|
operation: insights_thresholds_retrieve
|
|
enabled: false
|