Alarms

Alarms watch the $bind-resolved values your code pushes and fire push notifications + email when a condition trips. One alarm per streamboard, up to 5 conditions per alarm (logical AND).

Author an alarm

From an LLM (MCP):

> on streamboard sb_xyz, alert me when kpis.mrr.value < 40000 OR kpis.signups.value < 50

The model calls set_streamboard_alarm with a conditions array. Each condition has:

bindPath — dotted path into the state envelope (kpis.mrr.value, orders.rows.length, etc.). Must match a slot the spec exposes; get_streamboard_data returns the schema if unsure.
op — lt, lte, gt, gte, eq, neq, contains, notContains
value — number, string, or boolean to compare against
joinOp — AND or OR (omitted on the first condition)

Up to 5 conditions per alarm. The eval engine short-circuits at the first false on AND chains, first true on OR chains.

Evaluation

Alarms evaluate on every push to the streamboard’s state. There is no polling. Quiet boards never fire (and never cost anything).

Trip threshold: condition transitions from false → true. Re-firing on the same trip is debounced for 15 minutes.
Resolved threshold: condition returns to false. A “resolved” notification fires.
Push notification: delivered to all subscribed devices of the owning org’s members (Settings → Notifications → enable).
Email: delivered to alarm recipients (defaults to alarm creator).

Read + delete

> show the alarm on sb_xyz
> turn off the alarm on sb_xyz

get_streamboard_alarm returns the conditions array + last trip timestamp. set_streamboard_alarm with empty conditions removes the alarm.

Tier gating

Alarms require a Pro or Enterprise org. Personal-tier orgs cannot create alarms; the MCP tool returns 403 with subscription_required_pro.
Trial users get Pro flags during the 14-day window — alarms work.

MCP tools

Tool	Purpose
`get_streamboard_alarm`	Read current alarm + conditions + last-trip metadata.
`set_streamboard_alarm`	Create / update / clear the alarm (idempotent — full replace).