Version
DESTRUCTIVE

update_alert_destinations

Replace the full set of places the creator's alerts go — connected accounts and email, with per-class routing.

Replace the authenticated creator's alert routing whole, the operation PUT /v1/me/alert-destinations performs: destinations is the complete wanted list, at most 20 rows — a row left out is removed, an empty list silences everything. Each row names a kind (connector_identity or email), a target (a connected account's id from get_me's identities, or an email address) and optional classes (alert class words; omit for every class, an empty list keeps the destination but routes nothing). The answer is the routing as it now stands, the same rows get_alert_destinations reads.

A target must be the creator's own

Only the creator's linked accounts and their own email can receive alerts; any other target is RESOURCE_NOT_FOUND and nothing is written.

Requires ability

The token behind the MCP session must hold it, or the call is refused with TOKEN_MISSING_ABILITY.

Runs the same action as

The REST endpoint and this tool share one action, so validation, permissions and events are identical.

Annotations

DestructiveIdempotent

A client that honours annotations asks a person before running it. Sending the same arguments twice changes nothing the second time.

Arguments

destinations*array

The complete wanted list of destinations, at most 20: objects of "kind" ("connector_identity" or "email"), "target", and optional "classes" (alert class words; omit for every class, empty list for none). Rows left out are removed.

How it fails

RESOURCE_NOT_FOUND

a target that is not one of the caller's own accounts or addresses.

VALIDATION_FAILED

an unknown kind or alert class, more than 20 rows, or a malformed row.

TOKEN_MISSING_ABILITY

token lacks account:write.

Arguments

  • destinations (required) — the complete wanted list, each row {kind, target, classes?}.

How is this guide?

Last updated on