SIGNL4 MCP by usefulapi

List the SIGNL4 teams the API key can access: id, name, description, time zone and member ids. Team ids are needed to raise alerts and to look up categories and duties. GET /v3/teams.

One SIGNL4 team: name, description, time zone, member ids. GET /v3/teams/{teamId}.

List the SIGNL4 users the key can access with name, e-mail, contact addresses, activation state and duty status per team (dutyMode, onDutyTime). User ids are needed to acknowledge/close/annotate alerts. GET /v3/users.

無需輸入參數。

One SIGNL4 user: name, e-mail, contact addresses, time zone and duty status per team. GET /v3/users/{userId}.

List the users of the given teams (all accessible teams by default) with duty status. Teams that cannot be read are reported under `errors`. GET /v3/teams/users.

List the alert categories of a team (name, color, keywords used to auto-classify alerts). The category name can be passed to signl4_raise_alert. GET /v3/categories/{teamId}.

Search SIGNL4 alerts (signls), newest first, with status, severity, category and history (created, acknowledged, closed). Filter by team, status, creation time, text or external id. Up to 100 per page; pass the returned continuation_token to get the next page. POST /v3/signls/paged (a read).

Full detail of one alert: title, text, severity, category, status and delivery status, history (who acknowledged/closed it and when), parameters, attachments and escalations with per-user delivery. GET /v3/signls/{signlId}/details.

The ordered timeline of an alert: creation, notifications, acknowledgements, annotations, escalations and remote actions. GET /v3/signls/{signlId}/timeline.

Alert volume and response statistics per team over several time periods: acknowledged, closed and unhandled counts, overall and per category (optionally for one user). Teams that cannot be read are reported under `errors`. GET /v3/signls/report.

WRITE: raise a new alert in a SIGNL4 team. THIS NOTIFIES REAL PEOPLE: every team member currently on duty is paged (push, SMS and/or voice call according to their settings) and the alert escalates if nobody acknowledges it. Only use it when the user clearly asked to alert the team; never for tests unless they said so. Not idempotent: a second call pages the team again. Returns the new alert incl. its id. POST /v3/signls.

WRITE: acknowledge an alert on behalf of a SIGNL4 user (recorded in its history under that user). Stops escalation to further tiers for that alert. POST /v3/signls/{signlId}/acknowledge.

WRITE: close (resolve) an alert on behalf of a SIGNL4 user; it leaves the open list and stops all further notifications. POST /v3/signls/{signlId}/close.

WRITE: add a text note to an alert's timeline on behalf of a SIGNL4 user. The note is visible to the team in the app. It does not page anyone by itself. POST /v3/signls/{signlId}/annotate.

Planned on-call duty schedules (who is on duty when): start/end, team, user, tier, stand-in and shift info. Filter by team, user and time window. POST /v3/schedules (a read).

Whether a user is currently on or off duty in each of their teams (dutyMode, onDutyTime, tier). GET /v3/users/{userId}/dutyStatus.

Duty assistant info per team: whether it is enabled and the last two (or all) duty periods. GET /v3/duties/summary.

Audit log of changes and events in the SIGNL4 subscription (who changed what, when). Filter by team, time window and message text; pass the returned continuation_token for the next page. GET /v3/audits.