Skip to main content
Glama

send_broadcast

Send a draft or scheduled campaign now, or schedule it with scheduled_at. This mails every contact in the segment and cannot be undone once started; preview_broadcast shows the count beforehand. Marketing mail must carry a postal address: a workspace without one is refused with 422 no_postal_address (a person adds it in Settings), and a suspended workspace with 422 workspace_suspended, whether sending now or scheduling. Calling this on an already-scheduled campaign with a new scheduled_at moves it; with no scheduled_at it starts now. Any other status answers 409 invalid_state, and a malformed scheduled_at 422 invalid_request. Returns the campaign object, as get_broadcast does: its status and scheduled_at are where the campaign now stands. The calling API key's guardrails apply: a key that holds its sends for approval (requires_approval) or has allowed_recipients gets 403 forbidden, because a campaign cannot be held for approval or kept to an allowlist. A retry answers the same; the campaign is sent by a person from the dashboard, or with a key without those guardrails. A key with a daily_send_limit is charged once for each campaign it puts on its way: sending or scheduling a draft counts its recipients, and starting a scheduled campaign now, moving it earlier, resuming it or deciding its winner counts what it still has to send, unless this key already paid for that campaign. When that does not fit what is left of the limit today the call answers 429 daily_limit and nothing changes; a retry the same day answers the same. The campaign's topic_key was checked against existing topics when it was created. A campaign bigger than the day's remaining quota or its domain's warm-up allowance is not rejected: it sends what it can and stops as 'paused', then continues later. That is expected, not an error, and retrying does not change it. An A/B test sends its sample, goes to 'testing', and sends the rest to the winner after decide_after_minutes or when pick_broadcast_winner is called. A send-time test is scheduled by its variants' send_at and does not accept scheduled_at.

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": {
      "id": "<id>"
    },
    "name": "send_broadcast"
  }
}

Input Schema

NameRequiredDescriptionDefault
idYesThe campaign's id from create_broadcast or list_broadcasts (a UUID), not its name
scheduled_atNoUTC ISO 8601 timestamp with a Z suffix, e.g. 2026-09-16T09:00:00.000Z; offsets and phrases like 'in 2 hours' are refused. Omitted, it sends now

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / scheduled_at / description
      Previous value: -"UTC ISO 8601 timestamp with a Z suffix, e.g. 2026-09-16T09:00:00.000Z; offsets and phrases like 'in 2 hours' are refused. Omit to send now"New value: +"UTC ISO 8601 timestamp with a Z suffix, e.g. 2026-09-16T09:00:00.000Z; offsets and phrases like 'in 2 hours' are refused. Omitted, it sends now"
  2. Changed1 schema field changed
    • changedInput schema / properties / scheduled_at / description
      Previous value: -"ISO 8601 timestamp; omit to send now"New value: +"UTC ISO 8601 timestamp with a Z suffix, e.g. 2026-09-16T09:00:00.000Z; offsets and phrases like 'in 2 hours' are refused. Omit to send now"
  3. Changed1 schema field changed
    • addedInput schema / properties / id / description
      Added value: +"The campaign's id from create_broadcast or list_broadcasts (a UUID), not its name"
  4. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Beyond annotations (readOnlyHint false/openWorldHint true), the description discloses irreversibility ('cannot be undone once started'), all relevant error conditions (422/409/429/403), guardrail behavior, daily-limit charging, paused-campaign behavior, and A/B test flow. This far exceeds the annotation baseline and fully covers external side effects.

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

Conciseness3/5

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

The description is front-loaded and information-dense, but it's a single long paragraph with redundant or ambiguous clauses (e.g., the retry sentence and the topic_key history). It could be restructured into bullets or shortened without losing the essential edge cases.

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

Completeness5/5

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

For a two-parameter tool with no output schema and many edge cases, the description covers every failure mode, side effect, return shape, and scheduling nuance. An agent has enough to invoke correctly without additional context.

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, but the description adds semantics for scheduled_at (moving already-scheduled campaigns, omitted means now, not accepted for send-time tests) and clarifies id is a UUID not a name, which the schema already states but the behavior context reinforces.

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?

The first sentence names the action (send/schedule), resource (campaign), and mode (now vs scheduled_at), immediately distinguishing it from siblings like create_broadcast, resume_broadcast, and preview_broadcast. It also notes failure for invalid statuses, further narrowing its scope.

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

Usage Guidelines4/5

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

It gives clear context for when to call (sending or scheduling a draft/scheduled campaign) and references preview_broadcast for pre-send counts, implying a before-step. It doesn't explicitly exclude siblings like send_email or create_broadcast, but the scope is unambiguous enough.

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.