Skip to main content
Glama

SuprSend

Broadcast to a list

broadcasts_trigger
Destructive

Sends one published template (templates_publish) to every user of a subscriber list, without a workflow (an announcement, an outage notice). It sends real notifications to the whole list: tell the user the list size first (dry_run gives it). Set dry_run to only check that the list and the template exist; nothing is sent. The category decides which user preferences apply (preferences_list_categories). For some users, use workflows_trigger. Schedule it with trigger_at or delay (with both, trigger_at wins). The answer has an idempotency key: broadcasts_get shows the status with it (also of a scheduled broadcast), and broadcasts_cancel stops the broadcast.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "list_id": "<list_id>",
      "template": "<template>",
      "category": "<category>",
      "workspace": "<workspace>",
      "context": "<context>",
      "llm_model": "<llm_model>"
    },
    "name": "broadcasts_trigger"
  }
}

Input Schema

NameRequiredDescriptionDefault
dataNoValues for the template variables.
delayNoSend after this delay, in the form 1d2h30m10s. With trigger_at, trigger_at wins.
contextYesAnalytics: why you call this tool, in 10-20 words. Say "a user", never names, emails, or IDs.
dry_runNotrue: only check that the list and the template exist; nothing is sent.
list_idYesThe list ID (see lists_list).
categoryYesThe notification category slug (see preferences_list_categories).
channelsNoOnly these channels, e.g. ["inbox"]. Default: every channel of the template.
templateYesThe template slug (see templates_list).
llm_modelYesAnalytics: your model ID, or "unknown".
tenant_idNoThe tenant ID, e.g. "acme": it selects the tenant's branding and template variants.
workspaceYesThe slug of the workspace to act on. Call workspaces_list to find the valid values.
precomputeNoFor a scheduled broadcast (with trigger_at or delay): prepare it ahead of time — snapshot the audience, apply each user's preferences, and render every message up to 2 hours before the send, so a time-critical broadcast goes out on schedule instead of spending minutes preparing first. Trade-off: the plan is fixed at preparation time, so users who join the list, preference changes, and template edits made after that apply only from the next broadcast. Has no effect on a send now.
trigger_atNoSend at this time (ISO 8601 with a time zone, e.g. 2026-10-06T09:00:00Z); it wins over delay.
conversation_idNoPass the exact conversation_id from the server's previous response, unchanged. The server provides it on the first call — never invent one, and do not issue parallel tool calls until you have it. Keep passing the same conversation_id for the rest of the conversation, including after later user messages or on a different task; do not reset it when the user starts a new request.
idempotency_keyNoA retry with the same key sends nothing again. Default: new.

Output Schema

NameRequiredDescriptionDefault
validNoDry run only: the list and the template exist.
errorsNoDry run only: what is wrong.
dry_runYestrue: nothing was sent.
list_idYes
idempotency_keyNoGive it to broadcasts_cancel.
_mcp_instructionsNoServer-issued metadata for this conversation.
subscribers_countNoThe users in the list.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / precompute
      Added value: +{
      +  "description": "For a scheduled broadcast (with trigger_at or delay): prepare it ahead of time — snapshot the audience, apply each user's preferences, and render every message up to 2 hours before the send, so a time-critical broadcast goes out on schedule instead of spending minutes preparing first. Trade-off: the plan is fixed at preparation time, so users who join the list, preference changes, and template edits made after that apply only from the next broadcast. Has no effect on a send now.",
      +  "type": "boolean"
      +}
  2. First observed

TDQS

A4.7/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Goes beyond destructiveHint=true by naming the consequence concretely: it sends real notifications to the entire list, so the user should be shown the list size first. It also discloses idempotency semantics, trigger_at-over-delay precedence, preference-driven channel selection, and the follow-up tools (broadcasts_get for status, broadcasts_cancel to stop).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The high-stakes warning about sending to the whole list is front-loaded, and most sentences earn their place. The middle is dense with parenthetical sibling references (templates_publish, preferences_list_categories), which makes it read like a run-on in places.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given an output schema, full annotations, and 100% schema coverage, the description covers the risky semantics that matter for a mass-send. It omits precompute (with its audience-snapshot trade-off for scheduled sends) and channel narrowing, which an agent scheduling a time-critical broadcast would want surfaced in prose.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3; the description adds real meaning on top by explaining dry_run as an existence check, the trigger_at vs delay precedence, why category matters (preferences), and the idempotency key's retry behavior. It says nothing about precompute, channels, or tenant_id, which are the parameters with the trickiest trade-offs.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ("Sends one published template ... to every user of a subscriber list") and immediately names the sibling it is not (workflows_trigger) plus the prerequisite tool (templates_publish). An agent can distinguish it from workflows_trigger and broadcasts_get without opening a schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit when-to-use (announcements, outage notices, no workflow), when-not-to-use ("For some users, use workflows_trigger"), and a mandatory pre-flight ("tell the user the list size first"). Alternatives and sequencing are spelled out rather than implied.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.